[Virtio-fs] SELinux support in virtio-fs

[Virtio-fs] SELinux support in virtio-fs

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Virtio-fs] SELinux support in virtio-fs

[Daniel Walsh]

[-- Attachment #1.1: Type: text/plain, Size: 1417 bytes --]

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

I am traveling right now.  We should add in the SELinux team, and I will
be able to look at this on Friday.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Virtio-fs] SELinux support in virtio-fs

[Daniel Walsh]

[-- Attachment #1.1: Type: text/plain, Size: 4198 bytes --]

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. 




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Virtio-fs] SELinux support in virtio-fs

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 4743 bytes --]

On Mon, Feb 17, 2020 at 12:48:46PM -0500, Daniel Walsh wrote:
> 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. 

Yes, the upstream Kata guest kernel currently has SELinux disabled.

> 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.

Sounds good.

> 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. 

Okay, so no nesting and client/server must share types.  I'll try to get
that working.  At the moment setting labels on files inside the guest
fails because the setxattr("security.selinux", label) is rejected by the
host kernel.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [selinux-internal] SELinux support in virtio-fs

[Ondrej Mosnacek]

On Wed, Feb 12, 2020 at 4:29 PM Daniel Walsh <dwalsh@redhat.com> wrote:
> 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
>
> I am traveling right now.  We should add in the SELinux team, and I will
> be able to look at this on Friday.

Cc'ing the upstream SELinux mailing list for more insight. Here is a
public archive of the full thread:

https://www.redhat.com/archives/virtio-fs/2020-February/msg00005.html

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

Re: [Virtio-fs] [selinux-internal] SELinux support in virtio-fs

[Ondrej Mosnacek]

On Wed, Feb 12, 2020 at 4:29 PM Daniel Walsh <dwalsh@redhat.com> wrote:
> 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
>
> I am traveling right now.  We should add in the SELinux team, and I will
> be able to look at this on Friday.

Cc'ing the upstream SELinux mailing list for more insight. Here is a
public archive of the full thread:

https://www.redhat.com/archives/virtio-fs/2020-February/msg00005.html

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

Re: SELinux support in virtio-fs

[Stephen Smalley]

On 2/19/20 11:11 AM, Ondrej Mosnacek wrote:
> On Wed, Feb 12, 2020 at 4:29 PM Daniel Walsh <dwalsh@redhat.com> wrote:
>> 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
>>
>> I am traveling right now.  We should add in the SELinux team, and I will
>> be able to look at this on Friday.
> 
> Cc'ing the upstream SELinux mailing list for more insight. Here is a
> public archive of the full thread:
> 
> https://www.redhat.com/archives/virtio-fs/2020-February/msg00005.html

FWIW, there were previous attempts to add FUSE support for per-file 
SELinux labeling (rather than just a single genfscon-based or context= 
mount option label for all files in the mount) but there were problems:

- deadlock during mount with userspace waiting for mount(2) to complete 
and the kernel blocked on requesting the security.selinux xattr of the 
root directory as part of superblock setup during mount [1] [2].
[1] 
https://lore.kernel.org/selinux/1280234607.4789.6.camel@moss-pluto.epoch.ncsc.mil/
[2] 
https://lore.kernel.org/selinux/20120824195928.22970.16209.stgit@paris.rdu.redhat.com/

- there was an attempt to introduce distinctions based on filesystem 
"subtype" so that whitelisted fuse filesystems could have xattr support 
enabled when it was known that their userspace would handle mount(2) 
safely [3] but this was apparently always broken and later reverted [4].
[3] 
https://lore.kernel.org/selinux/20130416225619.GA30164@sh-el5.eng.rdu2.redhat.com/
[4] 
https://lore.kernel.org/selinux/20131213195520.11231.81980.stgit@localhost/.

- there is the issue of trusting the fuse filesystem for its labeling 
information and for domain/context transitions.  At the least, we'd need 
a permission check to gate which contexts a fuse filesystem could supply 
(e.g. the filesystem associate check), and by default nosuid mounts 
disable domain transitions (although it is possible to selectively allow 
them via nosuid_transition now).  Also, if a non-init user namespace 
mount, even if policy is configured to use xattrs 
(SECURITY_FS_USE_XATTR), we flip to using mountpoint labeling (i.e. 
implicit context= mount with the context derived from the mounter's 
context and matching type_transition rule if any) and we don't permit 
use of context mount options.

Re: [Virtio-fs] SELinux support in virtio-fs

[Stephen Smalley]

On 2/19/20 11:11 AM, Ondrej Mosnacek wrote:
> On Wed, Feb 12, 2020 at 4:29 PM Daniel Walsh <dwalsh@redhat.com> wrote:
>> 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
>>
>> I am traveling right now.  We should add in the SELinux team, and I will
>> be able to look at this on Friday.
> 
> Cc'ing the upstream SELinux mailing list for more insight. Here is a
> public archive of the full thread:
> 
> https://www.redhat.com/archives/virtio-fs/2020-February/msg00005.html

FWIW, there were previous attempts to add FUSE support for per-file 
SELinux labeling (rather than just a single genfscon-based or context= 
mount option label for all files in the mount) but there were problems:

- deadlock during mount with userspace waiting for mount(2) to complete 
and the kernel blocked on requesting the security.selinux xattr of the 
root directory as part of superblock setup during mount [1] [2].
[1] 
https://lore.kernel.org/selinux/1280234607.4789.6.camel@moss-pluto.epoch.ncsc.mil/
[2] 
https://lore.kernel.org/selinux/20120824195928.22970.16209.stgit@paris.rdu.redhat.com/

- there was an attempt to introduce distinctions based on filesystem 
"subtype" so that whitelisted fuse filesystems could have xattr support 
enabled when it was known that their userspace would handle mount(2) 
safely [3] but this was apparently always broken and later reverted [4].
[3] 
https://lore.kernel.org/selinux/20130416225619.GA30164@sh-el5.eng.rdu2.redhat.com/
[4] 
https://lore.kernel.org/selinux/20131213195520.11231.81980.stgit@localhost/.

- there is the issue of trusting the fuse filesystem for its labeling 
information and for domain/context transitions.  At the least, we'd need 
a permission check to gate which contexts a fuse filesystem could supply 
(e.g. the filesystem associate check), and by default nosuid mounts 
disable domain transitions (although it is possible to selectively allow 
them via nosuid_transition now).  Also, if a non-init user namespace 
mount, even if policy is configured to use xattrs 
(SECURITY_FS_USE_XATTR), we flip to using mountpoint labeling (i.e. 
implicit context= mount with the context derived from the mounter's 
context and matching type_transition rule if any) and we don't permit 
use of context mount options.

Re: SELinux support in virtio-fs

[Casey Schaufler]

On 2/19/2020 8:44 AM, Stephen Smalley wrote:
> On 2/19/20 11:11 AM, Ondrej Mosnacek wrote:
>> On Wed, Feb 12, 2020 at 4:29 PM Daniel Walsh <dwalsh@redhat.com> wrote:
>>> 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
>>>
>>> I am traveling right now.  We should add in the SELinux team, and I will
>>> be able to look at this on Friday.
>>
>> Cc'ing the upstream SELinux mailing list for more insight. Here is a
>> public archive of the full thread:
>>
>> https://www.redhat.com/archives/virtio-fs/2020-February/msg00005.html

Also adding the LSM mailing list. This could be interesting for
any security module that uses extended attributes.

>
> FWIW, there were previous attempts to add FUSE support for per-file SELinux labeling (rather than just a single genfscon-based or context= mount option label for all files in the mount) but there were problems:
>
> - deadlock during mount with userspace waiting for mount(2) to complete and the kernel blocked on requesting the security.selinux xattr of the root directory as part of superblock setup during mount [1] [2].
> [1] https://lore.kernel.org/selinux/1280234607.4789.6.camel@moss-pluto.epoch.ncsc.mil/
> [2] https://lore.kernel.org/selinux/20120824195928.22970.16209.stgit@paris.rdu.redhat.com/
>
> - there was an attempt to introduce distinctions based on filesystem "subtype" so that whitelisted fuse filesystems could have xattr support enabled when it was known that their userspace would handle mount(2) safely [3] but this was apparently always broken and later reverted [4].
> [3] https://lore.kernel.org/selinux/20130416225619.GA30164@sh-el5.eng.rdu2.redhat.com/
> [4] https://lore.kernel.org/selinux/20131213195520.11231.81980.stgit@localhost/.
>
> - there is the issue of trusting the fuse filesystem for its labeling information and for domain/context transitions.  At the least, we'd need a permission check to gate which contexts a fuse filesystem could supply (e.g. the filesystem associate check), and by default nosuid mounts disable domain transitions (although it is possible to selectively allow them via nosuid_transition now).  Also, if a non-init user namespace mount, even if policy is configured to use xattrs (SECURITY_FS_USE_XATTR), we flip to using mountpoint labeling (i.e. implicit context= mount with the context derived from the mounter's context and matching type_transition rule if any) and we don't permit use of context mount options.

Re: [Virtio-fs] SELinux support in virtio-fs

[Casey Schaufler]

On 2/19/2020 8:44 AM, Stephen Smalley wrote:
> On 2/19/20 11:11 AM, Ondrej Mosnacek wrote:
>> On Wed, Feb 12, 2020 at 4:29 PM Daniel Walsh <dwalsh@redhat.com> wrote:
>>> 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
>>>
>>> I am traveling right now.  We should add in the SELinux team, and I will
>>> be able to look at this on Friday.
>>
>> Cc'ing the upstream SELinux mailing list for more insight. Here is a
>> public archive of the full thread:
>>
>> https://www.redhat.com/archives/virtio-fs/2020-February/msg00005.html

Also adding the LSM mailing list. This could be interesting for
any security module that uses extended attributes.

>
> FWIW, there were previous attempts to add FUSE support for per-file SELinux labeling (rather than just a single genfscon-based or context= mount option label for all files in the mount) but there were problems:
>
> - deadlock during mount with userspace waiting for mount(2) to complete and the kernel blocked on requesting the security.selinux xattr of the root directory as part of superblock setup during mount [1] [2].
> [1] https://lore.kernel.org/selinux/1280234607.4789.6.camel@moss-pluto.epoch.ncsc.mil/
> [2] https://lore.kernel.org/selinux/20120824195928.22970.16209.stgit@paris.rdu.redhat.com/
>
> - there was an attempt to introduce distinctions based on filesystem "subtype" so that whitelisted fuse filesystems could have xattr support enabled when it was known that their userspace would handle mount(2) safely [3] but this was apparently always broken and later reverted [4].
> [3] https://lore.kernel.org/selinux/20130416225619.GA30164@sh-el5.eng.rdu2.redhat.com/
> [4] https://lore.kernel.org/selinux/20131213195520.11231.81980.stgit@localhost/.
>
> - there is the issue of trusting the fuse filesystem for its labeling information and for domain/context transitions.  At the least, we'd need a permission check to gate which contexts a fuse filesystem could supply (e.g. the filesystem associate check), and by default nosuid mounts disable domain transitions (although it is possible to selectively allow them via nosuid_transition now).  Also, if a non-init user namespace mount, even if policy is configured to use xattrs (SECURITY_FS_USE_XATTR), we flip to using mountpoint labeling (i.e. implicit context= mount with the context derived from the mounter's context and matching type_transition rule if any) and we don't permit use of context mount options.