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

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

On Fri, 2007-05-11 at 14:32 +0100, Derek Murray wrote:
> On 9 May 2007, at 18:04, George S. Coker, II wrote:
> > 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.
> 
> I've checked through changeset 15011 with your latest XSM patchset,  
> and looked at each instance of IS_PRIV(). I've attached the report  
> with this message.
> 
> 
> The uses of IS_PRIV() boil down to a few categories:
> 
> 1. Allow privileged domain only.
> 2. Allow self and privileged domain only.
> 3. set_foreigndom()
> 4. Allow self only, but with a different return code (EINVAL instead  
> of EPERM) for privileged domain.
> 5. Make no access control decision; instead use IS_PRIV() to modify a  
> register value.
> 
> The presence of XSM hooks can also be categorised:
> 
> 1. IS_PRIV() directly followed by XSM hook.
> 2. IS_PRIV() at start of do_*_op function, followed by XSM hooks for  
> the individual cases.
> 3. IS_PRIV() at start of list-processing function, followed by XSM  
> hook for each item in the list.
> 4. IS_PRIV() followed by no XSM hook (mostly in IA64 code).

We're not there yet for IA64, but we will be....any testers out there?
So I think XSM is "there" for all of the IS_PRIV uses, with the
exception of set_foreigndom() and modification of a register value in
traps.c.  (I honestly haven't spent any time thinking about the XSM
equivalent to the use of IS_PRIV in traps.c)

> The untidiest cases are where set_foreigndom() is involved. These  
> involve do_mmu_update(), do_update_va_otherdomain() and some  
> mmuext_ops. In particular, on the do_update_va_otherdomain() path,  
> IS_PRIV is checked twice. It would seem to me that the cleanest way  
> to do this is to have the permission check first (can domain X access  
> MFN Y of domain Z?), then carry out the set_foreigndom() logic.
> 

I think I agree.

> I am unsure about the location of the xsm_mmu_normal_update() hook.  
> What sort of policy do you envisage being enforced here? In  
> particular, the hook is based on the current domain and the value  
> that is to be written into the page table. In mod_l1_entry(),  
> get_page_from_l1e() is called, which ensures that the page belongs to  
> FOREIGNDOM, so would it be possible just to place the hook before  
> set_foreigndom()? This would have the added benefit of fewer calls to  
> the hook, when multiple updates have been batched together.
> 
> I am assuming that there are no latent examples of privilege-as-being- 
> dom0 in the code, but I haven't confirmed this.

I believe you are correct, although this was not always the case, I think.  

> On 9 May 2007, at 18:13, George S. Coker, II wrote:
> > 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.
> 
> It sounds to me that Flask-XSM provides the flexibility that would be  
> needed for defining a disaggregation policy. I wonder, though,  
> whether the Chinese Wall and Simple Type Enforcement ACM modules  
> (which, if I understand correctly, are separate Xen Security Modules  
> in this framework) would best be written with the IS_PRIV()- 
> replacement code separated out into a "shim" policy as Keir suggested  
> in this thread. Perhaps these modules should delegate to the dummy  
> policy, and, if they pass these hooks, then try the dynamic policy?  
> This would ensure that the Xen static privilege code is in a single  
> location and would hence be kept consistent.
> 
Currently the existing ACM module is implemented as a single XSM module
which stacks (internally) the Chinese Wall and Simple Type Enforcement
functionality.  (This is the preferred approach for stacking.)  ACM-XSM
is one module with the flexibility to enforce STE and/or CW policy.

The existing ACM was designed to be complementary to Xen's IS_PRIV().
Moving IS_PRIV() to the default/dummy XSM module does not alter this
relationship as the hooks used by ACM are orthogonal to the IS_PRIV()
hooks.  On init of the XSM (because ACM-XSM does not define replacements
for these IS_PRIV() hooks), the hooks from the dummy/default module are
integrated (or "shimmed") in to the ACM-XSM module.  So I think XSM can
do what you and Keir are suggesting.

> Thanks for your input on this, and if I can be of any more help,  
> please let me know.
> 
> Regards,
> 
> Derek Murray.
-- 
George S. Coker, II <gscoker@xxxxxxxxxxxxxx> 443-479-6944


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