[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 9/5/07 15:04, "Derek Murray" <Derek.Murray@xxxxxxxxxxxx> wrote:

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

Better to get rid of the IS_PRIV() altogether? If we're adding these hooks
all over the place we may as well get some benefit from them, even if it
means adding extra ones. Only question then is whether conflating security
constraints required for correct operation of the Xen platform (i.e.,
capabilities of the disaggregated dom0 domains) with the constraints
required for domU's, and trying to express these in the same security policy
module actually makes sense. It might make sense to 'shim in' a static
built-in policy at those hook points as a pre-filter on the
dynamically-loaded policy for ordinary domUs.

 -- Keir


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.