[libvirt] Re: SELinux SVirt/Qemu problems with current qemu design.

[Itamar Heim]

> From: libvir-list-bounces at redhat.com [mailto:libvir-list-
> bounces at redhat.com] On Behalf Of Daniel J Walsh
> I think labeling can be done to allow the access to directories, and
> files.  So libvirt could go in an label a file/directory in such a way
> that the running qemu_t:s0.c10 can read or read/write the
> file/directory.
> 
> Same with the ability to create save images, as long as the labeling is
> correct.  The only problem I see here is the searching of the directory
> path to the location of the directories.  If we want to allow users to
> store files/directories anywhere, we end up having to allow qemu_t the
> ability to at least search every directory on the system, and
> potentially read them.   Having the ability to read a directory is
> sometimes valuable, for a hacker.
[IH] I don't see us avoiding per-vm policy. The policy has to be dynamic -
customized before launching qemu, and able to change during process
life-cycle for events like hot-plug and migration. I don't see the need
for the qemu process to change its permissions, since the managing libvirt
can change the policy during process life (I assume selinux policy can
change while a process is already running). The reason the policy has to
be created just before process launch is that the VM can be run on
different hosts, and I don't think it makes sense to synchronize the
policy of all possible guests on all hosts all the time (and the policy is
enforced at host level, not storage level for example). Also, we need to
cover the SAN use case, where each image is probably an LV in LVM.