[Virtio-fs] [PATCH v5 0/9] virtiofsd: Add support for file security context at file creation

[German Maglione]

On Tue, Feb 8, 2022 at 11:44 PM Daniel P. Berrangé <berrange at redhat.com>
wrote:

> On Mon, Feb 07, 2022 at 04:19:38PM -0500, Vivek Goyal wrote:
> > On Mon, Feb 07, 2022 at 01:05:16PM +0000, Daniel P. Berrangé wrote:
> > > On Wed, Feb 02, 2022 at 02:39:26PM -0500, Vivek Goyal wrote:
> > > > Hi,
> > > >
> > > > This is V5 of the patches. I posted V4 here.
> > > >
> > > >
> https://listman.redhat.com/archives/virtio-fs/2022-January/msg00041.html
> > > >
> > > > These will allow us to support SELinux with virtiofs. This will send
> > > > SELinux context at file creation to server and server can set it on
> > > > file.
> > >
> > > I've not entirely figured it out from the code, so easier for me
> > > to ask...
> > >
> > > How is the SELinux labelled stored on the host side ? It is stored
> > > directly in the security.* xattr namespace,
> >
> > [ CC Dan Walsh ]
> >
> > I just tried to test the mode where I don't do xattr remapping and try
> > to set /proc/pid/attr/fscreate with the context I want to set. It will
> > set security.selinux xattr on host.
> >
> > But write to /proc/pid/attr/fscreate fails if host does not recognize
> > the label sent by guest. I am running virtiofsd with unconfined_t but
> > it still fails because guest is trying to create a file with
> > "test_filesystem_filetranscon_t" and host does not recognize this
> > label. Seeing following in audit logs.
> >
> > type=SELINUX_ERR msg=audit(1644268262.666:8111): op=fscreate
> invalid_context="unconfined_u:object_r:test_filesystem_filetranscon_t:s0"
>
> Yes, that's to be expected if the host policy doesn't know about the
> label that the guest is using.
>
> IOW, non-mapping case is only useful if you have a very good match
> between host + guest OS policy. This could be useful for an app
> like Kata because their guest is not a full OS, it is something
> special purpose and tightly controlled.
>
> > So if we don't remap xattrs and host has SELinux enabled, then it
> probably
> > work in very limited circumstances where host and guest policies don't
> > conflict. I guess its like running fedora 34 guest on fedora 34 host.
> > I suspect that this will see very limited use. Though I have put the
> > code in for the sake of completeness.
>
> For general purpose guest OS virtualization remapping is going to be
> effectuively mandatory.  The non-mapped case only usable when you tightly
> control the guest OS packages from the host.
>


If remap is recommended, why not make it mandatory or automatic?,
for instance, '-o security_label' either requires '-o xattrmap=' or
automatically makes
the mapping with the 'trusted' prefix, while  '-o security_label=nomap'
doesn't, so you
can choose whatever you want.

(I'm not suggesting the 'nomap' name, I'm terrible choosing names)

-- 
German
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20220209/a36e4c72/attachment.htm>