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

<Prev in Thread] Current Thread [Next in Thread>