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: > >> Daniel P. Berrange 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 > >> 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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list