Re: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section
On 11/06/2018 09:08 AM, Paul Durrant wrote: >> -Original Message- >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf >> Of George Dunlap >> Sent: 05 November 2018 18:07 >> To: xen-devel@lists.xenproject.org >> Cc: Stefano Stabellini ; Wei Liu >> ; Konrad Wilk ; Andrew Cooper >> ; Tim (Xen.org) ; George Dunlap >> ; Ross Lagerwall ; >> Julien Grall ; Jan Beulich ; >> Anthony Perard ; Ian Jackson >> >> Subject: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section >> >> Signed-off-by: George Dunlap >> --- >> Changes since v3: >> - Moved from the qemu-depriv doc patches. >> - Reword to include the possibility of having a non-dom0 "devicemodel" >> domain which may want to be protected >> - Specify `Linux dom0` as the currently-tech-supported window >> >> CC: Ian Jackson >> CC: Wei Liu >> CC: Andrew Cooper >> CC: Jan Beulich >> CC: Tim Deegan >> CC: Konrad Wilk >> CC: Stefano Stabellini >> CC: Julien Grall >> CC: Anthony Perard >> CC: Ross Lagerwall >> --- >> SUPPORT.md | 20 >> 1 file changed, 20 insertions(+) >> >> diff --git a/SUPPORT.md b/SUPPORT.md >> index 4f203da84a..1f0f5857a7 100644 >> --- a/SUPPORT.md >> +++ b/SUPPORT.md >> @@ -525,6 +525,26 @@ Vulnerabilities of a device model stub domain >> to a hostile driver domain (either compromised or untrusted) >> are excluded from security support. >> >> +### Device Model Deprivileging >> + >> +Status, Linux dom0: Tech Preview, with limited support >> + >> +This means adding extra restrictions to a device model in order to >> +prevent a compromised device model from attack the rest of the domain > > s/attack/attacking/ Yeah, this paragraph in particular seems to have challenged by ability to form grammatically-correct English sentences... anyway thanks, I'll fix it up on check-in. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section
George Dunlap writes ("[PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section"): > Signed-off-by: George Dunlap Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of George Dunlap > Sent: 05 November 2018 18:07 > To: xen-devel@lists.xenproject.org > Cc: Stefano Stabellini ; Wei Liu > ; Konrad Wilk ; Andrew Cooper > ; Tim (Xen.org) ; George Dunlap > ; Ross Lagerwall ; > Julien Grall ; Jan Beulich ; > Anthony Perard ; Ian Jackson > > Subject: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section > > Signed-off-by: George Dunlap > --- > Changes since v3: > - Moved from the qemu-depriv doc patches. > - Reword to include the possibility of having a non-dom0 "devicemodel" > domain which may want to be protected > - Specify `Linux dom0` as the currently-tech-supported window > > CC: Ian Jackson > CC: Wei Liu > CC: Andrew Cooper > CC: Jan Beulich > CC: Tim Deegan > CC: Konrad Wilk > CC: Stefano Stabellini > CC: Julien Grall > CC: Anthony Perard > CC: Ross Lagerwall > --- > SUPPORT.md | 20 > 1 file changed, 20 insertions(+) > > diff --git a/SUPPORT.md b/SUPPORT.md > index 4f203da84a..1f0f5857a7 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -525,6 +525,26 @@ Vulnerabilities of a device model stub domain > to a hostile driver domain (either compromised or untrusted) > are excluded from security support. > > +### Device Model Deprivileging > + > +Status, Linux dom0: Tech Preview, with limited support > + > +This means adding extra restrictions to a device model in order to > +prevent a compromised device model from attack the rest of the domain s/attack/attacking/ Paul > +it's running in (normally dom0). > + > +"Tech preview with limited support" means we will not issue XSAs for > +the _additional_ functionality provided by the feature; but we will > +issue XSAs in the event that enabling this feature opens up a security > +hole that would not be present without the feature disabled. > + > +For example, while this is classified as tech preview, a bug in libxl > +which failed to change the user ID of QEMU would not receive an XSA, > +since without this feature the user ID wouldn't be changed. But a > +change which made it possible for a compromised guest to read > +arbitrary files on the host filesystem without compromising QEMU would > +be issued an XSA, since that does weaken security. > + > ### KCONFIG Expert > > Status: Experimental > -- > 2.19.1 > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section
Signed-off-by: George Dunlap --- Changes since v3: - Moved from the qemu-depriv doc patches. - Reword to include the possibility of having a non-dom0 "devicemodel" domain which may want to be protected - Specify `Linux dom0` as the currently-tech-supported window CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper CC: Jan Beulich CC: Tim Deegan CC: Konrad Wilk CC: Stefano Stabellini CC: Julien Grall CC: Anthony Perard CC: Ross Lagerwall --- SUPPORT.md | 20 1 file changed, 20 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 4f203da84a..1f0f5857a7 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -525,6 +525,26 @@ Vulnerabilities of a device model stub domain to a hostile driver domain (either compromised or untrusted) are excluded from security support. +### Device Model Deprivileging + +Status, Linux dom0: Tech Preview, with limited support + +This means adding extra restrictions to a device model in order to +prevent a compromised device model from attack the rest of the domain +it's running in (normally dom0). + +"Tech preview with limited support" means we will not issue XSAs for +the _additional_ functionality provided by the feature; but we will +issue XSAs in the event that enabling this feature opens up a security +hole that would not be present without the feature disabled. + +For example, while this is classified as tech preview, a bug in libxl +which failed to change the user ID of QEMU would not receive an XSA, +since without this feature the user ID wouldn't be changed. But a +change which made it possible for a compromised guest to read +arbitrary files on the host filesystem without compromising QEMU would +be issued an XSA, since that does weaken security. + ### KCONFIG Expert Status: Experimental -- 2.19.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel