[libvirt] Re: XML representation of security labels
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 :|