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

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.

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