RE: [libvirt] Re: SELinux SVirt/Qemu problems with current qemu design.
From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-
bounces(a)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.