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.
Cc: Greg KH <[email protected]> Cc: Leon Romanovsky <[email protected]> Suggested-by: Leon Romanovsky <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> --- Leon, while we started this list before our discussion, I reused most of your proposal which was more comprehensive, and merged our initial work into it. I added you in Suggested-by: but I think that Co-developed-by: would be more suitable. If so, for this you'll have to also sign-off the patch. It's as you prefer, I personally don't care. --- Documentation/process/security-bugs.rst | 50 +++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index a8a8fc724e8c8..7cc3a1970ca00 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -66,6 +66,56 @@ In addition, the following information are highly desirable: the issue appear. It is useful to share them, as they can be helpful to keep end users protected during the time it takes them to apply the fix. +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 to the security team are +just regular bugs that have been improperly qualified as security bugs due to a +misunderstanding of the Linux kernel's threat model, and ought to have been +sent through the normal channels described in +'Documentation/admin-guide/reporting-issues.rst'. + +The security list exists for urgent bugs that grant an attacker a capability +they are not supposed to have on a correctly configured production system, and +can be easily exploited, representing an imminent threat to many users. Before +reporting, consider whether the issue actually crosses a trust boundary on such +a system. + +In the Linux kernel's threat model, an issue is **not** a security bug, and +should not be reported to the security list, when triggering it requires the +reporter to first undermine the system they are attacking. This includes, but +is not limited to, behavior that only manifests after the administrator has +explicitly enabled it (loading a module, setting a sysctl, writing to a debugfs +knob, or otherwise using an interface documented as privileged or unsafe); bugs +reachable only through root or CAP_SYS_ADMIN or CAP_NET_ADMIN on a machine the +actor already fully controls, with no further privilege boundary being crossed; +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), issues that appear only in debug, lockdep, KASAN, fault-injection, +CONFIG_NOMMU, or other developer-oriented kernel builds that are not intended +for production use; problems seen only under development simulators, emulators, +or fuzzing harnesses that present hardware or input states which cannot occur +on real systems; bugs that require modified or emulated hardware; missing +hardening or defence-in-depth suggestions with no demonstrable exploit path +(including local ASLR bypass); mounting file systems that would be fixed or +rejected by fsck; and bugs in out-of-tree modules or vendor forks, which should +be reported to the relevant vendor. Functional and performance regressions, +and disagreements with documented kernel policy (for example, "root can load +modules"), are likewise ordinary bugs or feature requests rather than security +issues, and should be reported via the usual channels. + +If you are unsure whether an issue qualifies, err on the side of reporting +privately: the security team would rather triage a borderline report than miss +a real vulnerability. Reporting ordinary bugs to the security list, however, +does not make them move faster and consumes triage capacity that other reports +need. + Identifying contacts -------------------- -- 2.52.0
