Date: Tue, 24 May 2022 15:56:46 +0200 From: Vegard Nossum <vegard.nossum@...cle.com> To: oss-security@...ts.openwall.com Subject: Re: linux-distros list policy and Linux kernel On 5/24/22 15:29, Solar Designer wrote: > On Sun, May 22, 2022 at 09:19:51PM +0200, Solar Designer wrote: >> it looks like Vegard Nossum and maybe Thadeu Lima de Souza Cascardo >> intend to propose changes to the kernel's >> Documentation/admin-guide/security-bugs.rst: >> >> On Fri, May 20, 2022 at 10:14:07AM +0200, Vegard Nossum wrote: >>> I'll respond a bit later with a slightly more detailed option >>> that also includes potential modifications to the in-kernel >>> documentation as displayed on kernel.org. [...] > If there are no objections, Vegard can you please suggest specific > edits accordingly, and if there are no objections to those either, > then submit them as a patch? I was going to propose completely rewriting the document to be clearer for reporters and to be more in line with both firstname.lastname@example.org and linux-distros policies. I'll include the full rewritten document here so you can reply to specific bits of it and I'll also give people a chance to comment on it here before attempting to submit it upstream (if somebody wants a Cc on that submission let me know). Rendered HTML: https://vegard.github.io/security/Documentation/output/admin-guide/security-bugs.html And just for comparison, this is the current upstream version: https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html Vegard 8<-------------------------------------- .. 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@...nel.org>; 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. .. _securitybugs: 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 at security@...nel.org, henceforth "the security list". This is a closed list of trusted developers who will help verify the bug report and develop a patch. 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; CVE assignment, disclosure to distributions, and public disclosure happens on different lists with different people. Here is a quick overview of the various lists: .. list-table:: :widths: 35 10 20 35 :header-rows: 1 * - List address - Open? - Purpose - Members * - security@...nel.org - Closed - Reporting; patch development - Trusted kernel developers * - linux-distros@...openwall.org - Closed - Coordination; CVE assignment; patch development, testing, and backporting - Linux distribution representatives * - oss-security@...ts.openwall.com - Public - 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. 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 distros list. **Disclosure.** The security list prefers to merge fixes into the appropriate public git repository as soon as they become available. However, you or an affected party may request that the patch be withheld for up to 7 calendar days from the availability of the patch, with an exceptional extension to 14 calendar days if it is agreed that the bug is critical enough to warrant 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. **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. **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; see below. 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@...openwall.org) 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@...ts.openwall.com). 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 .
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.