From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH] libxl: assigned a default ssid_label (XSM label) to guests Date: Mon, 18 May 2015 18:37:32 -0400 Message-ID: <555A69AC.6080603@tycho.nsa.gov> References: <1431599625-9572-1-git-send-email-ian.campbell@citrix.com> <55548553.7060700@citrix.com> <1431604483.13579.60.camel@citrix.com> <55552B0E.8050807@tycho.nsa.gov> <1431682741.8943.45.camel@citrix.com> <1431952728.4944.51.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1431952728.4944.51.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Julien Grall , ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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