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

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

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.
> 
> 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.
> 
>> 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.
> 
> 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
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel