On 5/31/21 4:42 PM, Darragh Bailey wrote: > Hi, > > On Thu, 27 May 2021 at 13:34, Michal Prívozník <mprivozn@xxxxxxxxxx> 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
