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

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.