Message-ID: <f5b429ff-4644-5930-8860-d0b30fefc514@oracle.com>
Date:   Thu, 2 Jun 2022 19:53:28 +0200
From:   Vegard Nossum <vegard.nossum@...cle.com>
To:     Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        Solar Designer <solar@...nwall.com>
Cc:     linux-kernel@...r.kernel.org, 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>,
        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


On 6/1/22 15:38, Jonathan Corbet wrote:
> I submit that you are breaking your own rule by putting this stuff
> at the top of the document.  I'm not really convinced that you need
> it at all - we don't normally include these sort of instructions -
> but if it has to be here I would put it at the end.

Agreed -- I've moved it to the bottom for now as I think there's value
in expressing the higher-level design of something, but I'm open to
editing/trimming it down and/or moving it to the changelog.

I guess I had the HTML docs more in mind when editing this document as I
think most people probably read this from kernel.org. But you're right
that we shouldn't forget the plaintext readers.

On 6/1/22 18:58, Jonathan Corbet wrote:
> Vegard Nossum <vegard.nossum@...cle.com> writes:
>> +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.  

Done.

>> +Here is a quick overview of the various lists:
>> +
>> +.. list-table::
[...]
> 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).

Great suggestion, I just fixed it up a tiny bit.

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

True. I've changed it to include reviews and testing:

+**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.

>> +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

Removed.

>> +Contacting the linux-distros list 
>> +---------------------------------
[...]
>> +**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?

I get your point, but I think this underestimates the value of having a
single place for reporters to get an overview of the full process that
we want them to follow in the ideal case.

It's been a little bit of a problem that people post to the list without
fully understanding how the list operates. Many reporters copy the list
and are surprised to learn that they are supposed to disclose something
to oss-security.

I think the main pain points have been addressed in the rewrite by
making it clear that everything sent to the list must also be made
public within some interval from when it is posted to the list, and also
that it is preferable to contact s@k.o first, separately, and ensure
there's a patch before engaging distros.

In my mind, having the full process and the most important points for
the linux-distros list in the kernel documentation also ensures that
reporters, Linux kernel developers, the security list people, and the
linux-distros people are all on the same page with what is expected of
each other -- and that everybody is in the loop when changes are made.
In a sense, it's harder to have conflicting policies if they're all (at
least the main points) expressed in a single document.

(As we also wrote on the oss-sec thread, having linux-distros in the
loop on security bugs is incredibly valuable for distros, which is why
it's also in our interest to make sure the recommended process is to
include linux-distros in the official reporting process -- but not at
the expense of forcing premature disclosures or causing friction between
the lists/groups.)

That said, Solar was expressing a similar idea as you in
<https://www.openwall.com/lists/oss-security/2022/05/24/2>, albeit for a
different reason. So I don't know.

I wouldn't go against a consensus either way, but I would hope that we
could try this and see whether keeping it up to date turns out to be a
bigger issue than reporters doing the wrong thing (from our point of view).

Thoughts? (Solar?)

Thanks for the feedback!


Vegard

Powered by blists - more mailing lists