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 <[email protected]> >>>> --- >>>> CC: Ian Jackson <[email protected]> >>>> CC: Wei Liu <[email protected]> >>>> CC: Andrew Cooper <[email protected]> >>>> CC: Jan Beulich <[email protected]> >>>> CC: Tim Deegan <[email protected]> >>>> CC: Stefano Stabellini <[email protected]> >>>> CC: Konrad Wilk <[email protected]> >>>> CC: Julien Grall <[email protected]> >>>> --- >>>> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
