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.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkluVyMACgkQrlYvE4MpobPu2QCg5HB5U1DsFa3gTnb+T78dj2iT hPoAn21jAg46ohyybQhwoJrjihR6puU5 =Ew2C -----END PGP SIGNATURE-----