This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM

On Thu, 2007-05-17 at 23:56 -0400, Stefan Berger wrote:
> xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 05/11/2007 11:10:08 AM:
> > On Fri, 2007-05-11 at 14:32 +0100, Derek Murray wrote:
> > > On 9 May 2007, at 18:04, George S. Coker, II wrote:
> [...]
> > Currently the existing ACM module is implemented as a single XSM
> module
> > which stacks (internally) the Chinese Wall and Simple Type
> Enforcement
> > functionality.  (This is the preferred approach for stacking.)
> > is one module with the flexibility to enforce STE and/or CW policy.
> > 
> > The existing ACM was designed to be complementary to Xen's
> IS_PRIV().
> > Moving IS_PRIV() to the default/dummy XSM module does not alter this
> > relationship as the hooks used by ACM are orthogonal to the
> > hooks.  On init of the XSM (because ACM-XSM does not define
> replacements
> > for these IS_PRIV() hooks), the hooks from the dummy/default module
> are
> > integrated (or "shimmed") in to the ACM-XSM module.  So I think XSM
> can 
> If ACM-XSM does not define replacements for the IS_PRIV() hooks, how
> are you going to integrate them into ACM-XSM? If so, based on what
> information from the current ACM policy would ACM-XSM enforce the
> IS_PRIV() check? What if ACM is not active, what enforces IS_PRIV()
> then? 

I think I am being misunderstood here.  In this discussion, I have
suggested that we could move the management of the IS_PRIV() checks
under XSM.  If this were to happen, these checks would be managed as the
default behavior of the XSM dummy module as well as be the default
behavior of XSM when disabled.  If XSM is not enabled, Xen will still
behave as expected.

On initialization, XSM does a check of a module's defined hooks, if a
module does not define a hook, the equivalent hook from the dummy module
is registered.  With the exception of the domain_create hook, the hooks
used by ACM-XSM are orthogonal to IS_PRIV().  For domain_create, the
corresponding ACM-XSM hook would need to add an IS_PRIV() call under
this proposal.  For the other hooks not used by ACM-XSM, the XSM init
process registers the dummy hooks containing the default IS_PRIV()
checks.  This is how XSM works today, except that the default/dummy
hooks currently return "0".


Xen-devel mailing list