Re: [Xen-devel] [Hackathon 16] Notes from Security Session

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 05/17/2016 05:08 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 26, 2016 at 09:57:12AM +0100, Lars Kurth wrote:
> > Also adding Steve Maresca to the thread, who has been using XSM extensively and 
> > also documenting XSM and can provide some user perspective
> > Lars
> >
> > > On 25 Apr 2016, at 20:51, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> > >
> > > On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:
> > > > On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
> > > > > On 19/04/16 10:02, Doug Goldstein wrote:
> > > > > > On 4/18/16 12:20 PM, Lars Kurth wrote:
> > > > > > > Hi all,
> > > > CC-ing XSM maintainer :-)
> > > Thanks. I'm going to comment on this and the wiki.
> > >
> > > [...]
> > > > > > > === Enabling XSM By default ===
> > > > > > > Andrew: There are some issues which we need to work through; a lot of little 
> > > > > > > paper cuts
> > > > > > > Rich: Could we create a list of issues on the wiki?
> > > > > > > Lars: Definitely
> > > > > > > Doug: Could we not have a policy which is equivalent to XSM being compiled out
> > > > > > > Andrew: Could make policy more modular instead of one big global policy
> > > > > > >
> > > > > > > Re-apply policy of guest after running
> > > > > > >
> > > > > > > ACTION: Need a wiki page, Konrad can start one and we can collaboratively flesh 
> > > > > > > it out
> > > > > > > Lars: See http://wiki.xenproject.org/wiki/XSMAsDefault_TODO_List
> > > > > > >
> > > > > > > ACTION: Konrad and others to add detail to it
> > > > > > It was pointed out to me that I did not get my comments about XSM across
> > > > > > clearly. I believe we need to improve the default policy to be
> > > > > > equivalent to disabling XSM and/or create a policy called "dummy" that
> > > > > > is the same as XSM disabled. To make XSM usage more smooth I propose we
> > > > > > bake the default policy into .initdata so that when you boot Xen
> > > > > > compiled with XSM you are no worse off than compiling XSM out.
> > > > > >
> > > > > > The rationale here is that prior to a recent commit when you compiled
> > > > > > Xen with XSM enabled but did not provide a default policy then any domUs
> > > > > > that you ran had as much access as dom0. The recent commit changed it so
> > > > > > that Xen by default does not boot without a policy.
> > > > > >
> > > > > > With my proposed change we would have "dummy" that would compile in and
> > > > > > if you provided another policy it would be used instead or you could
> > > > > > late load a replacement policy. Basically filling the gap of turning on
> > > > > > XSM and having a system less secure than XSM off until you developed
> > > > > > your policy.
> > > > > +1.  It also avoids needing to play around loading an extra file as a grub
> > > > > module, which makes distro-integration easer.
> > > > >
> > > > > ~Andrew
> > > This should be doable, though it will require moving the rest of
> > > tools/flask/policy under xen/ for proper dependencies. Beyond that, it
> > > would need either a script or a careful invocation of objcopy to convert
> > > the policy output to an array in initdata, and then that policy would be
> > > used if the bootloader one is not present.
> OK, let me take a stab at that. Unless somebody else is already looking
> at this?
I have an RFC patch that I'll send in a moment.

> > >  From the wiki:
> > > > XSM with default policy will have:
> > > >
> > > >   - Same functionality exposed to guests without regressions
> > > >   - Have at minimum the same security as we have without XSM enabled.
> > > >   - Have set of policies for device driver domains vs control domains.
> > > The first two bullets should be true with the current policy. The third
> > > needs to be more precisely defined: any operation on a group it
> > > controls, or limited operations (such as adjusting memory size) on all
> > > guests?  The latter will probably need a custom policy (module) for
> > > exactly what the control domain does.
> Hm. I would have thought that device driver domains would have
> limited operations. As in they can do grant maps, PCIe access, etc.
> But they cannot do the operations that dom0 has done.
For pure device driver domains, this is true: they can just use domU_t and
be done.  The custom types would be needed for (non-dom0) control domains.

> Doug, didn't you do some of this already?
> > > > Known Issues
> > > >
> > > >   - Cannot re-apply a new policy after guests have been running.
> > > This is possible via "xl loadpolicy".  There is no (exposed) way to
> > > re-label existing domains, but you can create new domains using new
> > > types in the policy.  The new policy rules will be enforced immediately
> > > on existing domains, but this may not fully tighten restrictions: for
> > > example, if a passthrough device is newly disallowed but already mapped
> > > by a domain, it will not be unmapped.
> Would the audit code mention this? Ah I presume not as the operation
> has already been completed and the IOMMU access and such do not do XSM
> checks.
The audit code would catch the policy reload, and it might find (and deny)
operations by PV domains doing a remap of the device mapping.  HVM domains
(especially ones using EPT) don't hit XSM code when adjusting that mapping,
only when it is initially added to the guest to machine mapping.

> But it is good to know that you can relable existing domains.
> I was under the mistaken impression you couldn't!
This is only exposed at the libxc level (xc_flask_relabel_domain), and it
is discouraged as the "doesn't revoke existing mappings" aspect, if not
taken into consideration, can make you think the system is more secure than
it actually is.

> > > > TODO List
> > > >
> > > >   - Could initial build of Xen hypervisor include a built-in (inside 
> > > > .init.data) policy file?
> > > (Above).
> > > >   - Can we make policies modularized? A core (perhaps built-in?) with 
> > > > amendments loaded later?
> > > There is already some support for modules in the XSM policy: see
> > > tools/flask/policy/policy/modules.conf.  Currently this is not really
> > > used: all rules are in the "xen" module.  However, it could be split up
> > > into a real core module (probably still named "xen") and other modules
> > > that would be available to turn on/off.
> That is quit appealing. Especially when it comes to working on
> say device driver domains and having the 'core' Xen one there while
> I can futz around with device driver one.
I tried making this work last week, and I think I'll post what I have now
instead of waiting until after 4.7 has been branched.

> > > The process of assembling the modules into a single XSM policy is done
> > > in userspace, not the hypervisor, so "xl loadpolicy" would not change.
> /me nods
>
> Thank you!
--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel