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 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
