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