[libvirt] Thoughts on svirt configuration files.
Daniel J Walsh
dwalsh at redhat.com
Wed Apr 8 13:43:36 UTC 2009
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
More information about the libvir-list
mailing list