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 :|