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

["George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>]

On Thu, 2007-03-08 at 16:21 +0000, Keir Fraser wrote:
> On 8/3/07 15:28, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx> wrote:
> 
> > The hooks implemented by this patch provide a framework for security
> > modules to interpose and complement the existing privileged hypercall
> > operationsin xen as well as interpose on the discretionary operations
> > between domains.
> 
> I guess the primary question here is whether the set of hooks is reasonable.
> The approach here seems to be comprehensive, to say the least.
> 
> For example, do we envisage policies where it is not only desirable to
> interpose at event-channel binding time (particularly for interdomain
> channels) but also on every send? 

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.

> Do you need to interpose on all types of
> bindings? Interposing on interdomain bindings is obviously required, but
> virq/pirq/ipi seem pretty dubious to me: virq/ipi bindings have only
> local-domain scope, and protection of physical resources (like pirqs) is
> already done via io capabilities.
> 

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.

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 admit the value is
unproven for Xen today. ;)

> Picking another example, is it useful to distinguish between the different
> ways that a domain can act on the visible state of an HVM guest. For
> example, you have hooks for setting pci link routes, and changing isa and
> pci intx interrupt levels (as separate hooks!): it seems to me that some
> more abstract capability could cover all these cases without loss of useful
> generality.
> 
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.

> As for the rest of the patches, I suspect they'll be largely okay. We should
> refactor all the security code in Xen to sit under xen/security or xen/xsm.
> In particular, flask/ and acm/ would be relocated under here. When you add
> hook code to existing files, please format the code to that file's
> conventions (which are typically not k&r or linux style!). 

Yes.

> The flask_op()
> hypercall interface is rather opaque -- shouldn't you have a public header
> file to define what that interface is? Having the command enumeration
> directly above the hypercall implementation (and so private to Xen) seems
> odd. And I'm not sure about the Plan9-style sscanf-of-strings interface
> either. It should at least be documented. :-)
> 
Fair enough.  Up to this point, I've been trying to reduce the amount of
code deposited and made public across the Xen tree.  It was not my
intention to hide the flask_op hypercall command structure.
Documentation will be forth coming after we straighten out any other
issues wrt XSM.

>  -- Keir
-- 
George S. Coker, II <gscoker@xxxxxxxxxxxxxx> 443-479-6944


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