[libvirt] [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-based virtualization

[Daniel P. Berrange]

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