mirror of
https://github.com/xen-project/xen.git
synced 2026-10-29 18:50:05 +01:00
George Dunlap
281fb93cc3
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. Signed-off-by: George Dunlap <george.dunlap@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> --- Changes since v4: - Remove unnecessary FIXME - Remove stale "Add SUPPORT.md" 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 <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: Konrad Wilk <konrad.wilk@oracle.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Julien Grall <julien.grall@arm.com> CC: Anthony Perard <anthony.perard@citrix.com> CC: Ross Lagerwall <ross.lagerwall@citrix.com>
102 lines
3.1 KiB
Plaintext
102 lines
3.1 KiB
Plaintext
% QEMU Deprivileging / dm_restrict
|
|
% Revision 1
|
|
|
|
\clearpage
|
|
|
|
# Basics
|
|
|
|
---------------- ----------------------------------------------------
|
|
Status: **Tech Preview**
|
|
|
|
Architecture(s): x86
|
|
|
|
Component(s): toolstack
|
|
|
|
---------------- ----------------------------------------------------
|
|
|
|
# Overview
|
|
|
|
By default, the QEMU device model is run in domain 0. If an attacker
|
|
can gain control of a QEMU process, it could easily take control of a
|
|
system.
|
|
|
|
dm_restrict is a set of operations to restrict QEMU running in domain
|
|
0. It consists of two halves:
|
|
|
|
1. Mechanisms to restrict QEMU to only being able to affect its own
|
|
domain
|
|
2. Mechanisms to restruct QEMU's ability to interact with domain 0.
|
|
|
|
# User details
|
|
|
|
## Getting the right versions of software
|
|
|
|
Linux: 4.11+
|
|
|
|
Qemu: 3.0+ (Or the version that comes with Xen 4.12+)
|
|
|
|
## Setting up a group and userid range
|
|
|
|
For maximum security, libxl needs to run the devicemodel for each
|
|
domain under a user id (UID) corresponding to its domain id. There
|
|
are 32752 possible domain IDs, and so libxl needs 32752 user ids set
|
|
aside for it. Setting up a group for all devicemodels to run at is
|
|
also recommended.
|
|
|
|
The simplest and most effective way to do this is to allocate a
|
|
contiguous block of UIDs, and create a single user named
|
|
`xen-qemuuser-range-base` with the first UID. For example, under
|
|
Debian:
|
|
|
|
adduser --system --uid 131072 --group --no-create-home xen-qemuuser-range-base
|
|
|
|
Two comments on this method:
|
|
|
|
1. 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".
|
|
2. Additionally, some container systems have proposed using the
|
|
upper 16 bits of the uid for a container ID. Using a multiple of 2^16
|
|
for the range base (as is done above) will result in all UIDs being
|
|
interpreted by such systems as a single container ID.
|
|
|
|
Another, less-secure way is to run all QEMUs as the same UID. To do
|
|
this, create a user named `xen-qemuuser-shared`; for example:
|
|
|
|
adduser --no-create-home --system xen-qemuuser-shared
|
|
|
|
## Domain config changes
|
|
|
|
The core domain config change is to add the following line to the
|
|
domain configuration:
|
|
|
|
dm_restrict=1
|
|
|
|
This will perform a number of restrictions, outlined below in the
|
|
'Technical details' section.
|
|
|
|
# Technical details
|
|
|
|
See docs/design/qemu-deprivilege.md for technical details.
|
|
|
|
# Limitations
|
|
|
|
The following features still need to be implemented:
|
|
* Inserting a new cdrom while the guest is running (xl cdrom-insert)
|
|
* Migration / save / restore
|
|
|
|
Additionally, getting PCI passthrough to work securely would require a
|
|
significant rework of how passthrough works at the moment. It may be
|
|
implemented at some point but is not a near-term priority.
|
|
|
|
See SUPPORT.md for security support status.
|
|
|
|
# History
|
|
|
|
------------------------------------------------------------------------
|
|
Date Revision Version Notes
|
|
---------- -------- -------- -------------------------------------------
|
|
2018-09-14 1 Xen 4.12 Imported from docs/misc
|
|
---------- -------- -------- -------------------------------------------
|