[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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.

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.

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.


  - Could initial build of Xen hypervisor include a built-in (inside 
.init.data) policy file?
  - 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.

The process of assembling the modules into a single XSM policy is done
in userspace, not the hypervisor, so "xl loadpolicy" would not change.

Daniel De Graaf
National Security Agency

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.