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