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