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 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