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

[Derek Murray <Derek.Murray@xxxxxxxxxxxx>]

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.

Attachment: IS_PRIV_report.txt
Description: Text document

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

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 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.
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.
Thanks for your input on this, and if I can be of any more help,  
please let me know.
Regards,

Derek Murray.

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