Date:   Wed, 01 Jun 2022 10:58:50 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Vegard Nossum <vegard.nossum@...cle.com>, linux-doc@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org,
        Vegard Nossum <vegard.nossum@...cle.com>,
        Amit Shah <aams@...zon.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Gustavo A . R . Silva" <gustavoars@...nel.org>,
        Jiri Kosina <jkosina@...e.cz>,
        Kees Cook <keescook@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Solar Designer <solar@...nwall.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        Will Deacon <will@...nel.org>, Willy Tarreau <w@....eu>
Subject: Re: [PATCH] Documentation/security-bugs: overhaul

Vegard Nossum <vegard.nossum@...cle.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@...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.

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@...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

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@...nel.org                no Reporting         Trusted kernel
                                                         developers
                                       Patch development
 linux-distros@...openwall.org      no Coordination      Distribution 
                                                         representatives
                                       CVE assignment
                                       Patch development
                                       Testing
                                       Backporting
 oss-security@...ts.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@...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

Powered by blists - more mailing lists