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
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list