Vegard Nossum <vegard.nossum@xxxxxxxxxx> 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@xxxxxxxxxx, 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@xxxxxxxxxx
> + - Closed
> + - Reporting; patch development
> + - Trusted kernel developers
> + * - linux-distros@xxxxxxxxxxxxxxx
> + - Closed
> + - Coordination; CVE assignment; patch development, testing, and backporting
> + - Linux distribution representatives
> + * - oss-security@xxxxxxxxxxxxxxxxxx
> + - 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@xxxxxxxxxx no Reporting Trusted kernel
developers
Patch development
linux-distros@xxxxxxxxxxxxxxx no Coordination Distribution
representatives
CVE assignment
Patch development
Testing
Backporting
oss-security@xxxxxxxxxxxxxxxxxx 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@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:
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
