[libvirt] Re: XML representation of security labels
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/