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