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" 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. Thanks Vivek > or is is subject to > xattr remapping that virtiofsd already supports. > > Storing directly means virtiofsd has to run in an essentially > unconfined context, to let it do arbitrary changes on security.* > xattrs without being blocked by SELinux) and has risk that guest > initiated changes can open holes in the host confinement if > the exported FS is generally visible to processes on the host. > > > Using remapping lets virtiofsd be strictly isolated by SELinux > policy on the host, and ensures that guest context changes > can't open up holes in the host. > > Both are valid use cases, so I'd ultimately expect us to want > to support both, but my preference for a "default" behaviour > would be remapping. > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| >