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.
