On Tue, Aug 12, 2008 at 09:20:41AM -0400, Daniel J Walsh wrote:
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.
That's not going to fly for VMs without disks in the host - either totally diskless VMs, or VMs using iSCSI/NFS network blockdevices / root FS. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|