Messages in this thread | | | From | Jonathan Corbet <> | Subject | Re: [PATCH] Documentation/security-bugs: overhaul | Date | Wed, 01 Jun 2022 10:58:50 -0600 |
| |
Vegard Nossum <vegard.nossum@oracle.com> writes:
> 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 top of the document itself (these will not appear in the rendered > document).
OK, some other thoughts...
[...]
> +Linux kernel security team at security@kernel.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.
Adding "as described below" or some such might be helpful for readers who are mostly interested in those things.
> +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@kernel.org > + - Closed > + - Reporting; patch development > + - Trusted kernel developers > + * - linux-distros@vs.openwall.org > + - Closed > + - Coordination; CVE assignment; patch development, testing, and backporting > + - Linux distribution representatives > + * - oss-security@lists.openwall.com > + - Public > + - Disclosure > + - General public
Please don't use list-table, that's totally unreadable in the plain-text format. How about something like:
=============================== ===== ================= =============== List address Open? Purpose Members =============================== ===== ================= =============== security@kernel.org no Reporting Trusted kernel developers Patch development linux-distros@vs.openwall.org no Coordination Distribution representatives CVE assignment Patch development Testing Backporting oss-security@lists.openwall.com yes Disclosure General public =============================== ===== ================= ===============
(Note I haven't tried to format this, there's probably an error in there somewhere).
> +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 linux-distros list. > + > +**Disclosure.** The security list prefers to merge fixes into the > +appropriate public git repository as soon as they become available.
More to the point, the idea is to get *review attention* onto the patches, presumably before they are commited to some repo, right? That's my understanding from the oss-security discussion, anyway. So the first disclosure may not be when it shows up in a repo, as suggested here.
[...]
> +Once a patch has been developed, you are encouraged to contact the > +linux-distros list; see below.
Nit: "see below" seems unnecessary when "below" is the next line down
> +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@vs.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:
So this seems certain to go out of date when the other list's rules change. I wonder if it would be better just to tell readers they need to be aware of that list's rules and give a pointer?
Thanks,
jon
| |