| 1 | Security |
| 2 | ======== |
| 3 | |
| 4 | Overview |
| 5 | -------- |
| 6 | |
| 7 | This chapter explains the security requirements that QEMU is designed to meet |
| 8 | and principles for securely deploying QEMU. |
| 9 | |
| 10 | Security Requirements |
| 11 | --------------------- |
| 12 | |
| 13 | QEMU supports many different use cases, some of which have stricter security |
| 14 | requirements than others. The community has agreed on the overall security |
| 15 | requirements that users may depend on. These requirements define what is |
| 16 | considered supported from a security perspective. |
| 17 | |
| 18 | Virtualization Use Case |
| 19 | ''''''''''''''''''''''' |
| 20 | |
| 21 | The virtualization use case covers cloud and virtual private server (VPS) |
| 22 | hosting, as well as traditional data center and desktop virtualization. These |
| 23 | use cases rely on hardware virtualization extensions to execute guest code |
| 24 | safely on the physical CPU at close-to-native speed. |
| 25 | |
| 26 | The following entities are untrusted, meaning that they may be buggy or |
| 27 | malicious: |
| 28 | |
| 29 | - Guest |
| 30 | - User-facing interfaces (e.g. VNC, SPICE, WebSocket) |
| 31 | - Network protocols (e.g. NBD, live migration) |
| 32 | - User-supplied files (e.g. disk images, kernels, device trees) |
| 33 | - Passthrough devices (e.g. PCI, USB) |
| 34 | |
| 35 | Bugs affecting these entities are evaluated on whether they can cause damage in |
| 36 | real-world use cases and treated as security bugs if this is the case. |
| 37 | |
| 38 | To be covered by this security support policy you must: |
| 39 | |
| 40 | - use a virtualization accelerator like KVM or HVF |
| 41 | - use one of the machine types listed below |
| 42 | |
| 43 | It may be possible to use other machine types with a virtualization |
| 44 | accelerator to provide improved performance with a trusted guest |
| 45 | workload, but any machine type not listed here should not be |
| 46 | considered to be providing guest isolation or security guarantees, |
| 47 | and falls under the "non-virtualization use case". |
| 48 | |
| 49 | Supported machine types for the virtualization use case, by target architecture: |
| 50 | |
| 51 | aarch64 |
| 52 | ``virt`` |
| 53 | i386, x86_64 |
| 54 | ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35`` |
| 55 | s390x |
| 56 | ``s390-ccw-virtio`` |
| 57 | loongarch64: |
| 58 | ``virt`` |
| 59 | ppc64: |
| 60 | ``pseries`` |
| 61 | riscv32, riscv64: |
| 62 | ``virt`` |
| 63 | |
| 64 | Non-virtualization Use Case |
| 65 | ''''''''''''''''''''''''''' |
| 66 | |
| 67 | The non-virtualization use case covers emulation using the Tiny Code Generator |
| 68 | (TCG). In principle the TCG and device emulation code used in conjunction with |
| 69 | the non-virtualization use case should meet the same security requirements as |
| 70 | the virtualization use case. However, for historical reasons much of the |
| 71 | non-virtualization use case code was not written with these security |
| 72 | requirements in mind. |
| 73 | |
| 74 | Bugs affecting the non-virtualization use case are not considered security |
| 75 | bugs at this time. Users with non-virtualization use cases must not rely on |
| 76 | QEMU to provide guest isolation or any security guarantees. |
| 77 | |
| 78 | Security boundary scope |
| 79 | ''''''''''''''''''''''' |
| 80 | |
| 81 | Even where a flaw affects the virtualization use case described above, |
| 82 | not all scenarios will be considered in scope. The following guidelines |
| 83 | are used to evaluate whether to apply the full security process, or treat |
| 84 | an issue as a normal bug. |
| 85 | |
| 86 | * **assert** / **abort**. If triggering the code path requires kernel |
| 87 | privileges (or root account access) in the guest, asserts/aborts in |
| 88 | QEMU are a self inflicted denial of service. These will **not** be |
| 89 | treated as security flaws, at most hardening bugs. If triggering the |
| 90 | code path can be done by an unprivileged guest OS account, this |
| 91 | **may** justify handling as a security bug. |
| 92 | |
| 93 | * **vhost-user/vfio-user backends**. The backend processes have |
| 94 | shared memory regions co-mapped with the QEMU process. The intent |
| 95 | of the process separation is operational resilience & flexibility |
| 96 | and allowing for independent software suppliers. There is not |
| 97 | considered to be security boundary between QEMU and the vhost-user |
| 98 | & vfio-user backends. Thus flaws in the backends which can cause |
| 99 | crashes / undesirable behaviour in QEMU will **not** be treated as |
| 100 | security flaws, but should be fixed as hardening bugs. |
| 101 | |
| 102 | * **memory allocation bounds**. There are many ways in which a QEMU |
| 103 | process can legitimately consume an amount of memory that is |
| 104 | significantly larger than the assigned guest RAM. QEMU's worst |
| 105 | case memory usage should be considered effectively unbounded. As |
| 106 | such the QEMU deployment on the host should account for the |
| 107 | possibility of large memory peaks and apply countermeasures to |
| 108 | provide continuity of host operations. It is typical for the Linux |
| 109 | OOM killer to reap the process triggering host memory overcommit |
| 110 | in the case of exccessive usage, offering a degree of protection. |
| 111 | As such, bugs which can lead to excessive/unbounded memory allocations |
| 112 | will usually not be classified as security flaws, but should be |
| 113 | fixed as hardening bugs. |
| 114 | |
| 115 | * **degraded guest behaviour**. There are a set of bugs which can |
| 116 | lead guest hardware devices to misbehave. For example, a flawed |
| 117 | virtual IOMMU operation may not offer the guest device isolation |
| 118 | that would otherwise be expected. If a guest triggered exploit |
| 119 | requires kernel privileges (or root account access), and leads |
| 120 | to sub-optimal behaviour of the virtual device this is considered |
| 121 | a self inflicted service degradation. These will **not** be |
| 122 | treated as security flaws, at most hardening bugs. If triggering |
| 123 | the code path can be done by an unprivileged guest OS account, |
| 124 | this may justify handling as a security bug. |
| 125 | |
| 126 | * **nested virtualization**. The scope for nested virtualization |
| 127 | is to prevent a level 2 guest from breaking out into a level |
| 128 | 1 guest. As noted above, a number of scenarios exclude security |
| 129 | handling for flaws only exploitable by the guest kernel / root |
| 130 | account with affect the guest's own service/availability. In the |
| 131 | context of nested virtualization with PCI device assignment, it |
| 132 | may may be possible for a level 2 guest kernel to trigger flaws |
| 133 | that affect the level 0 QEMU process. While these bugs should be |
| 134 | fixed, they will not be triaged as security flaws at this time. |
| 135 | |
| 136 | * **migration/snapshots**. Migration failures and snapshot load |
| 137 | failures are considered part of normal operation as long as the |
| 138 | source virtual machine and savevm file, respectively, are still |
| 139 | functional. Aborting the QEMU process at the migration/snapshot |
| 140 | destination is similarly not considered a security issue. The |
| 141 | migration stream is assumed to be secure as long as the design |
| 142 | principles described in the Architecture section are held, in |
| 143 | which case plain manipulation of the stream is not considered as |
| 144 | an attack vector. |
| 145 | |
| 146 | * **low severity impact**. As a catch all rule, issues which |
| 147 | are judged to have a "low" severity impact on the system will |
| 148 | usually not justify handling as security bugs, nor assignment |
| 149 | of CVEs. They will be fixed as routine bugs when time allows. |
| 150 | |
| 151 | Architecture |
| 152 | ------------ |
| 153 | |
| 154 | This section describes the design principles that ensure the security |
| 155 | requirements are met. |
| 156 | |
| 157 | Guest Isolation |
| 158 | ''''''''''''''' |
| 159 | |
| 160 | Guest isolation is the confinement of guest code to the virtual machine. When |
| 161 | guest code gains control of execution on the host this is called escaping the |
| 162 | virtual machine. Isolation also includes resource limits such as throttling of |
| 163 | CPU, memory, disk, or network. Guests must be unable to exceed their resource |
| 164 | limits. |
| 165 | |
| 166 | QEMU presents an attack surface to the guest in the form of emulated devices. |
| 167 | The guest must not be able to gain control of QEMU. Bugs in emulated devices |
| 168 | could allow malicious guests to gain code execution in QEMU. At this point the |
| 169 | guest has escaped the virtual machine and is able to act in the context of the |
| 170 | QEMU process on the host. |
| 171 | |
| 172 | Guests often interact with other guests and share resources with them. |
| 173 | A malicious guest must not gain control of other guests or access |
| 174 | their data. Disk image files and network traffic must be protected |
| 175 | from other guests, users and processes unless explicitly shared with |
| 176 | them by the user. |
| 177 | |
| 178 | Principle of Least Privilege |
| 179 | '''''''''''''''''''''''''''' |
| 180 | |
| 181 | The principle of least privilege states that each component only has access to |
| 182 | the privileges necessary for its function. In the case of QEMU this means that |
| 183 | each process only has access to resources belonging to the guest. |
| 184 | |
| 185 | The QEMU process should not have access to any resources that are inaccessible |
| 186 | to the guest. This way the guest does not gain anything by escaping into the |
| 187 | QEMU process since it already has access to those same resources from within |
| 188 | the guest. |
| 189 | |
| 190 | Following the principle of least privilege immediately fulfills guest isolation |
| 191 | requirements. For example, guest A only has access to its own disk image file |
| 192 | ``a.img`` and not guest B's disk image file ``b.img``. |
| 193 | |
| 194 | In reality certain resources are inaccessible to the guest but must be |
| 195 | available to QEMU to perform its function. For example, host system calls are |
| 196 | necessary for QEMU but are not exposed to guests. A guest that escapes into |
| 197 | the QEMU process can then begin invoking host system calls. |
| 198 | |
| 199 | New features must be designed to follow the principle of least privilege. |
| 200 | Should this not be possible for technical reasons, the security risk must be |
| 201 | clearly documented so users are aware of the trade-off of enabling the feature. |
| 202 | |
| 203 | Isolation mechanisms |
| 204 | '''''''''''''''''''' |
| 205 | |
| 206 | Several isolation mechanisms are available to realize this architecture of |
| 207 | guest isolation and the principle of least privilege. With the exception of |
| 208 | Linux seccomp, these mechanisms are all deployed by management tools that |
| 209 | launch QEMU, such as libvirt. They are also platform-specific so they are only |
| 210 | described briefly for Linux here. |
| 211 | |
| 212 | The fundamental isolation mechanism is that QEMU processes must run as |
| 213 | unprivileged users. Sometimes it seems more convenient to launch QEMU as |
| 214 | root to give it access to host devices (e.g. ``/dev/net/tun``) but this poses a |
| 215 | huge security risk. File descriptor passing can be used to give an otherwise |
| 216 | unprivileged QEMU process access to host devices without running QEMU as root. |
| 217 | It is also possible to launch QEMU as a non-root user and configure UNIX groups |
| 218 | for access to ``/dev/kvm``, ``/dev/net/tun``, and other device nodes. |
| 219 | Some Linux distros already ship with UNIX groups for these devices by default. |
| 220 | |
| 221 | - SELinux and AppArmor make it possible to confine processes beyond the |
| 222 | traditional UNIX process and file permissions model. They restrict the QEMU |
| 223 | process from accessing processes and files on the host system that are not |
| 224 | needed by QEMU. |
| 225 | |
| 226 | - Resource limits and cgroup controllers provide throughput and utilization |
| 227 | limits on key resources such as CPU time, memory, and I/O bandwidth. |
| 228 | |
| 229 | - Linux namespaces can be used to make process, file system, and other system |
| 230 | resources unavailable to QEMU. A namespaced QEMU process is restricted to only |
| 231 | those resources that were granted to it. |
| 232 | |
| 233 | - Linux seccomp is available via the QEMU ``--sandbox`` option. It disables |
| 234 | system calls that are not needed by QEMU, thereby reducing the host kernel |
| 235 | attack surface. |
| 236 | |
| 237 | - Transport Layer Security (TLS) protocol can be used to ensure authenticity and |
| 238 | encryption of the live migration connection where the network is untrusted. |
| 239 | |
| 240 | Sensitive configurations |
| 241 | ------------------------ |
| 242 | |
| 243 | There are aspects of QEMU that can have security implications which users & |
| 244 | management applications must be aware of. |
| 245 | |
| 246 | Monitor console (QMP and HMP) |
| 247 | ''''''''''''''''''''''''''''' |
| 248 | |
| 249 | The monitor console (whether used with QMP or HMP) provides an interface |
| 250 | to dynamically control many aspects of QEMU's runtime operation. Many of the |
| 251 | commands exposed will instruct QEMU to access content on the host file system |
| 252 | and/or trigger spawning of external processes. |
| 253 | |
| 254 | For example, the ``migrate`` command allows for the spawning of arbitrary |
| 255 | processes for the purpose of tunnelling the migration data stream. The |
| 256 | ``blockdev-add`` command instructs QEMU to open arbitrary files, exposing |
| 257 | their content to the guest as a virtual disk. |
| 258 | |
| 259 | Unless QEMU is otherwise confined using technologies such as SELinux, AppArmor, |
| 260 | or Linux namespaces, the monitor console should be considered to have privileges |
| 261 | equivalent to those of the user account QEMU is running under. |
| 262 | |
| 263 | It is further important to consider the security of the character device backend |
| 264 | over which the monitor console is exposed. It needs to have protection against |
| 265 | malicious third parties which might try to make unauthorized connections, or |
| 266 | perform man-in-the-middle attacks. Many of the character device backends do not |
| 267 | satisfy this requirement and so must not be used for the monitor console. |
| 268 | |
| 269 | The general recommendation is that the monitor console should be exposed over |
| 270 | a UNIX domain socket backend to the local host only. Use of the TCP based |
| 271 | character device backend is inappropriate unless configured to use both TLS |
| 272 | encryption and authorization control policy on client connections. |
| 273 | |
| 274 | In summary, the monitor console is considered a privileged control interface to |
| 275 | QEMU and as such should only be made accessible to a trusted management |
| 276 | application or user. |