|
xense-devel
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.
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
|
|
|
Home