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