docs/system/security.rst

5 --------
7 This chapter explains the security requirements that QEMU is designed to meet
8 and principles for securely deploying QEMU.
11 ---------------------
13 QEMU supports many different use cases, some of which have stricter security
24 safely on the physical CPU at close-to-native speed.
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)
36 real-world use cases and treated as security bugs if this is the case.
38 Non-virtualization Use Case
41 The non-virtualization use case covers emulation using the Tiny Code Generator
43 the non-virtualization use case should meet the same security requirements as
45 non-virtualization use case code was not written with these security
48 Bugs affecting the non-virtualization use case are not considered security
49 bugs at this time.  Users with non-virtualization use cases must not rely on
50 QEMU to provide guest isolation or any security guarantees.
53 ------------
67 QEMU presents an attack surface to the guest in the form of emulated devices.
68 The guest must not be able to gain control of QEMU.  Bugs in emulated devices
69 could allow malicious guests to gain code execution in QEMU.  At this point the
71 QEMU process on the host.
82 the privileges necessary for its function.  In the case of QEMU this means that
85 The QEMU process should not have access to any resources that are inaccessible
87 QEMU process since it already has access to those same resources from within
95 available to QEMU to perform its function.  For example, host system calls are
96 necessary for QEMU but are not exposed to guests.  A guest that escapes into
97 the QEMU process can then begin invoking host system calls.
101 clearly documented so users are aware of the trade-off of enabling the feature.
109 launch QEMU, such as libvirt.  They are also platform-specific so they are only
112 The fundamental isolation mechanism is that QEMU processes must run as
113 unprivileged users.  Sometimes it seems more convenient to launch QEMU as
116 unprivileged QEMU process access to host devices without running QEMU as root.
117 It is also possible to launch QEMU as a non-root user and configure UNIX groups
121 - SELinux and AppArmor make it possible to confine processes beyond the
122   traditional UNIX process and file permissions model.  They restrict the QEMU
123   process from accessing processes and files on the host system that are not
124   needed by QEMU.
126 - Resource limits and cgroup controllers provide throughput and utilization
129 - Linux namespaces can be used to make process, file system, and other system
130   resources unavailable to QEMU.  A namespaced QEMU process is restricted to only
133 - Linux seccomp is available via the QEMU ``--sandbox`` option.  It disables
134   system calls that are not needed by QEMU, thereby reducing the host kernel
138 ------------------------
140 There are aspects of QEMU that can have security implications which users &
147 to dynamically control many aspects of QEMU's runtime operation. Many of the
148 commands exposed will instruct QEMU to access content on the host file system
153 ``blockdev-add`` command instructs QEMU to open arbitrary files, exposing
156 Unless QEMU is otherwise confined using technologies such as SELinux, AppArmor,
158 equivalent to those of the user account QEMU is running under.
163 perform man-in-the-middle attacks. Many of the character device backends do not
172 QEMU and as such should only be made accessible to a trusted management