There is an interesting conversation going on about virtiofsd and SELinux

[Casey Schaufler]

On 8/25/2021 1:26 PM, Stephen Smalley wrote:
> On Wed, Aug 25, 2021 at 3:19 PM Daniel Walsh <dwalsh at redhat.com> 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@redhat.com/
>>
>> 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.