[Virtio-fs] SELinux support in virtio-fs

[Daniel Walsh]

On 2/10/20 11:06 AM, Stefan Hajnoczi wrote:
> Hi Dan,
> I've CCed the public virtio-fs mailing list because SELinux support in
> virtio-fs has been asked about recently.
>
> It's time to figure out what level of SELinux support will be available
> in virtio-fs.  The file system client shares most of its code with FUSE
> and SELinux labels on files are currently not supported in FUSE.
>
> It would be possible to pass through extended attributes to the
> virtiofsd daemon running on the host.  However, passing through xattrs
> allows the client to relabel files on the host file system and this
> could pose a security problem.  virtiofsd already allows the client to
> set the uid/gid and permissions, but is passing through SELinux xattrs a
> bad idea?
>
> virtiofsd is in a position to mangle extended attribute names
> ("security.selinux" -> "virtiofs.security.selinux") in order to separate
> guest SELinux labels from host SELinux labels.
>
> As someone who knows very little about SELinux I'm eager to hear what
> you think would be a good approach.  Secure containers (e.g. Kata
> Containers) are an important use case but virtio-fs can also be used as
> the root file system for a guest (a scenario where full SELinux support
> is needed).
>
> Thanks,
> Stefan

First off.  Lets look at some fundamental rules about SELinux. 

One if a file system like overlay is mounted with a context mount, then
SELinux labels can not be modified on this label.  This is going to be a
common use case for kata.    We expect the labels inside of the
container to be some form of container_file_t.  With an MCS Label to
match. Anything on the image that needs to be written inside of the
container needs to be done on an Overlay File system.  Bottom line, I
would like the labels from the host system to pass into the container
and be enforced in the container, iff the container supports SELinux
labeling.  I believe in KATA case, the Containers Kernel will basically
see SELinux as disabled, and will do no SELinux actions. 

We will run the virtiofs daemon(s) as the same label as the qemu
process, something like kvm_container_t. Where it will only be able to
write to files/directories with the container_file_t:MCS labels that match.

Then if a container process inside of a VM tries to write to content on
the host that was volume mounted into the container via virtiofs,
SELinux will block the access unless the content is labeled correctly. 
This would match the behavior of non KVM Containers.

Now if we look at VM's we have different issues.  Theoretically we could
mount a volume from the host into a VM with labels.  And the VM could
have SELinux enabled inside with a different policy. 

What happens then?

If the processes inside of the container attempts to create content on
the mount point with a label that is not defined on the host system, it
will be denied.  And this is a good thing.  We don't want bogus from the
host point of view labels on disk.  If a label on the host is mounted
into the container and the containers kernel does not understand the
label, then SELinux will report the label as unlabeled_t. Confined
processes will not be allowed to interact with unlabeled_t files.

I am not crazy about adding a new XATTR to support alternate types for a
file on the host.  This is asking for problems, and if should be
discussed with the upstream SELinux developers before it is considered. 
Two big issues I see with this is around Nesting.  If I want to run a
container and virtiofs inside of a VM running Virtiofs, then you have a
problem.  Second problem is around getting permission denials, become
hard to diagnose. A process inside of a container might get permission
denied trying to write to a file label, that looks correct in the VM,
but the virtiofs on the host is being denied access to a different type
on the host.

When we did labeled NFS we basically stated that the types used in a
mount point must be shared between the host and client and would be
enforced by both the client kernel and the server kernel.  I see no
reason to make this more complicated to start. 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20200217/5e21b31b/attachment.sig>