Re: [PATCH v3 2/5] qemu: Introduce shared_filesystems configuration option
On Thu, May 09, 2024 at 17:51:59 +0100, Daniel P. Berrangé wrote:
On Thu, May 09, 2024 at 04:47:48PM +0000, Andrea Bolognani wrote:
> On Thu, May 09, 2024 at 05:10:50PM GMT, Peter Krempa wrote:
> > Now things I see as problem in case when NFS not supporting xattr is
> > used. This means that the remote VM can set XATTRs and must use
> > 'virt_use_nfs' sebool.
>
> I must be confused about the purpose of the virt_use_nfs sebool, and
> I can't seem to find decent documentation about it. Do you have any
> handy?
Out of the box, there usually is no ability for QEMU to access
files stored on NFS whatsoever, because NFS lacks support for
storing (svirt_image_t:MCS) labels in xattr.
Setting virt_use_nfs, toggles the policy such that QEMU can now
access *any* nfs_t file. This lets QEMU works on NFS lacking
label support, but at the cost of killing MAC protection against
any other non-VM related files that might be stored on NFS. DAC
protection still applies though, since we're not running QEMU
as root.
If an NFS deployment *does* support SELinux labels, there is
no reason to use virt_use_nfs, and it should not be used due
to reduced MAC protection.
So I've finally got around to test this with NFS-4.2 with "XATTR"
support. I used xattr in quotes, as per spec it seems that xattr support
over NFS is limited (per spec IIUC, and observably) to only handle the
'user' namespace of xattr labels. Any other namespace is _NOT_
available over NFS at least in default config. (The main point in the
docs seem to be that OSes may interpret the security labels in such
namespaces differently and NFS doesn't want to deal with attempting to
translate them in any shape or form (e.g. on linux we use the 'trusted'
namespace while on FreeBSD we use the 'system' namespace to remember
lables))
This means that neither 'selinux' labels nor the XATTRs libvirt uses to
remember the previous security labels are available on the other side of
migration.
This works (partially) correctly though, as either side of the migration
is handing the full lifecycle of the security label (even despite that
the storage doesn't transport them).
This means that on outgoing migration the source will remove the
reference on the xattr remembering the seclabels (without actually
restoring them). Destination would obviously attempt to take a reference
but can't as it's not supported. This means that xattrs are not leaked.
On incoming migration though there's an issue though. Libvirt tries to
apply (the same) seclabel, which is correct. This though involves also
an attempt to remember the owner, whcih succeeds, but remembers the
*active* seclabel. When the VM is then terminated that seclabel is
restored.
The above is _not_ a good reason to disable seclabel remembering though,
as suggested by docs added by this patch, even when it does in fact work
around that issue. We should rather fix the seclabel remembering code:
- for now by not trying to create the xattrs to remember the seclabel
when we're migrating in and the labels on the image are already
correct.
- in the future we perhaps could transfer the original seclabels in the
migration cookie
I'll be posting patches to address this before this series goes in, so
that the suggestion to disable 'remember_owner' globally can be dropped.
If an NFS deployment does *not* support SELinux labels, then
virt_use_nfs must be turned on
Based on the above, this is in fact needed even with NFS-4.2