
On 5/31/21 4:42 PM, Darragh Bailey wrote:
Hi,
On Thu, 27 May 2021 at 13:34, Michal Prívozník <mprivozn@redhat.com> wrote:
Disks can contain various secrets (passwords, certificates, private keys, etc.). Historically, libvirt set seclabel on anything that QEMU needed access to and then returned it to root:root when QEMU no longer needed it, exactly because we could not tell if some sensitive info was stored in a file or not.
With recent enough libvirt (5.6.0 or newer) libvirt remember the original seclabel (owner + SELinux label) and restores them afterwards. The mode is untouched though.
Does the typical SELinux label prevent other users on the system from reading the VM image file even if it has o+r set on it? I'm hazy enough on SELinux that I don't want to make any invalid assumptions.
Yes. That was one of the reasons why SELinux was invented, i.e. regular file perms and owners are not enough to guard host from a malicious program. The idea is that with SELinux one can fine tune what operations can given process do with what files. Libvirt utilizes this when spawning new QEMU/LXC/... by allowing new VM/container to access only those files (and resources in general) which are configured in the XML (plus some well known paths like /dev/null, /dev/zero, etc.). SELinux uses labels (stored in XATTRs usually) plus a DB of allowed labels and operations (referred to as policy). But there are other approaches too: for instance AppArmor has a list of allowed path+operation pairs stored in a file. Both approaches have their pros and cons.
I'd say that if somebody wants a disk to be "shared", e.g. readable by other users on the system, they can put <shareable/> stanza into disk XML. But then again - libvirt doesn't change the mode. So I think it's up to vagrant to decide.
Michal
I think requiring an explicit decision to share is probably the best approach and better to keep that as part of the requirements before enabling o+r on the mode. Thanks, that's a very useful suggestion.
Yep, being explicit about choices is usually the best way to go. Michal