Recommended volume permissions (being created for vagrant-libvirt via fog-libvirt)

Michal Prívozník mprivozn at redhat.com
Thu May 27 12:34:22 UTC 2021


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




More information about the libvir-list mailing list