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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

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.

Ian.


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