[libvirt] Re: [RFC] sVirt v0.10 - initial prototype

Paul Moore paul.moore at hp.com
Thu Oct 23 12:05:39 UTC 2008


On Wednesday 22 October 2008 5:23:45 am James Morris wrote:
> On Tue, 21 Oct 2008, Daniel J Walsh wrote:
> > Why do we care about the policy type?  Policy type is a fairly
> > meaningless object.  If you are trying to figure out if the host
> > machine is valid to run a virtual machine you should just check
> > whether the type is valid on the machine,  That way if I define
> > minimum policy with virt support on one host and targeted policy
> > with virt support on another machine, both would work.
>
> We need a way to indicate how to interpret the meaning of labels,
> which may vary depending on how policy has been implemented and
> deployed within a specific administrative boundary.  Keep in mind
> also that this API needs to be useable with non-SELinux security
> schemes, although, in any case, just because a label is technically
> valid on a system, doesn't mean that the meaning is understood.  e.g.
> "virt_image_t:s0" on a targeted system could mean something radically
> different to "virt_image_t:s0" on an MLS system, where, say, "s0"
> might mean "top secret" instead of "nothing".
>
> Perhaps we should call this element "doi" (Domain of Interpretation)
> instead of "policytype", in keeping with existing similar security
> labeling, and not tied in name to the SELinux polictype configuration
> variable.
>
> I thought the SELinux policytype in this case would be a useful
> starting point for the DOI, although the truth is that this needs to
> be entirely administratively managed.  We can't predict where
> administrative security boundaries will be or how the user will
> represent them.  Possibile DOI schemes include domain name, policy
> package+version names, existing kerberos realms etc.

I like the concept of a DOI field instead of policy type; considering 
the portability of guest images this seems like a good solution based 
on the relative success of DOIs in other distributed applications.

However, may I suggest that instead of representing the DOI as a string 
we use a 32bit integer?  I know that may sound a bit odd, but in the 
networking world most DOI values are represented as integers and when 
security labels are involved they tend to be 32bits.  I understand that 
using a plain integer is much more abstract than a human readable 
string but it should make it easier to leverage existing and future* 
DOI frameworks.

*An informal group/list just formed to start discussing DOI management 
issues such as DOI formats, negotiation and translation.

-- 
paul moore
linux @ hp




More information about the libvir-list mailing list