Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug

[Shuah Khan <skhan@linuxfoundation.org>]

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