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

[Keir Fraser <keir@xxxxxxxxxxxxx>]

On 8/3/07 18:08, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx> wrote:

> The check on send, enables for the flask module the creation of a one-
> way event channel.  Flask can check whether A can send to B, but this
> does not imply that B can send to A.  The primary value for this check
> is in the construction of one-way information flows.

Fair enough.

> The pirq bindings are meant to protect the hypervisor against abuse by
> the control-plane, thereby ensuring that the control-plane cannot setup
> resource bindings that are prohibited by the policy.  The control-plane
> in this argument is decomposed or deprivileged by the running policy
> such that it is unable to cause a policy reload and circumvent these
> checks.

You can restrict this via the iocaps mechanism, and I'll bet you already
include a hook that could prevent the domain from modifying its own iocaps
in a disallowed way. :-)

> While the virq/ipi have local-domain scope, it is in the interest of
> comprehensiveness that this hooks exists.  For a domain running a
> general purpose OS, this hook has little value since anything checked
> here will always likely need to be granted.  However, light-weight
> domains for which the enforced policy could be justifiably more
> restrictive, would benefit from this hook.

I don't think this is true. Same applies to evtchn_close(): another entirely
local VM operation. It seems outside the scope of XSM policy to be hooking
those. If you were to go this route then wouldn't you essentially be arguing
for interception of *every* hypercall subcommand?

> Separate hooks does not necessarily mean separate permissions - the
> breakdown of permissions is module dependent.  Separate hooks allows for
> a narrower per-hook interface (ensuring that the hooks are unlikely to
> be abused for non-security purposes) and makes it unlikely that a given
> hook will be separated from or lose context with the critical code path.

If new critical code paths are added then XSM could end up with a set of
critical paths that it doesn't hook at all. That would be less of a problem
if the hooks aren't pushed way down into hypercall subcommands. I guess you
can argue this one either way. With this scheme you don't end up having to
demux the hypercall subcommands in every XSM module implementation.

 -- Keir


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