[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Hash: SHA1

Itamar Heim wrote:
>> From: libvir-list-bounces redhat com [mailto:libvir-list-
>> bounces 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.
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


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.

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]