1The Linux Kernel threat model 2============================= 3 4There are a lot of assumptions regarding what the kernel does and does not 5protect against. These assumptions tend to cause confusion for bug reports 6(:doc:`security-related ones <security-bugs>` vs :doc:`non-security ones 7<../admin-guide/reporting-issues>`), and can complicate security enforcement 8when the responsibilities for some boundaries is not clear between the kernel, 9distros, administrators and users. 10 11This document tries to clarify the responsibilities of the kernel in this 12domain. 13 14The kernel's responsibilities 15----------------------------- 16 17The kernel abstracts access to local hardware resources and to remote systems 18in a way that allows multiple local users to get a fair share of the available 19resources granted to them, and, when the underlying hardware permits, to assign 20a level of confidentiality to their communications and to the data they are 21processing or storing. 22 23The kernel assumes that the underlying hardware behaves according to its 24specifications. This includes the integrity of the CPU's instruction set, the 25transparency of the branch prediction unit and the cache units, the consistency 26of the Memory Management Unit (MMU), the isolation of DMA-capable peripherals 27(e.g., via IOMMU), state transitions in controllers, ranges of values read from 28registers, the respect of documented hardware limitations, etc. 29 30When hardware fails to maintain its specified isolation (e.g., CPU bugs, 31side-channels, hardware response to unexpected inputs), the kernel will usually 32attempt to implement reasonable mitigations. These are best-effort measures 33intended to reduce the attack surface or elevate the cost of an attack within 34the limits of the hardware's facilities; they do not constitute a 35kernel-provided safety guarantee. 36 37Users always perform their activities under the authority of an administrator 38who is able to grant or deny various types of permissions that may affect how 39users benefit from available resources, or the level of confidentiality of 40their activities. Administrators may also delegate all or part of their own 41permissions to some users, particularly via capabilities but not only. All this 42is performed via configuration (sysctl, file-system permissions etc). 43 44The Linux Kernel applies a certain collection of default settings that match 45its threat model. Distros have their own threat model and will come with their 46own configuration presets, that the administrator may have to adjust to better 47suit their expectations (relax or restrict). 48 49By default, the Linux Kernel guarantees the following protections when running 50on common processors featuring privilege levels and memory management units: 51 52* **User-based isolation**: an unprivileged user may restrict access to their 53 own data from other unprivileged users running on the same system. This 54 includes: 55 56 * stored data, via file system permissions 57 * in-memory data (pages are not accessible by default to other users) 58 * process activity (ptrace is not permitted to other users) 59 * inter-process communication (other users may not observe data exchanged via 60 UNIX domain sockets or other IPC mechanisms). 61 * network communications within the same or with other systems 62 63* **Capability-based protection**: 64 65 * users not having elevated capabilities (including but not limited to 66 CAP_SYS_ADMIN) may not alter the 67 kernel's configuration, memory nor state, change other users' view of the 68 file system layout, grant any user capabilities they do not have, nor 69 affect the system's availability (shutdown, reboot, panic, hang, or making 70 the system unresponsive via unbounded resource exhaustion). 71 * users not having the ``CAP_NET_ADMIN`` capability may not alter the network 72 configuration, intercept nor spoof network communications from other users 73 nor systems. 74 * users not having ``CAP_SYS_PTRACE`` may not observe other users' processes 75 activities. 76 77When ``CONFIG_USER_NS`` is set, the kernel also permits unprivileged users to 78create their own user namespace in which they have all capabilities, but with a 79number of restrictions (they may not perform actions that have impacts on the 80initial user namespace, such as changing time, loading modules or mounting 81block devices). Please refer to ``user_namespaces(7)`` for more details, the 82possibilities of user namespaces are not covered in this document. 83 84The kernel also offers a lot of troubleshooting and debugging facilities, which 85can constitute attack vectors when placed in wrong hands. While some of them 86are designed to be accessible to regular local users with a low risk (e.g. 87kernel logs via ``/proc/kmsg``), some would expose enough information to 88represent a risk in most places and the decision to expose them is under the 89administrator's responsibility (perf events, traces), and others are not 90designed to be accessed by non-privileged users (e.g. debugfs). Access to these 91facilities by a user who has been explicitly granted permission by an 92administrator does not constitute a security breach. 93 94Bugs that permit to violate the principles above constitute security breaches. 95However, bugs that permit one violation only once another one was already 96achieved are only weaknesses. The kernel applies a number of self-protection 97measures whose purpose is to avoid crossing a security boundary when certain 98classes of bugs are found, but a failure of these extra protections do not 99constitute a vulnerability alone. 100 101What does not constitute a security bug 102--------------------------------------- 103 104In the Linux kernel's threat model, the following classes of problems are 105**NOT** considered as Linux Kernel security bugs. However, when it is believed 106that the kernel could do better, they should be reported, so that they can be 107reviewed and fixed where reasonably possible, but they will be handled as any 108regular bug: 109 110* **Configuration**: 111 112 * outdated kernels and particularly end-of-life branches are out of the scope 113 of the kernel's threat model: administrators are responsible for keeping 114 their system up to date. For a bug to qualify as a security bug, it must be 115 demonstrated that it affects actively maintained versions. 116 117 * build-level: changes to the kernel configuration that are explicitly 118 documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or 119 targeted at developers only. 120 121 * OS-level: changes to command line parameters, sysctls, filesystem 122 permissions, user capabilities, exposure of privileged interfaces, that 123 explicitly increase exposure by either offering non-default access to 124 unprivileged users, or reduce the kernel's ability to enforce some 125 protections or mitigations. Example: write access to procfs or debugfs. 126 127 * issues triggered only when using features intended for development or 128 debugging (e.g., LOCKDEP, KASAN, FAULT_INJECTION): these features are known 129 to introduce overhead and potential instability and are not intended for 130 production use. 131 132 * issues affecting drivers exposed under CONFIG_STAGING, as well as features 133 marked EXPERIMENTAL in the configuration. 134 135 * loading of explicitly insecure/broken/staging modules, and generally any 136 using any subsystem marked as experimental or not intended for production 137 use. 138 139 * running out-of-tree modules or unofficial kernel forks; these should be 140 reported to the relevant vendor. 141 142* **Excess of initial privileges**: 143 144 * actions performed by a user already possessing the privileges required to 145 perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``, 146 ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no further 147 boundary being crossed). 148 149 * actions performed in user namespace that do not bypass the restrictions 150 imposed to the initial user (e.g. ptrace usage, signal delivery, resource 151 usage, access to FS/device/sysctl/memory, network binding, system/network 152 configuration etc). 153 154 * anything performed by the root user in the initial namespace (e.g. kernel 155 oops when writing to a privileged device). 156 157* **Out of production use**: 158 159 This covers theoretical/probabilistic attacks that rely on laboratory 160 conditions with zero system noise, or those requiring an unrealistic number 161 of attempts (e.g., billions of trials) that would be detected by standard 162 system monitoring long before success, such as: 163 164 * prediction of random numbers that only works in a totally silent 165 environment (such as IP ID, TCP ports or sequence numbers that can only be 166 guessed in a lab). 167 168 * activity observation and information leaks based on probabilistic 169 approaches that are prone to measurement noise and not realistically 170 reproducible on a production system. 171 172 * issues that can only be triggered by heavy attacks (e.g. brute force) whose 173 impact on the system makes it unlikely or impossible to remain undetected 174 before they succeed (e.g. consuming all memory before succeeding). 175 176 * problems seen only under development simulators, emulators, or combinations 177 that do not exist on real systems at the time of reporting (issues 178 involving tens of millions of threads, tens of thousands of CPUs, 179 unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds. 180 181 * issues whose reproduction requires hardware modification or emulation, 182 including fake USB devices that pretend to be another one. 183 184 * as well as issues that can be triggered at a cost that is orders of 185 magnitude higher than the expected benefits (e.g. fully functional keyboard 186 emulator only to retrieve 7 uninitialized bytes in a structure, or 187 brute-force method involving millions of connection attempts to guess a 188 port number). 189 190* **Hardening failures**: 191 192 * ability to bypass some of the kernel's hardening measures with no 193 demonstrable exploit path (e.g. ASLR bypass, events timing or probing with 194 no demonstrable consequence). These are just weaknesses, not 195 vulnerabilities. 196 197 * missing argument checks and failure to report certain errors with no 198 immediate consequence. 199 200* **Random information leaks**: 201 202 This concerns information leaks of small data parts that happen to be there 203 and that cannot be chosen by the attacker, or face access restrictions: 204 205 * structure padding reported by syscalls or other interfaces. 206 207 * identifiers, partial data, non-terminated strings reported in error 208 messages. 209 210 * Leaks of kernel memory addresses/pointers do not constitute an immediately 211 exploitable vector and are not security bugs, though they must be reported 212 and fixed. 213 214* **Crafted file system images**: 215 216 * bugs triggered by mounting a corrupted or maliciously crafted file system 217 image are generally not security bugs, as the kernel assumes the underlying 218 storage media is under the administrator's control, unless the filesystem 219 driver is specifically documented as being hardened against untrusted media. 220 221 * issues that are resolved, mitigated, or detected by running a filesystem 222 consistency check (fsck) on the image prior to mounting. 223 224* **Physical access**: 225 226 Issues that require physical access to the machine, hardware modification, or 227 the use of specialized hardware (e.g., logic analyzers, DMA-attack tools over 228 PCI-E/Thunderbolt) are out of scope unless the system is explicitly 229 configured with technologies meant to defend against such attacks 230 (e.g. IOMMU). 231 232* **Functional and performance regressions**: 233 234 Any issue that can be mitigated by setting proper permissions and limits 235 doesn't qualify as a security bug. 236