[libvirt] [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-based virtualization
Daniel J Walsh
dwalsh at redhat.com
Tue Aug 12 13:20:41 UTC 2008
James Morris wrote:
> On Tue, 12 Aug 2008, Daniel P. Berrange wrote:
>
>> Do we instead add the info the udev rules, so when /dev is
>> populated at boot time by udev the device nodes get the desired
>> initial labelling ? Or do we manually chcon() the device
>> at the time we boot the VM ?
>
> Dan Walsh has mentioned wanting to label the device at VM launch so that
> MCS labels can be dynamically assigned. This raises some other possible
> issues such as revoking any existing access (Linux doesn't have general
> revocation) and having the security of the system depend on whatever is
> performing the relabel (although we can enforce relabelfrom/relabelto
> permissions).
>
> I wonder if existing work/concepts related to MLS device allocation would
> be useful here.
>
> See:
> http://sourceforge.net/projects/devallocator/
>
>
> - James
The experimenting I have done has been around labeling of the virt_image
and the process with mcs labels to prevent one process from touching
another process/image with a different MCS label.
system_u:system_r:qemu_t:s0:c1 can read/write
system_u:system_r:virt_image_t:s0:c1
But can not read/write system_u:system_r:virt_image_t:s0:c2
or communicate with process system_u:system_r:qemu_t:s0:c2
The idea would be to have libvirt look at the labeling of the image file
and lauch the qemu process with the correct type and matching MCS label.
So a more advanced image might be labeled
system_u:system_r:virt_image_nonet_t:s0:c1
and libvirt would launch system_u:system_r:qemu_nonet_t:s0:c2
I have not looked into which devices on the host machine might need
higher levels of protection.
In Fedora 9/Rawhide libvirt runs as virtd_t and has a transition rule on
qemu_exec_t to qemu_t. So all virtual machines run with
system_u:system_r:qemu_t:s0
More information about the libvir-list
mailing list