History

Documentation: security-bugs: explain what is and is not a security bug

The use of automated tools to find bugs in random locations of the kernel induces a raise of security reports even if most of them should just be reported as regular bugs. This patch is an attempt at drawing a line between what qualifies as a security bug and what does not, hoping to improve the situation and ease decision on the reporter's side. It defers the enumeration to a new file, threat-model.rst, that tries to enumerate various classes of issues that are and are not security bugs. This should permit to more easily update this file for various subsystem-specific rules without having to revisit the security bug reporting guide.

Willy Tarreau committed 6 months ago

Commit a03ef331 parent aed3c333 files · +274 −1Browse files

Unified · Split

3 files
  1. Documentation/process/index.rst +1 −0
  2. Documentation/process/security-bugs.rst +37 −1
  3. Documentation/process/threat-model.rst +236 −0
Documentation/process/index.rst+1−0
@@ -86,6 +86,7 @@ regressions and security problems. · 85 unmodified lines
8686 debugging/index
8787 handling-regressions
8888 security-bugs
89+ threat-model
8990 cve
9091 embargoed-hardware-issues
9192
Documentation/process/security-bugs.rst+37−1
@@ -66,6 +66,42 @@ In addition, the following information are highly desirable: · 65 unmodified lines
6666 the issue appear. It is useful to share them, as they can be helpful to
6767 keep end users protected during the time it takes them to apply the fix.
6868
69+What qualifies as a security bug
70+--------------------------------
71+
72+It is important that most bugs are handled publicly so as to involve the widest
73+possible audience and find the best solution. By nature, bugs that are handled
74+in closed discussions between a small set of participants are less likely to
75+produce the best possible fix (e.g., risk of missing valid use cases, limited
76+testing abilities).
77+
78+It turns out that the majority of the bugs reported via the security team are
79+just regular bugs that have been improperly qualified as security bugs due to
80+a lack of awareness of the Linux kernel's threat model, as described in
81+Documentation/process/threat-model.rst, and ought to have been sent through
82+the normal channels described in Documentation/admin-guide/reporting-issues.rst
83+instead.
84+
85+The security list exists for urgent bugs that grant an attacker a capability
86+they are not supposed to have on a correctly configured production system, and
87+can be easily exploited, representing an imminent threat to many users. Before
88+reporting, consider whether the issue actually crosses a trust boundary on such
89+a system.
90+
91+**If you resorted to AI assistance to identify a bug, you must treat it as
92+public**. While you may have valid reasons to believe it is not, the security
93+team's experience shows that bugs discovered this way systematically surface
94+simultaneously across multiple researchers, often on the same day. In this
95+case, do not publicly share a reproducer, as this could cause unintended harm;
96+just mention that one is available and maintainers might ask for it privately
97+if they need it.
98+
99+If you are unsure whether an issue qualifies, err on the side of reporting
100+privately: the security team would rather triage a borderline report than miss
101+a real vulnerability. Reporting ordinary bugs to the security list, however,
102+does not make them move faster and consumes triage capacity that other reports
103+need.
104+
69105 Identifying contacts
70106 --------------------
71107
@@ -74,7 +110,7 @@ affected subsystem's maintainers and Cc: the Linux kernel security team. Do · 2 unmodified lines
74110 not send it to a public list at this stage, unless you have good reasons to
75111 consider the issue as being public or trivial to discover (e.g. result of a
76112 widely available automated vulnerability scanning tool that can be repeated by
77−anyone).
113+anyone, or use of AI-based tools).
78114
79115 If you're sending a report for issues affecting multiple parts in the kernel,
80116 even if they're fairly similar issues, please send individual messages (think
Documentation/process/threat-model.rst+236−0
@@ -0,0 +1,236 @@
1+.. _threatmodel:
2+
3+The Linux Kernel threat model
4+=============================
5+
6+There are a lot of assumptions regarding what the kernel does and does not
7+protect 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
10+when the responsibilities for some boundaries is not clear between the kernel,
11+distros, administrators and users.
12+
13+This document tries to clarify the responsibilities of the kernel in this
14+domain.
15+
16+The kernel's responsibilities
17+-----------------------------
18+
19+The kernel abstracts access to local hardware resources and to remote systems
20+in a way that allows multiple local users to get a fair share of the available
21+resources granted to them, and, when the underlying hardware permits, to assign
22+a level of confidentiality to their communications and to the data they are
23+processing or storing.
24+
25+The kernel assumes that the underlying hardware behaves according to its
26+specifications. This includes the integrity of the CPU's instruction set, the
27+transparency of the branch prediction unit and the cache units, the consistency
28+of 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
30+registers, the respect of documented hardware limitations, etc.
31+
32+When hardware fails to maintain its specified isolation (e.g., CPU bugs,
33+side-channels, hardware response to unexpected inputs), the kernel will usually
34+attempt to implement reasonable mitigations. These are best-effort measures
35+intended to reduce the attack surface or elevate the cost of an attack within
36+the limits of the hardware's facilities; they do not constitute a
37+kernel-provided safety guarantee.
38+
39+Users always perform their activities under the authority of an administrator
40+who is able to grant or deny various types of permissions that may affect how
41+users benefit from available resources, or the level of confidentiality of
42+their activities. Administrators may also delegate all or part of their own
43+permissions to some users, particularly via capabilities but not only. All this
44+is performed via configuration (sysctl, file-system permissions etc).
45+
46+The Linux Kernel applies a certain collection of default settings that match
47+its threat model. Distros have their own threat model and will come with their
48+own configuration presets, that the administrator may have to adjust to better
49+suit their expectations (relax or restrict).
50+
51+By default, the Linux Kernel guarantees the following protections when running
52+on 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+
78+When ``CONFIG_USER_NS`` is set, the kernel also permits unprivileged users to
79+create their own user namespace in which they have all capabilities, but with a
80+number of restrictions (they may not perform actions that have impacts on the
81+initial user namespace, such as changing time, loading modules or mounting
82+block devices). Please refer to ``user_namespaces(7)`` for more details, the
83+possibilities of user namespaces are not covered in this document.
84+
85+The kernel also offers a lot of troubleshooting and debugging facilities, which
86+can constitute attack vectors when placed in wrong hands. While some of them
87+are designed to be accessible to regular local users with a low risk (e.g.
88+kernel logs via ``/proc/kmsg``), some would expose enough information to
89+represent a risk in most places and the decision to expose them is under the
90+administrator's responsibility (perf events, traces), and others are not
91+designed to be accessed by non-privileged users (e.g. debugfs). Access to these
92+facilities by a user who has been explicitly granted permission by an
93+administrator does not constitute a security breach.
94+
95+Bugs that permit to violate the principles above constitute security breaches.
96+However, bugs that permit one violation only once another one was already
97+achieved are only weaknesses. The kernel applies a number of self-protection
98+measures whose purpose is to avoid crossing a security boundary when certain
99+classes of bugs are found, but a failure of these extra protections do not
100+constitute a vulnerability alone.
101+
102+What does not constitute a security bug
103+---------------------------------------
104+
105+In 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
107+that the kernel could do better, they should be reported, so that they can be
108+reviewed and fixed where reasonably possible, but they will be handled as any
109+regular 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.