Re: [libvirt] Thoughts on svirt configuration files.
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