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 <[email protected]> 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/[email protected]/ > [2] > https://lore.kernel.org/selinux/[email protected]/ > > - 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/[email protected]/ > [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. _______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
