On Fri, Aug 29, 2008 at 06:00:36AM +0100, Daniel P. Berrange wrote: > On Fri, Aug 29, 2008 at 01:32:27PM +1000, James Morris wrote: > > 1. We should probably not build security model specific code directly into > > the library. It's more flexible and also cleaner to abstract the security > > model out. So, I suggest making a plugin scheme similar to those already > > present in libvirt, where a security model can register a driver to handle > > abstracted operations like "getSecurityLabel". > > Sounds like a reasonable idea. At very least Solaris won't be using SELinux > but their own equivalent. honnestly I lack expertise to assert the security value, but getting an idea of the kind of API would be nice to review. > > 2. The XML format for security labels needs to be extended to indicate > > which security model is in use, and potentially carry model-specific > > metadata. For SELinux, we may want to know what type of policy is active, > > and later, be able to interpret labels generated on other systems. I guess so far we didn't look at the interpretation of security context in the case of migration to a different system. The problem is that except for the base UNIX informations, they are likely to be lost. Still i would expect that storage will have to be shared for such migration, so in the end the case of migration of security context values looks like quite unprobable, but maybe I don't see some of the use cases (heterogenous server pools ?) > > > In this case, I suggest we deprecate the existing label element and, if > > present, assume it's a plain SELinux context (or perhaps ignore it). seems the status quo > > I'd suggest we implement a new label element to avoid breaking > > compatibility and to avoid potential confusion with other types of device > > labels (e.g. as you might see via /dev/disk/by-label). > > > > So, how about the following: > > > > <seclabel> > > > > <model> > > > > <!-- model-specific elements in here, to be handled by > > named security driver, in this case "selinux" --> > > <selinux> > > <type>targeted</type> > > </selinux> > > I'd rather not have security model specific XML element names if > practical. We've tried to keep to a naming that is conceptually > generic, even if it only has 1 implementation. right in general we have been using element names for specifying the concepts and attributes values to explain the specifics. > > > </model> > > > > <value>system_u:object_r:virt_image_t:s0</value> > > Since the interpretation of the 'value' element's contents > depends on the type of security model, I think the type > is better designated on the parent 'seclabel' element. > > > > > </seclabel> > > Would this be sufficient... > > <seclabel model='selinux'> > <policy>targeted</policy> > <value>system_u:object_r:virt_image_t:s0</value> > </seclabel> that looks more homogeneous. i don't know hos that would map to other security models, examples would be great > I imagine the 'virConnectGetCapabilites()' XML output may well want > to specify more detailed metadata about the system's currently > active security model & its config. One obvious thing would be the > name & version of the policy that is loaded. So if you had a storage > volume description indicating seclabel wrt the 'targeted' policy, > you could check the host capabilities to ensure the host is actually > running the 'targeted' policy and not something else entirely. good point, that would be needed by the management tools Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list