Recommended volume permissions (being created for vagrant-libvirt via fog-libvirt)
Hi, A request has come up recently in vagrant-libvirt about changing the permissions used for the VM volume image file. Currently there is a backing image file uploaded that gets 744 as the file permissions, and then the VM domain is created using this as the backing file for any changes. The file containing the changes for the VM gets 600, so accessing what is contained is limited to libvirt and thus to those that can connect to libvirt. The request is to change this to be 744, it appears to have been triggered due to a desire to try and use virt-v2v to create a portable XML and export the disks. However I'm a little hesitant as in general I would default to more secure rather than less secure to avoid creating security concerns down the line. Even though vagrant-libvirt is typically used for development, it wouldn't surprise me to see it being used on CI build infrastructure and given the shared nature of that, making things less secure may cause issues for some users. Of course working out who would be impacted is virtually impossible without making the change and seeing who is concerned. And that might be several months down the line before it's raised. Rather than just merging this, wondering if there are any security guidelines on the file permissions for VM image files? That or something that can outline the risks, or even clarify that it's unnecessary to worry about? -- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool"
On 5/25/21 6:50 PM, Darragh Bailey wrote:
Hi,
A request has come up recently in vagrant-libvirt about changing the permissions used for the VM volume image file.
Currently there is a backing image file uploaded that gets 744 as the file permissions, and then the VM domain is created using this as the backing file for any changes. The file containing the changes for the VM gets 600, so accessing what is contained is limited to libvirt and thus to those that can connect to libvirt.
The request is to change this to be 744, it appears to have been triggered due to a desire to try and use virt-v2v to create a portable XML and export the disks.
However I'm a little hesitant as in general I would default to more secure rather than less secure to avoid creating security concerns down the line. Even though vagrant-libvirt is typically used for development, it wouldn't surprise me to see it being used on CI build infrastructure and given the shared nature of that, making things less secure may cause issues for some users. Of course working out who would be impacted is virtually impossible without making the change and seeing who is concerned. And that might be several months down the line before it's raised.
Rather than just merging this, wondering if there are any security guidelines on the file permissions for VM image files? That or something that can outline the risks, or even clarify that it's unnecessary to worry about?
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. 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
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.
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. -- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool"
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
participants (2)
-
Darragh Bailey -
Michal Prívozník