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

[Daniel P. Berrange]

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.

> I think libvirt being SELinux aware and have it decide which context to
> run qemu at is the important point.
> 
> The arguement about whether it needs to store the SELinux label in its
> database or base it off the label of the image can be hashed out later.

So the important thing is that the label is represented in the libvirt
XML format, and this XML config is persisted in a manner which is most
applicable for the virtualization driver in question. While I know James
wants to target KVM primarily, we need make sure the approach we take 
doesn't paint ourselves into a corner wrt supporting other virt platforms
like Xen.

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.

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