On 5/8/26 22:48, Willy Tarreau wrote:
Hi Shuah,
On Fri, May 08, 2026 at 02:52:13PM -0600, Shuah Khan wrote:
+What qualifies as a security bug
+--------------------------------
+
+It is important that most bugs are handled publicly so as to involve the widest
+possible audience and find the best solution. By nature, bugs that are handled
+in closed discussions between a small set of participants are less likely to
+produce the best possible fix (e.g., risk of missing valid use cases, limited
+testing abilities).
+
+It turns out that the majority of the bugs reported via the security team are
+just regular bugs that have been improperly qualified as security bugs due to
+ignorance or misunderstanding of the Linux kernel's threat model described in
"lack of understanding" instead of ignorance?
I already had "misunderstanding", here I wanted to express the idea that
people could simply ignore that this file exists (since it's new). Do you
think we shouldn't care about this and just keep "misunderstanding" ?
(...)
+The Linux Kernel threat model
+=============================
+
+There are a lot of assumptions regarding what the kernel protects against and
+what it does not protect against. These assumptions tend to cause confusion for
Could simply say "what it does not" or "what the kernel does and does not
protect
against"
Ah OK good point, I'll rephrase it.
+* **Configuration**:
+
+ * outdated kernels and particularly end-of-life branches are out of the scope
+ of the kernel's threat model: administrators are responsible for keeping
+ their system up to date. For a bug to qualify as a security bug, it must be
+ demonstrated that it affects actively maintained versions.
+
+ * build-level: changes to the kernel configuration that are explicitly
+ documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or
+ targeted at developers only.
+
+ * OS-level: changes to command line parameters, sysctls, filesystem
+ permissions, user capabilities, exposure of privileged interfaces, that
+ explicitly increase exposure by either offering non-default access to
+ unprivileged users, or reduce the kernel's ability to enforce some
+ protections or mitigations. Example: write access to procfs or debugfs.
+
+ * issues triggered only when using features intended for development or
+ debugging (e.g., lockdep, KASAN, fault-injection): these features are known
+ to introduce overhead and potential instability and are not intended for
+ production use.
Can we call out features and tools (the ones in kernel repo)
Sure!
sched_ext's Kconfig enables
a few debug options including LOCKDEP
tools/sched_ext/Kconfig:CONFIG_DEBUG_LOCKDEP=y
It's still there but maybe not visible enough, I should probably write
it in upper case:
debugging (e.g., lockdep, KASAN, fault-injection):
+* **Excess of initial privileges**:
+
+ * actions performed by a user already possessing the privileges required to
+ perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``,
+ ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no further
+ boundary being crossed).
+
+ * actions performed in user namespace without permitting anything in the
+ initial namespace that was not already permitted to the same user there.
This was a bit hard to parse - examples might help here
Yeah when rereading it now, I fully agree. I think I should avoid the
double negation here and use a form such as;
* actions performed in user namespace that do not bypass the restrictions
imposed to the initial user.
If examples are still needed, I could possibly add: "(e.g. ptrace, signals,
FS or device access, system/network configuration, network binding)".
+ * anything performed by the root user in the initial namespace (e.g. kernel
+ oops when writing to a privileged device).
+
+* **Out of production use**:
+
+ This covers theoretical/probabilistic attacks that rely on laboratory
+ conditions with zero system noise, or those requiring an unrealistic number
+ of attempts (e.g., billions of trials) that would be detected by standard
+ system monitoring long before success, such as:
+
+ * prediction of random numbers that only works in a totally silent
+ environment (such as IP ID, TCP ports or sequence numbers that can only be
+ guessed in a lab).
+
+ * activity observation and information leaks based on probabilistic
+ approaches that are prone to measurement noise and not realistically
+ reproducible on a production system.
+
+ * issues that can only be triggered by heavy attacks (e.g. brute force) whose
+ impact on the system makes it unlikely or impossible to remain undetected
+ before they succeed (e.g. consuming all memory before succeeding).
+
+ * problems seen only under development simulators, emulators, or combinations
+ that do not exist on real systems at the time of reporting (issues
+ involving tens of millions of threads, tens of thousands of CPUs,
+ unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds.
+
+ * issues whose reproduction requires hardware modification or emulation,
+ including fake USB devices that pretend to be another one.
+
+ * as well as issues that can be triggered at a cost that is orders of
+ magnitude higher than the expected benefits (e.g. fully functional keyboard
+ emulator only to retrieve 7 uninitialized bytes in a structure, or
+ brute-force method involving millions of connection attempts to guess a
+ port number).
Can we add a section about problems found using experimental or tools
in development stage?
You mean one more paragraph about CONFIG_EXPERIMENTAL ? Or what else do
you have in mind ? Do not hesiate to propose a paragraph if you have
anything in mind!
This is what I have in mind:
issues found by closed source static and dynamic checkers that are
in development by individual or research groups.
I see that you sent out v3 and we can add this later. My Reviewed-by
hold for your v3.
thanks,
-- Shuah
