[libvirt] Thoughts on svirt configuration files.

[Daniel J Walsh]

On 04/07/2009 03:27 PM, Daniel P. Berrange wrote:
> 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 ?
>
No I was thinking the user would specify the image label, and if 
dynamic, libvirt would assign the other three labels.

I guess a close approximation of this would be the 
/etc/selinux/targeted/context/users directory, where each file includes 
multiple context.

So we could add

/etc/selinux/targeted/context/virt/

default:
domain_label = system_u:system_r:svirt_t:s0
exclusive_image_label = system_u:object_r:svirt_image_t:s0
shared_image_label = system_u:object_r:svirt_image_t:s0
readonly_image_label = system_u:object_r:virt_content_t:s0

svirt_nonet_t:
domain_label = system_u:system_r:svirt_nonet_t:s0
exclusive_image_label = system_u:object_r:svirt_nonet_image_t:s0
shared_image_label = system_u:object_r:svirt_image_t:s0
readonly_image_label = system_u:object_r:virt_content_t:s0


The more I think about this, it might be a waste, though.  If we just 
change the libvirtd_t to allow the user to select a alternate 
domain_label and always set the images the same, it would probably work 
for most everyone.

For those that this does not work would have to use static labeling.


/etc/selinux/targeted/context/virtual_domain_context
default_domain_label = system_u:system_r:svirt_t:s0
exclusive_image_label = system_u:object_r:svirt_image_t:s0
shared_image_label = system_u:object_r:svirt_image_t:s0
readonly_image_label = system_u:object_r:virt_content_t:s0



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