> -----Original Message----- > From: Vivek Goyal <vgoyal@xxxxxxxxxx> > Sent: Friday, June 25, 2021 12:12 PM > To: linux-fsdevel@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > viro@xxxxxxxxxxxxxxxxxx > Cc: virtio-fs@xxxxxxxxxx; dwalsh@xxxxxxxxxx; dgilbert@xxxxxxxxxx; > berrange@xxxxxxxxxx; vgoyal@xxxxxxxxxx Please include Linux Security Module list <linux-security-module@xxxxxxxxxxxxxxx> and selinux@xxxxxxxxxxxxxxx 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
