[PATCH v2] Documentation/security-bugs: overhaul
From: Vegard Nossum
Date: Mon Jun 06 2022 - 15:52:50 EST
The current instructions for reporting security vulnerabilities in the
kernel are not clear enough, in particular the process of disclosure
and requesting CVEs, and what the roles of the different lists are and
how exactly to report to each of them.
Let's give this document an overhaul. Goals are stated as a comment at
the bottom of the document; these will not appear in the rendered HTML
document.
v2: address feedback from Willy Tarreau and Jonathan Corbet
Link: https://seclists.org/oss-sec/2022/q2/133
Cc: Amit Shah <aams@xxxxxxxxxx>
Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
Cc: David Woodhouse <dwmw@xxxxxxxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: Gustavo A. R. Silva <gustavoars@xxxxxxxxxx>
Cc: Jiri Kosina <jkosina@xxxxxxx>
Cc: Jonathan Corbet <corbet@xxxxxxx>
Cc: Kees Cook <keescook@xxxxxxxxxxxx>
Cc: Laura Abbott <labbott@xxxxxxxxxx>
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>
Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Solar Designer <solar@xxxxxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Thorsten Leemhuis <linux@xxxxxxxxxxxxx>
Cc: Tyler Hicks <tyhicks@xxxxxxxxxxxxxxxxxxx>
Cc: Will Deacon <will@xxxxxxxxxx>
Cc: Willy Tarreau <w@xxxxxx>
Signed-off-by: Vegard Nossum <vegard.nossum@xxxxxxxxxx>
---
Documentation/admin-guide/security-bugs.rst | 252 +++++++++++++-------
1 file changed, 167 insertions(+), 85 deletions(-)
v1 thread:
https://lore.kernel.org/all/20220531230309.9290-1-vegard.nossum@xxxxxxxxxx/T/#u
Updated rendered HTML:
https://vegard.github.io/security/Documentation/output/admin-guide/security-bugs-v2.html
diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
index 82e29837d5898..c63eeb1e89ffd 100644
--- a/Documentation/admin-guide/security-bugs.rst
+++ b/Documentation/admin-guide/security-bugs.rst
@@ -1,96 +1,178 @@
+
.. _securitybugs:
-Security bugs
-=============
+Reporting security bugs
+=======================
Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible. Please report security bugs to the
-Linux kernel security team.
-
-Contact
--------
-
-The Linux kernel security team can be contacted by email at
-<security@xxxxxxxxxx>. This is a private list of security officers
-who will help verify the bug report and develop and release a fix.
-If you already have a fix, please include it with your report, as
-that can speed up the process considerably. It is possible that the
-security team will bring in extra help from area maintainers to
-understand and fix the security vulnerability.
-
-As it is with any bug, the more information provided the easier it
-will be to diagnose and fix. Please review the procedure outlined in
-'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
-information is helpful. Any exploit code is very helpful and will not
-be released without consent from the reporter unless it has already been
-made public.
-
-Please send plain text emails without attachments where possible.
-It is much harder to have a context-quoted discussion about a complex
-issue if all the details are hidden away in attachments. Think of it like a
-:doc:`regular patch submission <../process/submitting-patches>`
-(even if you don't have a patch yet): describe the problem and impact, list
+Linux kernel security team at security@xxxxxxxxxx, henceforth "the
+security list". This is a closed list of trusted developers who will
+help verify the bug report and develop a patch in case none was already
+proposed.
+
+While the security list is closed, the security team may bring in
+extra help from the relevant maintainers to understand and fix the
+security vulnerability.
+
+Note that the main interest of the kernel security list is in getting
+bugs fixed and getting patches reviewed, tested, and merged; CVE
+assignment, disclosure to distributions, and public disclosure happen
+on different lists with different people, as described below.
+
+Here is a quick overview of the various lists:
+
+ =============================== ===== =================== ===============
+ List address Open? Purpose Members
+ =============================== ===== =================== ===============
+ security@xxxxxxxxxx no | Reporting Trusted kernel
+ | Patch development developers
+ ------------------------------- ----- ------------------- ---------------
+ linux-distros@xxxxxxxxxxxxxxx no | Coordination Distribution
+ | CVE assignment representatives
+ | Backporting
+ | Testing
+ ------------------------------- ----- ------------------- ---------------
+ oss-security@xxxxxxxxxxxxxxxxxx yes | Disclosure General public
+ =============================== ===== =================== ===============
+
+The following sections give a step-by-step guide to reporting and
+disclosure.
+
+Contacting the security list
+----------------------------
+
+As it is with any bug, the more information provided the easier it will
+be to diagnose and fix; please review the procedure outlined in
+Documentation/admin-guide/reporting-issues.rst if you are unclear about
+what information is helpful. Any exploit code is very helpful and will
+not be released without consent from the reporter unless it has already
+been made public. Reporters are encouraged to propose patches, participate
+in the discussions of a fix, and test patches.
+
+The security team does not assign CVEs, nor does it require them
+for reports or fixes. CVEs may be requested when the issue is reported to
+the linux-distros list.
+
+**Disclosure.** The security list strongly prefers to have patches posted
+for review and testing on public mailing lists and and merged into the
+appropriate public git repository as soon as they become available.
+However, in exceptional cases, you or an affected party may request that
+the patch be withheld for some days; as a rule, the maximum is 7 days.
+Only in truly exceptional cases will the security list consider deferring
+the publication of a fix beyond this, and the only valid reason for doing
+so would be to accommodate the logistics of QA and large scale rollouts
+that require release coordination.
+
+Please note that although a fix is public, there may still be value
+in withholding the details of its security relevance and/or how to exploit
+it for another while; see below for when and how to properly disclose the
+security impact of your findings publicly.
+
+**List rules.** Please send plain text emails without attachments where
+possible. It is much harder to have a context-quoted discussion about a
+complex issue if all the details are hidden away in attachments. Think of
+it like regular patch submission (see Documentation/process/submitting-patches.rst)
+even if you don't have a patch yet; describe the problem and impact, list
reproduction steps, and follow it with a proposed fix, all in plain text.
-Disclosure and embargoed information
-------------------------------------
-
-The security list is not a disclosure channel. For that, see Coordination
-below.
-
-Once a robust fix has been developed, the release process starts. Fixes
-for publicly known bugs are released immediately.
-
-Although our preference is to release fixes for publicly undisclosed bugs
-as soon as they become available, this may be postponed at the request of
-the reporter or an affected party for up to 7 calendar days from the start
-of the release process, with an exceptional extension to 14 calendar days
-if it is agreed that the criticality of the bug requires more time. The
-only valid reason for deferring the publication of a fix is to accommodate
-the logistics of QA and large scale rollouts which require release
-coordination.
-
-While embargoed information may be shared with trusted individuals in
-order to develop a fix, such information will not be published alongside
-the fix or on any other disclosure channel without the permission of the
-reporter. This includes but is not limited to the original bug report
-and followup discussions (if any), exploits, CVE information or the
-identity of the reporter.
-
-In other words our only interest is in getting bugs fixed. All other
-information submitted to the security list and any followup discussions
-of the report are treated confidentially even after the embargo has been
-lifted, in perpetuity.
-
-Coordination
-------------
-
-Fixes for sensitive bugs, such as those that might lead to privilege
-escalations, may need to be coordinated with the private
-<linux-distros@xxxxxxxxxxxxxxx> mailing list so that distribution vendors
-are well prepared to issue a fixed kernel upon public disclosure of the
-upstream fix. Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start. In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
-
-CVE assignment
---------------
-
-The security team does not normally assign CVEs, nor do we require them
-for reports or fixes, as this can needlessly complicate the process and
-may delay the bug handling. If a reporter wishes to have a CVE identifier
-assigned ahead of public disclosure, they will need to contact the private
-linux-distros list, described above. When such a CVE identifier is known
-before a patch is provided, it is desirable to mention it in the commit
-message if the reporter agrees.
-
-Non-disclosure agreements
--------------------------
+**Confidentiality.** While embargoed information may be shared with trusted
+individuals in order to develop a fix, such information will not be
+published alongside the fix or on any other disclosure channel without the
+permission of the reporter. This includes but is not limited to the
+original bug report and followup discussions (if any), exploits, CVE
+information or the identity of the reporter. All such other information
+submitted to the security list and any follow-up discussions of the report
+are treated confidentially even after the embargo has been lifted, in
+perpetuity.
The Linux kernel security team is not a formal body and therefore unable
to enter any non-disclosure agreements.
+
+Once a patch has been developed, you are encouraged to contact the
+linux-distros list.
+
+Contacting the linux-distros list
+---------------------------------
+
+Fixes for particularly sensitive bugs (such as those that might lead to
+privilege escalations) may need to be coordinated with the private
+linux-distros mailing list (linux-distros@xxxxxxxxxxxxxxx) so that
+distribution vendors are well prepared to release a fixed kernel as soon
+as possible after the public disclosure of the upstream fix. This
+includes verifying the reported issue, testing proposed fixes,
+developing a fix (if none is known yet), and backporting to older kernels
+and other versions.
+
+The linux-distros list can also help with assigning a CVE for your issue.
+
+**Disclosure.** The linux-distros list has a strict policy of requiring
+reporters to post about the security issue on oss-security within 14 days
+of the list being contacted regardless of whether a patch is available or
+not. It is therefore preferable that you don't send your initial bug
+report to the linux-distros list unless you already have a patch for the
+issue.
+
+**List rules.** The main rules to be aware of when contacting the
+linux-distros list are:
+
+* Don't post about issues that are already public. If your issue has a
+ public patch, but the security impact is not generally known, then you
+ may still post about it.
+
+* The submitter can suggest an embargo end-date, but as a rule, embargoes
+ should not be longer than 7 days, or at most 14 days in exceptional
+ cases. Keep in mind that vendors may prefer to release new kernel
+ packages and/or updates Tuesday through Thursday.
+
+* When the embargo ends, the issue must be disclosed immediately on
+ the oss-security list (see below).
+
+* Prefix your subject with the string "[vs]" to avoid getting rejected
+ by the spam filter.
+
+For the full list of rules, see:
+https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters
+
+**Confidentiality.** Please note that, as opposed to the security list, any
+and all material submitted to the list must be made public once the
+security issue is publicly disclosed, so please do not post information
+to the linux-distros list that cannot be made public.
+
+Contacting the oss-security list
+--------------------------------
+
+When your security issue is public, or you wish to make your issue public,
+you can write to the oss-security list (oss-security@xxxxxxxxxxxxxxxxxx).
+This is a public list (anybody can subscribe and view the list archives)
+and it is not restricted to Linux kernel issues.
+
+The oss-security list typically does not assign CVEs or accept requests for
+CVE assignments.
+
+**List rules.** Please do not cross-post to other lists when writing to
+this list. Make sure to read the other list rules before posting:
+https://oss-security.openwall.org/wiki/mailing-lists/oss-security
+.
+
+..
+ If you modify this document, please consider the following:
+
+ 1) The most important information should be at the top (preferably in
+ the opening paragraph). This means contacting <security@xxxxxxxxxx>;
+ if somebody doesn't read any further than that, at least the security
+ team will have the report.
+
+ 2) Make the differences between the lists extremely clear. The old
+ version did make an attempt at this, but the lines were not drawn
+ clearly enough.
+
+ 3) Emphasize some of the posting rules which can be confusing to new
+ people (e.g. the fact that posting to linux-distros means you must
+ propose an embargo date and that this cannot under any circumstances
+ be more than 14 days).
+
+ 4) The document should be a "step-by-step process" as much as possible,
+ so that you can use it as a guide while reporting an issue instead of
+ having to search back and forth for the thing you're looking for.
--
2.35.1.46.g38062e73e0