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

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 5/17/16 4: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 know I pitched this out and said I had planned on working on it but
the realities of life have set in and I likely won't really be able to
put an honest amount of effort into this for a few more weeks. I think a
bulk of the work will really be testing and documenting instead of
coding because as we said it should just be a few commands and a few if
checks.

> 
>>>
>>> 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.
> 
> Doug, didn't you do some of this already?

So I've made a domD_t but I'm not sure how encompassing it is. I've
thought about making the "driver_domain=BOOL" parameter apply that label
over domU_t but right now its just done through "seclabel". I can post
what I've got as a RFC.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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