[libvirt] Re: XML representation of security labels

[Daniel P. Berrange]

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