On Fri, Aug 29, 2008 at 06:00:36AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 29, 2008 at 01:32:27PM +1000, James Morris wrote:
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.
honnestly I lack expertise to assert the security value, but getting an idea of the kind of API would be nice to review.
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.
I guess so far we didn't look at the interpretation of security context in the case of migration to a different system. The problem is that except for the base UNIX informations, they are likely to be lost. Still i would expect that storage will have to be shared for such migration, so in the end the case of migration of security context values looks like quite unprobable, but maybe I don't see some of the use cases (heterogenous server pools ?)
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).
seems the status quo
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.
right in general we have been using element names for specifying the concepts and attributes values to explain the specifics.
</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>
that looks more homogeneous. i don't know hos that would map to other security models, examples would be great
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.
good point, that would be needed by the management tools Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/