lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 25 Jun 2021 21:49:51 +0000
From:   "Schaufler, Casey" <casey.schaufler@...el.com>
To:     Vivek Goyal <vgoyal@...hat.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>
CC:     "virtio-fs@...hat.com" <virtio-fs@...hat.com>,
        "dwalsh@...hat.com" <dwalsh@...hat.com>,
        "dgilbert@...hat.com" <dgilbert@...hat.com>,
        "berrange@...hat.com" <berrange@...hat.com>,
        "casey@...aufler-ca.com" <casey@...aufler-ca.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        "selinux@...r.kernel.org" <selinux@...r.kernel.org>
Subject: RE: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special
 files if caller has CAP_SYS_RESOURCE

> -----Original Message-----
> From: Vivek Goyal <vgoyal@...hat.com>
> Sent: Friday, June 25, 2021 12:12 PM
> To: linux-fsdevel@...r.kernel.org; linux-kernel@...r.kernel.org;
> viro@...iv.linux.org.uk
> Cc: virtio-fs@...hat.com; dwalsh@...hat.com; dgilbert@...hat.com;
> berrange@...hat.com; vgoyal@...hat.com

Please include Linux Security Module list <linux-security-module@...r.kernel.org>
and selinux@...r.kernel.org on this topic.

> Subject: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if
> caller has CAP_SYS_RESOURCE
> 
> Hi,
> 
> In virtiofs, actual file server is virtiosd daemon running on host.
> There we have a mode where xattrs can be remapped to something else.
> For example security.selinux can be remapped to
> user.virtiofsd.securit.selinux on the host.

This would seem to provide mechanism whereby a user can violate
SELinux policy quite easily. 

> 
> This remapping is useful when SELinux is enabled in guest and virtiofs
> as being used as rootfs. Guest and host SELinux policy might not match
> and host policy might deny security.selinux xattr setting by guest
> onto host. Or host might have SELinux disabled and in that case to
> be able to set security.selinux xattr, virtiofsd will need to have
> CAP_SYS_ADMIN (which we are trying to avoid). Being able to remap
> guest security.selinux (or other xattrs) on host to something else
> is also better from security point of view.

Can you please provide some rationale for this assertion?
I have been working with security xattrs longer than anyone
and have trouble accepting the statement.

> But when we try this, we noticed that SELinux relabeling in guest
> is failing on some symlinks. When I debugged a little more, I
> came to know that "user.*" xattrs are not allowed on symlinks
> or special files.
> 
> "man xattr" seems to suggest that primary reason to disallow is
> that arbitrary users can set unlimited amount of "user.*" xattrs
> on these files and bypass quota check.
> 
> If that's the primary reason, I am wondering is it possible to relax
> the restrictions if caller has CAP_SYS_RESOURCE. This capability
> allows caller to bypass quota checks. So it should not be
> a problem atleast from quota perpective.
> 
> That will allow me to give CAP_SYS_RESOURCE to virtiofs deamon
> and remap xattrs arbitrarily.

On a Smack system you should require CAP_MAC_ADMIN to remap
security. xattrs. I sounds like you're in serious danger of running afoul
of LSM attribute policy on a reasonable general level.

> 
> Thanks
> Vivek
> 
> Vivek Goyal (1):
>   xattr: Allow user.* xattr on symlink/special files with
>     CAP_SYS_RESOURCE
> 
>  fs/xattr.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --
> 2.25.4

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ