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

Showing the changes to Documentation/process (3 of 3 files). Show all

Unified · Split

3 files

Documentation/process/index.rst +1 −0
Documentation/process/security-bugs.rst +37 −1
Documentation/process/threat-model.rst +236 −0

Documentation/process/index.rst+1−0

@@ -86,6 +86,7 @@ regressions and security problems. · 85 unmodified lines
86	debugging/index	86	debugging/index
87	handling-regressions	87	handling-regressions
88	security-bugs	88	security-bugs
		89	threat-model
89	cve	90	cve
90	embargoed-hardware-issues	91	embargoed-hardware-issues
91		92

Documentation/process/security-bugs.rst+37−1

@@ -66,6 +66,42 @@ In addition, the following information are highly desirable: · 65 unmodified lines
66	the issue appear. It is useful to share them, as they can be helpful to	66	the issue appear. It is useful to share them, as they can be helpful to
67	keep end users protected during the time it takes them to apply the fix.	67	keep end users protected during the time it takes them to apply the fix.
68		68
		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
69	Identifying contacts	105	Identifying contacts
70	--------------------	106	--------------------
71		107
@@ -74,7 +110,7 @@ affected subsystem's maintainers and Cc: the Linux kernel security team. Do · 2 unmodified lines
74	not send it to a public list at this stage, unless you have good reasons to	110	not send it to a public list at this stage, unless you have good reasons to
75	consider the issue as being public or trivial to discover (e.g. result of a	111	consider the issue as being public or trivial to discover (e.g. result of a
76	widely available automated vulnerability scanning tool that can be repeated by	112	widely available automated vulnerability scanning tool that can be repeated by
77	anyone).	113	anyone, or use of AI-based tools).
78		114
79	If you're sending a report for issues affecting multiple parts in the kernel,	115	If you're sending a report for issues affecting multiple parts in the kernel,
80	even if they're fairly similar issues, please send individual messages (think	116	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.