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:23 +0100, Keir Fraser wrote:
> 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.
> 

We could easily move the IS_PRIV() checks to the default/dummy modules.
This would ensure that a static security policy is enforced either in
the XSM enabled/disabled cases or in the case of a security module
neglecting not to implement a specific hook.  In all cases, Xen would be
protected by some security policy.  This is how XSM is setup to behave
today, but it is up to the community to commit to making IS_PRIV() the
default XSM module.

Some review of the current hooks is needed to ensure that existing uses
of IS_PRIV() are completely covered.  I believe this is the case for
almost all of the XSM hooks.  In most code paths where there is an
IS_PRIV() call there is an XSM hook immediately following.  mmu_update
is perhaps an exception.  I believe the hook is in the right place to
control the use of mmu_update and probably does not require an extra
hook in set_foreigndom() but there is a side effect from
set_foreigndom() (FOREIGNDOM is set to some value in the absense of
IS_PRIV()) that must be dealt with in the mmu_update hook.



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