-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Itamar Heim wrote: >> From: libvir-list-bounces@xxxxxxxxxx [mailto:libvir-list- >> bounces@xxxxxxxxxx] 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. SELinux has to levels of flexibility here device/file labeling and booleans. Having virt-manager modifying the policy on the fly would be quite a bit more complicated. lvm should be handled just by setting the labels on the /dev/mapper/VolGroup00-LogVol00 For example. If this is labeled virt_image_t then qemu_t can read/write it. If it is default labeled to fixed_disk_device_t, then it will not be allowed. -----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----- -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list