[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.