[libvirt] Re: XML representation of security labels

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/