* [PATCH] SUPPORT.md: Clarify stubdomain support @ 2018-03-06 17:08 George Dunlap 2018-03-06 18:08 ` Wei Liu 2018-03-06 18:57 ` Ian Jackson 0 siblings, 2 replies; 7+ messages in thread From: George Dunlap @ 2018-03-06 17:08 UTC (permalink / raw) To: xen-devel Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, Tim Deegan, George Dunlap, Julien Grall, Jan Beulich, Ian Jackson 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@citrix.com> --- CC: Ian Jackson <ian.jackson@citrix.com> CC: Wei Liu <wei.liu2@citrix.com> CC: Andrew Cooper <andrew.cooper3@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Tim Deegan <tim@xen.org> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Konrad Wilk <konrad.wilk@oracle.com> CC: Julien Grall <julien.grall@arm.com> --- 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; +untrusted stub domain binaries (e.g., provided by untrusted users) +are excluded from security support. + Vulnerabilities of a device model stub domain to a hostile driver domain (either compromised or untrusted) are excluded from security support. -- 2.16.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] SUPPORT.md: Clarify stubdomain support 2018-03-06 17:08 [PATCH] SUPPORT.md: Clarify stubdomain support George Dunlap @ 2018-03-06 18:08 ` Wei Liu 2018-03-06 18:18 ` George Dunlap 2018-03-06 18:57 ` Ian Jackson 1 sibling, 1 reply; 7+ messages in thread From: Wei Liu @ 2018-03-06 18:08 UTC (permalink / raw) To: George Dunlap Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, Tim Deegan, Julien Grall, Jan Beulich, Ian Jackson, xen-devel 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@citrix.com> > --- > CC: Ian Jackson <ian.jackson@citrix.com> > CC: Wei Liu <wei.liu2@citrix.com> > CC: Andrew Cooper <andrew.cooper3@citrix.com> > CC: Jan Beulich <jbeulich@suse.com> > CC: Tim Deegan <tim@xen.org> > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: Konrad Wilk <konrad.wilk@oracle.com> > CC: Julien Grall <julien.grall@arm.com> > --- > 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? Wei. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] SUPPORT.md: Clarify stubdomain support 2018-03-06 18:08 ` Wei Liu @ 2018-03-06 18:18 ` George Dunlap 2018-03-06 19:05 ` Wei Liu 0 siblings, 1 reply; 7+ messages in thread From: George Dunlap @ 2018-03-06 18:18 UTC (permalink / raw) To: Wei Liu Cc: Stefano Stabellini, Andrew Cooper, Tim Deegan, Julien Grall, Jan Beulich, Ian Jackson, xen-devel 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@citrix.com> >> --- >> CC: Ian Jackson <ian.jackson@citrix.com> >> CC: Wei Liu <wei.liu2@citrix.com> >> CC: Andrew Cooper <andrew.cooper3@citrix.com> >> CC: Jan Beulich <jbeulich@suse.com> >> CC: Tim Deegan <tim@xen.org> >> CC: Stefano Stabellini <sstabellini@kernel.org> >> CC: Konrad Wilk <konrad.wilk@oracle.com> >> CC: Julien Grall <julien.grall@arm.com> >> --- >> 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." Does that make sense? It's not saying we don't provide support *for the binary*; it's saying we don't provide support for *the rest of the system* if you use an untrusted binary. Feel free to suggest a reword... -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] SUPPORT.md: Clarify stubdomain support 2018-03-06 18:18 ` George Dunlap @ 2018-03-06 19:05 ` Wei Liu 2018-09-25 10:39 ` George Dunlap 0 siblings, 1 reply; 7+ messages in thread From: Wei Liu @ 2018-03-06 19:05 UTC (permalink / raw) To: George Dunlap Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, Tim Deegan, Julien Grall, Jan Beulich, Ian Jackson, xen-devel 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@citrix.com> > >> --- > >> CC: Ian Jackson <ian.jackson@citrix.com> > >> CC: Wei Liu <wei.liu2@citrix.com> > >> CC: Andrew Cooper <andrew.cooper3@citrix.com> > >> CC: Jan Beulich <jbeulich@suse.com> > >> CC: Tim Deegan <tim@xen.org> > >> CC: Stefano Stabellini <sstabellini@kernel.org> > >> CC: Konrad Wilk <konrad.wilk@oracle.com> > >> CC: Julien Grall <julien.grall@arm.com> > >> --- > >> 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? Wei. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] SUPPORT.md: Clarify stubdomain support 2018-03-06 19:05 ` Wei Liu @ 2018-09-25 10:39 ` George Dunlap 2018-09-25 11:18 ` Ian Jackson 0 siblings, 1 reply; 7+ messages in thread From: George Dunlap @ 2018-09-25 10:39 UTC (permalink / raw) To: Wei Liu Cc: Stefano Stabellini, Konrad Wilk, Andrew Cooper, Tim Deegan, Julien Grall, Jan Beulich, Ian Jackson, xen-devel 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@citrix.com> >>>> --- >>>> CC: Ian Jackson <ian.jackson@citrix.com> >>>> CC: Wei Liu <wei.liu2@citrix.com> >>>> CC: Andrew Cooper <andrew.cooper3@citrix.com> >>>> CC: Jan Beulich <jbeulich@suse.com> >>>> CC: Tim Deegan <tim@xen.org> >>>> CC: Stefano Stabellini <sstabellini@kernel.org> >>>> CC: Konrad Wilk <konrad.wilk@oracle.com> >>>> CC: Julien Grall <julien.grall@arm.com> >>>> --- >>>> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] SUPPORT.md: Clarify stubdomain support 2018-09-25 10:39 ` George Dunlap @ 2018-09-25 11:18 ` Ian Jackson 0 siblings, 0 replies; 7+ messages in thread From: Ian Jackson @ 2018-09-25 11:18 UTC (permalink / raw) To: George Dunlap Cc: Stefano Stabellini, Wei Liu, Konrad Wilk, Andrew Cooper, Tim Deegan, Julien Grall, Jan Beulich, xen-devel George Dunlap writes ("Re: [PATCH] SUPPORT.md: Clarify stubdomain support"): > 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. I agree with George. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] SUPPORT.md: Clarify stubdomain support 2018-03-06 17:08 [PATCH] SUPPORT.md: Clarify stubdomain support George Dunlap 2018-03-06 18:08 ` Wei Liu @ 2018-03-06 18:57 ` Ian Jackson 1 sibling, 0 replies; 7+ messages in thread From: Ian Jackson @ 2018-03-06 18:57 UTC (permalink / raw) To: George Dunlap Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, Tim Deegan, Julien Grall, Jan Beulich, xen-devel George Dunlap writes ("[PATCH] SUPPORT.md: Clarify stubdomain support"): > We don't promise to protect you against rogue stub domain binaries; > only from the running domain once the guest has come up. Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-09-25 11:18 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-06 17:08 [PATCH] SUPPORT.md: Clarify stubdomain support George Dunlap 2018-03-06 18:08 ` Wei Liu 2018-03-06 18:18 ` George Dunlap 2018-03-06 19:05 ` Wei Liu 2018-09-25 10:39 ` George Dunlap 2018-09-25 11:18 ` Ian Jackson 2018-03-06 18:57 ` Ian Jackson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).