On Fri, Aug 29, 2008 at 01:32:27PM +1000, James Morris wrote: > There is already some support for querying security labels in libvirt, > although it does not seem to be widely used as yet. Indeed - I'm not aware of any apps using it yet. It is currently only of marginal benefit, since you can't actually set the label, only see the existing (potentially wrong) label. > For storage pool XML descriptors, there's a permissions element per > http://libvirt.org/formatstorage.html : > > <permissions> > <owner>0744</owner> > <group>0744</group> > <mode>0744</mode> > <label>virt_image_t</label> > </permissions> > > The label element in this is currently assumed by libvirt to be an SELinux > security label obtainable via getfilecon(3). > There are a couple of issues here: > > 1. We should probably not build security model specific code directly into > the library. It's more flexible and also cleaner to abstract the security > model out. So, I suggest making a plugin scheme similar to those already > present in libvirt, where a security model can register a driver to handle > abstracted operations like "getSecurityLabel". Sounds like a reasonable idea. At very least Solaris won't be using SELinux but their own equivalent. > 2. The XML format for security labels needs to be extended to indicate > which security model is in use, and potentially carry model-specific > metadata. For SELinux, we may want to know what type of policy is active, > and later, be able to interpret labels generated on other systems. > In this case, I suggest we deprecate the existing label element and, if > present, assume it's a plain SELinux context (or perhaps ignore it). > > I'd suggest we implement a new label element to avoid breaking > compatibility and to avoid potential confusion with other types of device > labels (e.g. as you might see via /dev/disk/by-label). > > So, how about the following: > > <seclabel> > > <model> > > <!-- model-specific elements in here, to be handled by > named security driver, in this case "selinux" --> > <selinux> > <type>targeted</type> > </selinux> I'd rather not have security model specific XML element names if practical. We've tried to keep to a naming that is conceptually generic, even if it only has 1 implementation. > </model> > > <value>system_u:object_r:virt_image_t:s0</value> Since the interpretation of the 'value' element's contents depends on the type of security model, I think the type is better designated on the parent 'seclabel' element. > > </seclabel> Would this be sufficient... <seclabel model='selinux'> <policy>targeted</policy> <value>system_u:object_r:virt_image_t:s0</value> </seclabel> I imagine the 'virConnectGetCapabilites()' XML output may well want to specify more detailed metadata about the system's currently active security model & its config. One obvious thing would be the name & version of the policy that is loaded. So if you had a storage volume description indicating seclabel wrt the 'targeted' policy, you could check the host capabilities to ensure the host is actually running the 'targeted' policy and not something else entirely. > The model and value elements would be mandatory, but possibly empty. > > The seclabel element would be a child of the permissions element: > > <permissions> > <owner>0744</owner> > <group>0744</group> > <mode>0744</mode> > <seclabel> > <model> > <selinux> > <type>targeted</type> > </selinux> > </model> > <value>system_u:object_r:virt_image_t:s0</value> > </seclabel> > </permissions> > > It would also likely be reused for labeling domains themselves, and other > resources. 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