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

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

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
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

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