Re: [Xen-devel] [PATCH] libxl: assigned a default ssid_label (XSM label) to guests

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 05/18/2015 08:38 AM, Ian Campbell wrote:
> On Fri, 2015-05-15 at 10:39 +0100, Ian Campbell wrote:
> > > The header file defining these SIDs is buried in the hypervisor source
> > > tree (xen/xsm/flask/include/flask.h) and is only generated during a build
> > > with XSM enabled.  It may be simpler to define the value in a shared header
> > > and add a BUILD_BUG_ON somewhere in the flask code to check for mismatches.
> > I was about to ask about this. Short of a pretty serious change to the
> > build a BUILD_BUG_ON seems like a reasonable approach.
> To what extent is a user's customized (e.g. potentially clean room
> implemented) policy required to match what goes on here? I suspect the
> answer is "fully" and that any custom policy must therefore use exactly
> the policy/security_classes and policy/initial_sids as was used when Xen
> was built.
When rewriting the security policy, xen/xsm/flask/policy/initial_sids is
expected to remain unchanged, while tools/flask/policy/policy/initial_sids
can be modified to suit the types defined in the rewritten policy.  This
applies to all the files split between the two directories.

> If this coupling already exists then I see no particular harm in
> extending it to the tools as well, although I think I might see about
> making the header available for checking even in non-xsm builds (since I
> don't really want to add an xsm compile time option to the tools, nor to
> rely on the xsm builds catching errors for non-xsm usage).
>
> BTW, I seem to have two of each of security_classes and initial_sids in
> my tree, one in tools/flask/policy/policy/ and the other in
> xen/xsm/flask/policy/ and they appear to differ.
>
> The xen initial_sids appears to be derived from the tools one, whereas
> security_classes looks different.
The security_classes and access_vectors in the local policy (tools/...)
are intended to be used by components outside the hypervisor that do not
implement their own security policy.  The current example policy defines
a class for xenstore permissions, but since xenstore does not actually
use this, it is just an example.

--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel