selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [selinux-internal] SELinux support in virtio-fs
       [not found] ` <bbcbd9a0-a036-1c1e-ed66-ac2aaca454a5@redhat.com>
@ 2020-02-19 16:11   ` Ondrej Mosnacek
  2020-02-19 16:44     ` Stephen Smalley
  0 siblings, 1 reply; 3+ messages in thread
From: Ondrej Mosnacek @ 2020-02-19 16:11 UTC (permalink / raw)
  To: Daniel Walsh; +Cc: Stefan Hajnoczi, virtio-fs, SElinux list

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: SELinux support in virtio-fs
  2020-02-19 16:11   ` [selinux-internal] SELinux support in virtio-fs Ondrej Mosnacek
@ 2020-02-19 16:44     ` Stephen Smalley
  2020-02-19 17:50       ` Casey Schaufler
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Smalley @ 2020-02-19 16:44 UTC (permalink / raw)
  To: Ondrej Mosnacek, Daniel Walsh; +Cc: Stefan Hajnoczi, virtio-fs, SElinux list

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: SELinux support in virtio-fs
  2020-02-19 16:44     ` Stephen Smalley
@ 2020-02-19 17:50       ` Casey Schaufler
  0 siblings, 0 replies; 3+ messages in thread
From: Casey Schaufler @ 2020-02-19 17:50 UTC (permalink / raw)
  To: Stephen Smalley, Ondrej Mosnacek, Daniel Walsh
  Cc: Stefan Hajnoczi, virtio-fs, SElinux list, Linux Security Module list

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-02-19 17:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200210160639.GA411895@stefanha-x1.localdomain>
     [not found] ` <bbcbd9a0-a036-1c1e-ed66-ac2aaca454a5@redhat.com>
2020-02-19 16:11   ` [selinux-internal] SELinux support in virtio-fs Ondrej Mosnacek
2020-02-19 16:44     ` Stephen Smalley
2020-02-19 17:50       ` Casey Schaufler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).