On Tue, Aug 12, 2008 at 10:16:35AM -0400, Daniel J Walsh wrote:
Daniel P. Berrange wrote:
On Tue, Aug 12, 2008 at 09:54:23AM -0400, Daniel J Walsh wrote:
On Tue, Aug 12, 2008 at 09:20:41AM -0400, Daniel J Walsh wrote:
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 We could store the label to run qemu for a particular image in the
Daniel P. Berrange wrote: libvirt database. But this mechanism would have to match up with the labeling on disk or remote storage.
Ok, one minor point worth mentioning is that libvirt does not have a general purpose database of configurations. The way VM configuration is stored is hypervisor-specific. In the Xen/OpenVZ/VMWware case we pass the config straight through to XenD which takes care of persisting it. In QEMU/LXC case we store the XML config files in /etc/libvirt.
Or you have rules that state if virtd_t wants to start an image labeled nfs_t it will use qemu_nfs_t
You could still use the MCS label to prevent processes from attacking each other, but if the remote storage does not support labelling you will not be able to prevent them from attacking each others image files.
We don't need to restrict ourselves to a single NFS type qemu_nfs_t/nfs_t. A single NFS server can export many directories each of which can be mounted with a different context.
Yes and no. The mountpoint can be labeled differently at the directory level I believe. So you would have to store each image in it's own directory and mount at that level in order for mount -o context to work.
Yes, that's what I actually meant - different directories on the NFS server for each set of disk images which need to be separated by security label.
Our guiding rule with libvirt is that for every capability we add, we need to come up with a conceptual model that is applicable to all virtualization drivers, even if we only implement it for one particular driver.
Isn't libvirt going to be execing q program like qemu_t to run xen images? If yes then this should all work with the defined mechanism.
Yes & no. In the Xen case, we pass the configuration ontop XenD. This talks to the hypervisor to create the virtual machine. Some Xen guests happen to have a QEMU process to provide an emulated device model, but this isn't required by Xen. We can however pass a security label to XenD and have it do the neccessary security work at VM creation time. 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 :|