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

[Michal Prívozník]

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