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

["George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>]

On Wed, 2007-05-09 at 15:04 +0100, Derek Murray wrote:
> I'm interested in whether this code could be used to supersede IS_PRIV 
> (dom), particularly when doing an mmu_update operation.
> 
> As far as I can see, the xsm_mmu_normal_update() hook is called after  
> set_foreigndom(). set_foreigndom() will fail if the calling domain is  
> not privileged (!IS_PRIV(current->domain)) and the operation  
> specifies a different domain as the foreigndom.
> 
> For disaggregation of the domain builder, we would like to be able to  
> delegate this privilege to a small, trusted domain (domB): it seems  
> to me that XSM would be the cleanest way to do this. Would it  
> therefore be possible to add a hook in set_foreigndom() on the ! 
> IS_PRIV(d) branch, or is there some security consequence that I am  
> overlooking?
> 

I believe we have similar goals here.  It should be possible through the
XSM framework and the Flask-XSM module to define a policy that enables a
fine grain usage model such as disaggregation of the domain builder as
well as others.  The benefit to Flask-XSM is the flexibility provided is
completely general as it is derived through definition of a policy not a
specific module.

I realize my posts here may be out of order, but look on in this same
thread at my other posts regarding management of IS_PRIV() under the XSM
default/dummy module.

I encourage you to look at the existing hooks and see if the interfaces
are suitable for your work as well as determine the kinds of policy you
would like to enforce in the hooks.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel