1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
% 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
A final way to set up a separate process for qemus is to allocate one
UID per VM, and set the UID in the domain config file with the
`device_model_user` argument. For example, suppose you have a VM
named `c6-01`. You might do the following:
adduser --system --no-create-home --group xen-qemuuser-c6-01
And then in your config file, the following line:
device_model_user="xen-qemuuser-c6-01"
If you use this method, you should also allocate one "reaper" user to
be used for killing device models:
adduser --system --no-create-home --group xen-qemuuser-reaper
NOTE: It is important when using `device_model_user` that EACH VM HAVE
A SEPARATE UID, and that none of these UIDs map to root. xl will
throw an error a uid maps to zero, but not if multiple VMs have the
same uid. Multiple VMs with the same device model uid will cause
problems.
It is also important that `xen-qemuuser-reaper` not have any processes
associated with it, as they will be destroyed when deprivileged qemu
processes are destroyed.
## 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)
* Support for qdisk backends
A number of restrictions still need to be implemented. A compromised
device model may be able to do the following:
* Delay or exploit weaknesses in the toolstack
* Launch "fork bombs" or other resource exhaustion attacks
* Make network connections on the management network
* Break out of the restrictions after migration
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
---------- -------- -------- -------------------------------------------
|
