Re: [Xen-devel] [PATCH v4 1/6] docs/qemu-deprivilege: Revise and update with status and future plans
George Dunlap writes ("[PATCH v4 1/6] 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.
Acked-by: Ian Jackson
(Assuming you fix the commit message to drop the mention of
nonexistent SUPPORT.md changes...)
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/6] docs/qemu-deprivilege: Revise and update with status and future plans
On Tue, Nov 06, 2018 at 09:07:12AM +, Paul Durrant wrote: > > +## Migration > > + > > +When calling xen-save-devices-state, since QEMU is running in a chroot > > +it is not useful to pass a filename (it doesn't even have write access > > +inside the chroot). Instead, give it an open fd using the add-fd > > +mechanism. > > + > > +Additionally, all the restrictions need to be applied to the qemu > > +started up on the post-migration side. One issue that needs to be > > +solved is how to signal the toolstack on restore that qemu is ready > > +for the domain to be started (since this is normally done via > > +xenstore, and at this point the xenstore connections will have been > > +closed). > > I thought Anthony had fixed this now? > It's work in progress. (libxl__ev_qmp_* patch series.) -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/6] docs/qemu-deprivilege: Revise and update with status and future plans
> -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 1/6] 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 v3: > - Fix typo (32->16) > - Use an example value not close to the `nobody` uids, but still a > multiple of 2^16. > - Mention that using a multiple of 2^16 may have advantages. > - Have the example create a group as well > - Reorganize two comments on the "range-base" method for clarity > > 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 > --- > docs/designs/qemu-deprivilege.md | 322 ++ > docs/features/qemu-deprivilege.pandoc | 101 > docs/misc/qemu-deprivilege.txt| 36 --- > 3 files changed, 423 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/docs/designs/qemu-deprivilege.md b/docs/designs/qemu- > deprivilege.md > new file mode 100644 > index 00..787ae1ac7c > --- /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 considered secure (that is, there are known attack > +vectors which they close); others are "just in case" (that is, there > +are no known attack vectors, but we perform the restrictions to reduce > +the possibility of unknown attack vectors). > + > +# Restrictions done > + > +The following restrictions
Re: [Xen-devel] [PATCH v4 1/6] docs/qemu-deprivilege: Revise and update with status and future plans
On 11/05/2018 06:07 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. Sorry, I thought I'd removed this -- the SUPPORT.md changes have been moved to another file. I can fix this up on check-in if necessary. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 1/6] 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 v3: - Fix typo (32->16) - Use an example value not close to the `nobody` uids, but still a multiple of 2^16. - Mention that using a multiple of 2^16 may have advantages. - Have the example create a group as well - Reorganize two comments on the "range-base" method for clarity 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 --- docs/designs/qemu-deprivilege.md | 322 ++ docs/features/qemu-deprivilege.pandoc | 101 docs/misc/qemu-deprivilege.txt| 36 --- 3 files changed, 423 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/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md new file mode 100644 index 00..787ae1ac7c --- /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 considered secure (that is, there are known attack +vectors which they close); others are "just in case" (that is, there +are no known attack vectors, but we perform the restrictions to reduce +the possibility of unknown attack vectors). + +# Restrictions done + +The following restrictions are currently implemented. + +## Having qemu switch user + +'''Description''': As mentioned above, having QEMU switch to a +non-root user, one per domain id. Not being the root user limits what +a compromised QEMU process can do to the system, and having one user +per domain id limits what a comprimised QEMU process can do to the +QEMU processes of other VMs. + +'''Implementation''': The toolstack adds the following to the qemu command-line: + +-runas : + +'''How to test''': + +grep /proc//status [UG]id + +'''Testing Status''': Not tested + +## Xen library / file-descriptor restrictions + +'''Description''': Close and restrict Xen-related file descriptors. +Specifically: + * Close all
