WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

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

To: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Thu, 17 May 2007 23:56:57 -0400
Cc: Derek Murray <Derek.Murray@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 17 May 2007 20:55:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1178896208.6520.171.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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.)  ACM-XSM
> 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 IS_PRIV()
> 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?

   Stefan

> do what you and Keir are suggesting.



>
> > Thanks for your input on this, and if I can be of any more help,  
> > please let me know.
> >
> > Regards,
> >
> > Derek Murray.
> --
> George S. Coker, II <gscoker@xxxxxxxxxxxxxx> 443-479-6944
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel