Re: [Xen-devel] [PATCH] SUPPORT.md: Clarify stubdomain support

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 03/06/2018 07:05 PM, Wei Liu wrote:
> On Tue, Mar 06, 2018 at 06:18:12PM +0000, George Dunlap wrote:
>> On 03/06/2018 06:08 PM, Wei Liu wrote:
>>> On Tue, Mar 06, 2018 at 05:08:43PM +0000, George Dunlap wrote:
>>>> We don't promise to protect you against rogue stub domain binaries;
>>>> only from the running domain once the guest has come up.
>>>>
>>>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>>>> ---
>>>> CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
>>>> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
>>>> CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> CC: Jan Beulich <jbeulich@xxxxxxxx>
>>>> CC: Tim Deegan <tim@xxxxxxx>
>>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>> CC: Konrad Wilk <konrad.wilk@xxxxxxxxxx>
>>>> CC: Julien Grall <julien.grall@xxxxxxx>
>>>> ---
>>>>  SUPPORT.md | 5 +++++
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>>> index a1810b8046..ce9f68e1c2 100644
>>>> --- a/SUPPORT.md
>>>> +++ b/SUPPORT.md
>>>> @@ -501,6 +501,11 @@ for more information about security support.
>>>>  
>>>>      Status: Supported, with caveats
>>>>  
>>>> +Only stub domain binaries provided by the host admin
>>>> +or trusted users are security supported;
>>>
>>> I'm not sure I follow -- why would / should upstream support a binary
>>> that is not produced from upstream source code?
>>
>> Hrm, seems I wasn't very clear.
>>
>> Suppose for some reason, a cloud provider says to their customers, "I'll
>> let you submit *your own* devicemodel binary!  Your virtual guests can
>> have whatever virtual hardware you can code up!  It's secure because it
>> runs as a stub domain!"
>>
>> And suppose that we discover a bug in the stubdomain setup code, that
>> would allow a "crafted image" to break into the toolstack; or we
>> discovered a bug such that a rogue stubdomain could cause problems after
>> the stubdomain started but before the guest started.  Should we issue an
>> XSA in that case?
>>
>> The point of this statement is to say, "No, we would not issue an XSA in
>> that case: We only provide security support for systems where the
>> administrator or trusted users provide the stub domain binary; the stub
>> domain is only meant to protect against attacks *after* the VM has
>> started up."
>>
> 
> I think there is too much special-casing here. Stubdom is just another
> domain. It should be treated like any untrusted DomU, unless there is
> some set of interfaces which is only available to stubdom but not an
> ordinary DomU. In this case -- the toolstack code that sets up the
> stubdom? Some special xenstore node that only stubdom can read from /
> write to?

[Reviving this thread after ages]

I think my answer before contains the answer to your question.  Yes, a
stubdomain *image* has access to code and interfaces that a *running
stubdomain* does not -- it interacts with the setup code.  Its image is
parsed by the toolstack, which means that a *hostile image* has
opportunities to break into the toolstack that a *hostile running
domain* (i.e., one which became hostile as a result of being exploited)
does not).  In addition, stub domains starts running before the
toolstack is completely finished setting up the target VM; if there were
a race condition somewhere in the setup code, a rogue stubdomain could
potentially take advantage of this race condition.

This didn't come out of nowhere.  From the Security Team's perspective,
the main purpose of SUPPORT.md is to be able to say of a bug, "This is
not a security issue; we will not issue an XSA."  There was specifically
an issue for which we didn't want to issue an XSA because it's a
configuration nobody ever intended on supporting, hence the patch.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel