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@lists.xen.org
http://lists.xen.org/xen-devel
