[Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7)

[Daniel Walsh]

On 7/13/20 04:54, Chirantan Ekbote wrote:
> On Thu, Jun 25, 2020 at 9:55 PM Vivek Goyal <vgoyal at redhat.com> wrote:
>> On Thu, Jun 25, 2020 at 12:19:39PM +0900, Chirantan Ekbote wrote:
>> [..]
>>>> Chirantan,
>>>>
>>>> So you ended up renaming all "trusted", "security" and "system" xattrs?
>>>> Only "user" xattrs are complete passthrough?
>>>>
>>> No, we only rename "security" xattrs (except for selinux).
>>>
>>>> IOW, security.selinux will be renamed to user.virtiofs.security.selinux
>>>> on host?
>>>>
>>> We don't relabel security.selinux because it only requires CAP_FOWNER
>>> in the process's user namespace and it also does its own MAC-based
>>> checks.  Also we have some tools that label files beforehand so it
>>> seemed easier to leave them unchanged.
>> If we rename selinux xattr also, then we can support selinux both in
>> guest and host and they both can have their own independent policies.
>>
> This works as long as you don't need to support setfscreatecon, which
> exists to guarantee that an inode is atomically created with the
> correct selinux context.  It's kind of possible for files with
> O_TMPFILE + fsetxattr + linkat but there is no equivalent for
> directories.  You're basically forced to create the directory and then
> set the xattr and while it's possible to prevent other threads in the
> server from seeing the unfinished directories with a rwlock or similar
> there is no protection against power loss.  If the machine loses power
> after the directory is created but before the selinux xattr is set
> then that directory will have the wrong selinux context and the guest
> would need to run restorecon at boot to assign the correct label.
>
>> Otherwise we either have to disable selinux on host (if we want to
>> support it in guest) or somehow guest and how policies will have
>> to know about each other and be able to work together (which will
>> be hard for a generic use case).
> Yes, I agree this is hard to do for a generic case but unfortunately
> the more I understand how selinux works the less I feel that it works
> well with a passthrough style file system.  As you said it either
> needs to be turned off on the host or the host and guest need to work
> together.

Correct both kernels need to understand the labels, or one of the
kernels has to have SELinux disabled.

That is the bottom line.  Same issue exists for labeled NFS so I don't
see this as a problem.

> Chirantan
>
> _______________________________________________
> Virtio-fs mailing list
> Virtio-fs at redhat.com
> https://www.redhat.com/mailman/listinfo/virtio-fs