Re: [libvirt] [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-based virtualization
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