On 8/25/2021 1:26 PM, Stephen Smalley wrote: > On Wed, Aug 25, 2021 at 3:19 PM Daniel Walsh <dwalsh@xxxxxxxxxx> wrote: >> The problem is how do we handle a VM with SELinux enabled and the rootfs >> handled by virtiofsd? Or if the SELinux inside of the VM wanted to write >> multiple different labels on a volume mounted in via virtiofsd. >> >> Here is how Vivek defines it: >> >> ``` >> How do we manage SELinux host and guest policy with passthrough >> filesystems like virtiofs. Both guest and host might have different >> SELinux policies and can conflict with each other in various ways. And >> this problem exacerbates where there are nested VM guests. Now there >> are 3 entities with possibly 3 different SELinux policies and still >> all the real security.selinux xattr is created and stored on host >> filesystem. >> >> One possible proposal is to remap guest SELinux xattrs to some other >> name, say user.virtiofs.security.selinux. That way host will enforce >> SELinux policy based on security.selinux xattr stored on file. Guest >> will get labels stored in user.virtiofs.security.selinux and guest >> kernel will enforce that. This in theory provides both guest and >> host policies to co-exist and work. And this can be extended to >> nested guest where its attrs are prefixed by one more level of >> user.virtiofs. IOW, user.virtiofs.user.virtiofs.security.selinux >> will be the xattr on host which will show up as security.selinux >> xattr when nested guest does getxattr(). >> >> Virtiofsd currently has capability to do this remapping. One problem >> we have is that we are using "user" xattr namespace and one can >> not use "user" xattr on symlinks and special files. So when guest >> tries relabeling or chcon on these files, it fails. May be this is >> fixable. I have done an RFC propsal upstream. >> >> https://lore.kernel.org/linux-fsdevel/20210708175738.360757-1-vgoyal@xxxxxxxxxx/ >> >> Looking for thoughts how to fix the issue of SELinux with passthrough >> filesystems. What's the best way to solve this issue. >> >> Thanks >> Vivek >> >> ``` >> >> We used to talk about this way back when, but never found a good solution. Theoretically >> labeled NFS has the same issue, but I don't believe there are any NFS rootfs using SELinux. > The early labeled NFS work included a notion of a label > domain-of-interpretation (DOI) field and label translation as part of > the infrastructure but I don't think that made it into mainline? > It is however part of the NFSv4.2 spec I believe (called a label > format specifier or LFS). > At present I believe the assumption is that either the NFS server is > just a "dumb" server that is not enforcing any SELinux policy at all > (just storing the labels for use by clients) or is enforcing the same > policy as the clients. > > A while ago James Morris proposed an approach to namespaced selinux > xattrs to support selinux namespaces, > https://lore.kernel.org/linux-security-module/alpine.LFD.2.20.1711212009330.6297@localhost/ > . > However, that keeps them in the security.* namespace which on the one > hand better protects them from tampering but runs afoul of virtiofsd's > goal of avoiding the need to run with capabilities. > > If we use the user. namespace we need a way to control which processes > can change these attributes (or remove them) on the host; optimally we > could limit it to only virtiofsd itself and no other processes not > even > root processes on the host. That presumably requires some kind of LSM > hook or hook call; the current SELinux setxattr and removexattr hooks > don't care about user.* beyond a general setattr permission check. "Wow, if only there was a round thing we could attach to this wagon so it wouldn't be so hard to pull." I must be missing something really obvious. User namespaces map uids and gids to their parent namespace. An xattr namespace could do exactly the same thing, mapping security.selinux=foo in the child namespace to security.selinux=bar in the parent namespace. We know how to do this for uids, and have found and addressed a bunch of issues. Why do something different? There's no reason to make this LSM specific, or even something that's only useful for security attributes. I know that we've got partial "solutions", including virtiofs and various LSM specific namespace schemes. Nothing I've seen wouldn't be better served by an xattr namespace. Warning: I am not a fan of namespaces. I am less a fan of having dozens of "solutions", none of which work with any of the others, all of which have to be made to play nice together by user-space services.
