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

[Keir Fraser <keir@xxxxxxxxxxxxx>]

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

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.

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

 -- Keir


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