Re: Recommended volume permissions (being created for vagrant-libvirt via fog-libvirt)
On 5/31/21 4:42 PM, Darragh Bailey wrote:
Hi,
On Thu, 27 May 2021 at 13:34, Michal Prívozník <mprivozn(a)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