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

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

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

Right, while we do check the iocaps setup, there is more value here than
a simple check on bind.  XSM has also introduced a security field for
event channels.  The value of this security field can only practically
be computed at bind time, so whether a security module wants to do a
permission check on binding for pirq/virq/ipi is not as relevant as
whether the module needs to assign a security field to the channel.  The
purpose of the security field is not only to facilitate information
flows to resources, virtual or physical, in the hypervisor, but also to
facilitate guests in the ability to identify channels based on these
security properties and support information flows mediated by these
guests.  This is really an important property for creating secure
channels between domains as well as other resources (virtual or
physical) resources.

> > 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?
> 
I certainly do not want to go down the path of intercepting *every*
hypercall subcommand.  Let me give a bit more detail about what kinds of
capabilities that I am suggesting.  To achieve a very light-weight
domain, one would like to remove as much functionality from that domain
as possible, to include the interrupt handler.  Instead, there would
exist a light-weight domain interrupt handler domain that is responsible
for this functionality.  These interrupts would manifest as interdomain
channels; however, the ipi mechanism remains unless a hook exists to
block this code path.  Likewise, the light-weight domains wouldn't be
able to close their channels arbitrarily, and require a check on close
as well.

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

It does go either way, but hopefully, as XSM becomes part of Xen, new
hooks or the need for new hooks won't be as opaque as it is in the roll-
up implementation.  At least in the current XSM, it is clear as to what
is/not checked.  Another issue is demuxing in the hook forces a wide
hook interface - not to mention needless hook processing on every entry
to the hypercall.  Demuxing in the hook also makes the hook and the rest
of Xen ripe for abuse ala typical ioctl style issues.

George
> 
>  -- Keir



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