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

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. >> >> 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 argument 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