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
