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

[Keir Fraser <keir@xensource.com>]

On 9/5/07 15:04, "Derek Murray" <Derek.Murray@cl.cam.ac.uk> 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