Re: [Xen-devel] [PATCH 1/5] docs/qemu-deprivilege: Revise and update with status and future plans
[Re-sending as this mail seems to have gone missing]
> On Oct 26, 2018, at 3:52 PM, George Dunlap wrote:
>
> On 10/26/2018 02:45 PM, Ian Jackson wrote:
>> George Dunlap writes ("[PATCH 1/5] docs/qemu-deprivilege: Revise and update
>> with status and future plans"):
>>> docs/qemu-deprivilege.txt had some basic instructions for using
>>> dm_restrict, but it was incomplete, misleading, and stale.
>>
>> Thanks for the updates to the unshare stuff.
>>
>>> +### Device Model Deprivileging
>>> +
>>> +Status, Linux: Tech Preview, with limited support
>>^
>> dom0
>
> "Deprivileging" only makes sense in a dom0 context; the definition in
> the first paragraph should make that clear. I think adding 'dom0' would
> confuse the issue by implying that non-dom0 deprivileging is possible.
>
>> I think this maybe needs
>>
>> +Status, FreeBSD dom0: Unsupported
>>
>> too ? The usual default is supported and not listing it at all is
>> confusing.
>
> Where do we say the default is supported? I thought the default for a
> _feature_ not mentioned was "no information" (i.e., might be either
> supported or not -- if there's a question ask), and the default for a
> _configuration_ not mentioned was "unsupported".
>
>>> +NOTE: Most modern systems have 32-bit UIDs, and so can in theory go up
>>> +to 2^31 (or 2^32 if uids are unsigned). POSIX only guarantees 16-bit
>>> +UIDs however; UID 65535 is reserved for an invalid value, and 65534 is
>>> +normally allocated to "nobody". Additionally, some container systems
>>> +have proposed using the upper 32 bits of the uid for a container ID.
>> ^^
>> 16
>
> Ack
>
>> This is a good paragraph.
>>
>> Can I suggest we pick a different example to 65536 ? It's visually
>> similar to the familiar values of 65534 and 65535 and abuts them.
>>
>> osstest uses 20 but that's not a multiple of 2^16.
>> How about 131072 ?
>
> Is the idea for making it a multiple of 2^16 that the values will then
> only take up one entry in the "container ID" space?
>
> -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/5] docs/qemu-deprivilege: Revise and update with status and future plans
George Dunlap writes ("[PATCH 1/5] docs/qemu-deprivilege: Revise and update
with status and future plans"):
> docs/qemu-deprivilege.txt had some basic instructions for using
> dm_restrict, but it was incomplete, misleading, and stale.
Thanks for the updates to the unshare stuff.
> +### Device Model Deprivileging
> +
> +Status, Linux: Tech Preview, with limited support
^
dom0
I think this maybe needs
+Status, FreeBSD dom0: Unsupported
too ? The usual default is supported and not listing it at all is
confusing.
> +NOTE: Most modern systems have 32-bit UIDs, and so can in theory go up
> +to 2^31 (or 2^32 if uids are unsigned). POSIX only guarantees 16-bit
> +UIDs however; UID 65535 is reserved for an invalid value, and 65534 is
> +normally allocated to "nobody". Additionally, some container systems
> +have proposed using the upper 32 bits of the uid for a container ID.
^^
16
This is a good paragraph.
Can I suggest we pick a different example to 65536 ? It's visually
similar to the familiar values of 65534 and 65535 and abuts them.
osstest uses 20 but that's not a multiple of 2^16.
How about 131072 ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/5] docs/qemu-deprivilege: Revise and update with status and future plans
Ping? It's been nearly 3 weeks with only minor review for this series. -George On 10/05/2018 05:56 PM, George Dunlap wrote: > docs/qemu-deprivilege.txt had some basic instructions for using > dm_restrict, but it was incomplete, misleading, and stale. > > Update the docs in a number of ways. > > First, separate user-facing documentation and technical description > into docs/features and docs/design, respectively. > > In the feature doc: > > * Introduce a section mentioning minimim versions of Linux, Xen, and > qemu required (TBD) > > * Fix the discussion of qemu userid. Mention xen-qemuuser-range-base, > and provide example shell code that actually has some hope of working > (instead of failing out after creating 900 userids). > > * Describe how to enable restrictions, as well as features which > probably don't or definitely don't work. > > In the design doc, introduce a "Technical Details" section which > describes specifically what restrictions are currently done, and also > what restrictions we are looking at doing in the future. > > The idea here is that as we implement the various items for the > future, we move them from "Restrictions still to do" to "Restrictions > done". This can also act as a design document -- a place for public > discussion of what can or should be done and how. > > Also add an entry to SUPPORT.md. > > Signed-off-by: George Dunlap > --- > Changes since v2: > - Extraneous privcmd / evtchn instances aren't closed > - Expand description of how to test fd deprivileging > - Rework and clarify two namespace sections, give reference for QEMU NAK > - Add more information about migration technical challenges > - In UID section, mention possibility of container ID collisions. > - Fix name of design document. > - Add SUPPORT.md statement. Specify Linux, to make sure that FreeBSD is > evaluated separately. > - Mention that `-sandbox` is a blacklist and why > > Changes since v1: > - Break into two, and move into appropriate directories (rather than 'misc') > - Updated version requirements > - Distinguish between features which "don't yet work" and features which we > never expect to work > - Update description of xen-restrict functionality > - Reorder and expand further restrictions > - Make it more clear which restrictions are available on Linux only > - Include detailed description of how to kill a process > - Add RLIMIT_NPROC as something we can do without further changes to qemu > - Document the need to check for the sandbox feature before using it > > Thank you to Ross Lagerwall, whose description of what XenServer is > doing formed much of the basis for the text here. > > 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 ++ > docs/designs/qemu-deprivilege.md | 322 ++ > docs/features/qemu-deprivilege.pandoc | 94 > docs/misc/qemu-deprivilege.txt| 36 --- > 4 files changed, 436 insertions(+), 36 deletions(-) > create mode 100644 docs/designs/qemu-deprivilege.md > create mode 100644 docs/features/qemu-deprivilege.pandoc > delete mode 100644 docs/misc/qemu-deprivilege.txt > > diff --git a/SUPPORT.md b/SUPPORT.md > index 3727446b83..b5e7e44fb3 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: Tech Preview, with limited support > + > +This means adding extra restrictions to a device model running in > +domain 0 in order to prevent a compromised device model to attack the > +rest of the system. > + > +"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 > diff --git a/docs/designs/qemu-deprivilege.md > b/docs/designs/qemu-deprivilege.md > new file mode 100644 > index 00..d3c6495030 > --- /dev/null > +++ b/docs/designs/qemu-deprivilege.md > @@ -0,0 +1,322 @@ > +# Introduction > + > +The goal of deprilvileging qemu is this: Even if there is a bug (for > +example in qemu) which permits a domain to gain
[Xen-devel] [PATCH 1/5] docs/qemu-deprivilege: Revise and update with status and future plans
docs/qemu-deprivilege.txt had some basic instructions for using dm_restrict, but it was incomplete, misleading, and stale. Update the docs in a number of ways. First, separate user-facing documentation and technical description into docs/features and docs/design, respectively. In the feature doc: * Introduce a section mentioning minimim versions of Linux, Xen, and qemu required (TBD) * Fix the discussion of qemu userid. Mention xen-qemuuser-range-base, and provide example shell code that actually has some hope of working (instead of failing out after creating 900 userids). * Describe how to enable restrictions, as well as features which probably don't or definitely don't work. In the design doc, introduce a "Technical Details" section which describes specifically what restrictions are currently done, and also what restrictions we are looking at doing in the future. The idea here is that as we implement the various items for the future, we move them from "Restrictions still to do" to "Restrictions done". This can also act as a design document -- a place for public discussion of what can or should be done and how. Also add an entry to SUPPORT.md. Signed-off-by: George Dunlap --- Changes since v2: - Extraneous privcmd / evtchn instances aren't closed - Expand description of how to test fd deprivileging - Rework and clarify two namespace sections, give reference for QEMU NAK - Add more information about migration technical challenges - In UID section, mention possibility of container ID collisions. - Fix name of design document. - Add SUPPORT.md statement. Specify Linux, to make sure that FreeBSD is evaluated separately. - Mention that `-sandbox` is a blacklist and why Changes since v1: - Break into two, and move into appropriate directories (rather than 'misc') - Updated version requirements - Distinguish between features which "don't yet work" and features which we never expect to work - Update description of xen-restrict functionality - Reorder and expand further restrictions - Make it more clear which restrictions are available on Linux only - Include detailed description of how to kill a process - Add RLIMIT_NPROC as something we can do without further changes to qemu - Document the need to check for the sandbox feature before using it Thank you to Ross Lagerwall, whose description of what XenServer is doing formed much of the basis for the text here. 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 ++ docs/designs/qemu-deprivilege.md | 322 ++ docs/features/qemu-deprivilege.pandoc | 94 docs/misc/qemu-deprivilege.txt| 36 --- 4 files changed, 436 insertions(+), 36 deletions(-) create mode 100644 docs/designs/qemu-deprivilege.md create mode 100644 docs/features/qemu-deprivilege.pandoc delete mode 100644 docs/misc/qemu-deprivilege.txt diff --git a/SUPPORT.md b/SUPPORT.md index 3727446b83..b5e7e44fb3 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: Tech Preview, with limited support + +This means adding extra restrictions to a device model running in +domain 0 in order to prevent a compromised device model to attack the +rest of the system. + +"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 diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md new file mode 100644 index 00..d3c6495030 --- /dev/null +++ b/docs/designs/qemu-deprivilege.md @@ -0,0 +1,322 @@ +# Introduction + +The goal of deprilvileging qemu is this: Even if there is a bug (for +example in qemu) which permits a domain to gain control of the device +model, the compromised device model process is prevented from +violating the system's overall security properties. Ie, a guest +cannot "escape" from the virtualisation by using a qemu bug. + +This document lists the various technical measures which we either +have taken, or plan to take to effect this goal. Some of them are +required to be
