[libvirt] Thoughts on svirt configuration files.

[Daniel P. Berrange]

On Mon, Apr 06, 2009 at 03:05:57PM -0400, Daniel J Walsh wrote:
> Currently we do not want to hard code virtual image names into libvirt, 
> so libvirt and virtual-manager can use libselinux to get the default 
> image label and process label.  svirt_t and svirt_image_t.  The idea was 
> one policy writer might want his virtual images labeled differently than 
> another.
> 
> One problem with this is I added to interfaces one for the domain, and 
> one for the image label.  Now we realize we have other images.
> 
> We have
> 
> process Label        -     svirt_t:MCS
> Exclusive RW Image   -     svirt_image_t:MCS
> Shared RW Image      -     svirt_image_t:s0
> Read Only Image      -     virt_content_t:s0
> 
> So I am suggesting that we remove the virtual_image_context file and 
> allowing policy writers to define context in the virtual_domain_context 
> files but have multiple records and multiple fields.
> 
> Something like a space separated list where each field corresponds to above.
> 
> system_u:system_r:svirt_t:s0 system_u:object_r:svirt_image_t:s0 
> system_u:object_r:svirt_image_t:s0 system_u:object_r:virt_content_t:s0
> 
> Then you could add optional types with similar fields
> 
> system_u:system_r:svirt_nonet_t:s0 system_u:object_r:svirt_image_t:s0 
> system_u:object_r:svirt_image_t:s0 system_u:object_r:virt_content_t:s0

How would libvirt decide which of the records to use, or what the 
semantics of each were ? Or are you thinking this info  is just to
allow for verification of user supplied labels in the XML ?

> Since SELinux just returns a path, the virt team could choose the format 
> of the file if a space separated list is not addequate. (xml?) Name 
> Value Pairs?  Policy writers would have to enter the format that is chosen.

I'd favour using the simple config format we have for /etc/libvirt/libvirt.conf
handled by the src/conf.h APIs. This is actually originates from Xen where
it used /etc/xen/$GUEST config files, which were in fact python code. Our
parser basically allows a subset of just strings and lists, which seems 
like it'd be sufficent for this case, and also allow the SELinux python 
libs to easily read the files too

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