[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Thoughts on svirt configuration files.



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

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.

Thoughts?

I am thinking we might eventually want to allow an admin to select dynamic labels but specify alternative types.

So svirt_t would be default but if someone wanted svirt_nonet_t, they could choose that also and get separation with a different type.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]