[PATCH] Documentation/security-bugs: overhaul

[PATCH] Documentation/security-bugs: overhaul

[Vegard Nossum]

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

Link: https://seclists.org/oss-sec/2022/q2/133
Cc: Amit Shah <aams@amazon.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Solar Designer <solar@openwall.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thorsten Leemhuis <linux@leemhuis.info>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Will Deacon <will@kernel.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 Documentation/admin-guide/security-bugs.rst | 249 +++++++++++++-------
 1 file changed, 164 insertions(+), 85 deletions(-)

See rendered HTML at:
<https://vegard.github.io/security/Documentation/output/admin-guide/security-bugs.html>
(this is probably easier to read than the diff...)

Compare with the existing document:
<https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html>

diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
index 82e29837d5898..5f37b3f1e77dc 100644
--- a/Documentation/admin-guide/security-bugs.rst
+++ b/Documentation/admin-guide/security-bugs.rst
@@ -1,96 +1,175 @@
+..
+    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@kernel.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:
 
-Security bugs
-=============
+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.
-
-Contact
--------
-
-The Linux kernel security team can be contacted by email at
-<security@kernel.org>.  This is a private list of security officers
-who will help verify the bug report and develop and release a fix.
-If you already have a fix, please include it with your report, as
-that can speed up the process considerably.  It is possible that the
-security team will bring in extra help from area maintainers to
-understand and fix the security vulnerability.
-
-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.
-
-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 a
-:doc:`regular patch submission <../process/submitting-patches>`
-(even if you don't have a patch yet): describe the problem and impact, list
+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.
+
+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
+
+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.
+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.
 
-Disclosure and embargoed information
-------------------------------------
-
-The security list is not a disclosure channel.  For that, see Coordination
-below.
-
-Once a robust fix has been developed, the release process starts.  Fixes
-for publicly known bugs are released immediately.
-
-Although our preference is to release fixes for publicly undisclosed bugs
-as soon as they become available, this may be postponed at the request of
-the reporter or an affected party for up to 7 calendar days from the start
-of the release process, with an exceptional extension to 14 calendar days
-if it is agreed that the criticality of the bug requires 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.
-
-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.
-
-In other words our only interest is in getting bugs fixed.  All other
-information submitted to the security list and any followup discussions
-of the report are treated confidentially even after the embargo has been
-lifted, in perpetuity.
-
-Coordination
-------------
-
-Fixes for sensitive bugs, such as those that might lead to privilege
-escalations, may need to be coordinated with the private
-<linux-distros@vs.openwall.org> mailing list so that distribution vendors
-are well prepared to issue a fixed kernel upon public disclosure of the
-upstream fix. Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start. In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
-
-CVE assignment
---------------
-
-The security team does not normally assign CVEs, nor do we require them
-for reports or fixes, as this can needlessly complicate the process and
-may delay the bug handling. If a reporter wishes to have a CVE identifier
-assigned ahead of public disclosure, they will need to contact the private
-linux-distros list, described above. When such a CVE identifier is known
-before a patch is provided, it is desirable to mention it in the commit
-message if the reporter agrees.
-
-Non-disclosure agreements
--------------------------
+**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@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:
+
+* 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@lists.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
+.
-- 
2.35.1.46.g38062e73e0

Re: [PATCH] Documentation/security-bugs: overhaul

[Willy Tarreau]

Hello Vegard,

On Wed, Jun 01, 2022 at 01:03:09AM +0200, Vegard Nossum wrote:
> 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).

Thanks for working on this, I'm having a few comments below.

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

+ "in case none was already proposed".

There's indeed recently a tendency on the list to get a lot of first-time
reports from individuals showing that some work was done trying to make
some code parts fail, but no effort was made to try to figure how these
ought to be addressed, and that costs a lot of time, because once the
analysis was done, the person who knows best about the problem and how
to fix it is the reporter, and we must absolutely encourage that the
work is finished and a candidate patch is proposed. Usually, returning
reporters propose patches, so I think they understand the value in doing
the work properly, which makes me think that we just don't make that
obvious enough from the rules. It's also possible that many reporters
are not used to working with OSS projects and imagine it's inappropriate
of them to propose a fix. But the question that's the most commonly
asked on the list is "do you have a patch for this?".

Overall it seems that reporters are willing to do their best but that
it's never easy to engage in such a bug disclosure process which may
involve short times, and that it can be stressful for the reporters
who forget to do a lot of the parts they would do for more regular
bugs.

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

I think it's also important to explain that sometimes some patches may
be merged ASAP to plug a hole and let them flow to stable branches,
while letting the reporter deal with the full disclosure once they
consider that enough time has elapsed. The recent "dirty pipe" fix was
one of the best examples of a report that went smoothly and allowed the
reporter to work on a nice description of the problem:

    https://dirtypipe.cm4all.com/

There's always this gray area between getting a fix merged and disclosing
all the details of the bug. A bug indeed becomes public once the fix is
merged, but that doesn't mean that all the details are shared, so the
reporter still has the opportunity to write their story about it. The
reporter must only understand that it's only a matter of time between
the merge of a fix and the moment someone will understand how to exploit
the bug and publish about it.

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

While this part renders well on your HTML version, I'm afraid it's totally
unreadable here in the text version, and this document is supposed to be
the one reporters will use. I suggest to try again with an item list
instead of a table.

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

I'm still having an issue here. Originally it was something along "up
to 5 days if there's a really compelling reason". Then it was extended
to 7 days in order to better match the tuesday-to-thursday range. Then
"up to 14 days" for exceptional cases (i.e. hopefully never). But the
wording tends to make all reporters think that asking for 7 days is
normal. We really need to make it even clearer that:
  - the default is no embargo

  - if there is a *really compelling reason* (that has to be justified
    by the reporter), it may reach *up to 7 days*

  - in exceptional cases (the bug-of-the-year with a risk of massive
    exploitation requiring coordination) it may be extended to 14 days

  - "I already contacted this or that list so you must respect THEIR
    embargo" is NOT a valid justification to withhold a fix

  - dealing with embargoes is a pain, a withheld patch risks to be
    forgotten or confused with a previous version of the patch that
    appeared in discussions, it's difficult to synchronize stable
    and mainline, and the risk that it leaks by accident grows with
    time and with the number of participants in a discussion.

Just my two cents.
Willy

Re: [PATCH] Documentation/security-bugs: overhaul

[Jonathan Corbet]

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

...but they do appear in the plain-text document, which must also be
readable.  Thus...

[...]

> diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> index 82e29837d5898..5f37b3f1e77dc 100644
> --- a/Documentation/admin-guide/security-bugs.rst
> +++ b/Documentation/admin-guide/security-bugs.rst
> @@ -1,96 +1,175 @@
> +..
> +    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@kernel.org>;
> +    if somebody doesn't read any further than that, at least the security
> +    team will have the report.

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.

[Haven't had a chance to look at the real material yet]

Thanks,

jon

Re: [PATCH] Documentation/security-bugs: overhaul

[Jonathan Corbet]

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

Re: [PATCH] Documentation/security-bugs: overhaul

[Vegard Nossum]

On 6/1/22 05:12, Willy Tarreau wrote:
> On Wed, Jun 01, 2022 at 01:03:09AM +0200, Vegard Nossum wrote:
>> 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).
> 
> Thanks for working on this, I'm having a few comments below.

Thanks for the comments, I'll send an updated v2 shortly, just wanted to
address individual comments.

>> +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.
> 
> + "in case none was already proposed".

Done.

> There's indeed recently a tendency on the list to get a lot of first-time
> reports from individuals showing that some work was done trying to make
> some code parts fail, but no effort was made to try to figure how these
> ought to be addressed, and that costs a lot of time, because once the
> analysis was done, the person who knows best about the problem and how
> to fix it is the reporter, and we must absolutely encourage that the
> work is finished and a candidate patch is proposed. Usually, returning
> reporters propose patches, so I think they understand the value in doing
> the work properly, which makes me think that we just don't make that
> obvious enough from the rules. It's also possible that many reporters
> are not used to working with OSS projects and imagine it's inappropriate
> of them to propose a fix. But the question that's the most commonly
> asked on the list is "do you have a patch for this?".
> 
> Overall it seems that reporters are willing to do their best but that
> it's never easy to engage in such a bug disclosure process which may
> involve short times, and that it can be stressful for the reporters
> who forget to do a lot of the parts they would do for more regular
> bugs.

I think there's also an argument for encouraging reports whether the
person has a patch or not, presumably it is better to know about an
issue so it can be prioritized against all other known issues, no?

In any case, I have amended the text like this:

+Reporters are encouraged to propose patches, participate in the
+discussions of a fix, and test patches.

>> +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.
> 
> I think it's also important to explain that sometimes some patches may
> be merged ASAP to plug a hole and let them flow to stable branches,
> while letting the reporter deal with the full disclosure once they
> consider that enough time has elapsed. The recent "dirty pipe" fix was
> one of the best examples of a report that went smoothly and allowed the
> reporter to work on a nice description of the problem:
> 
>     https://dirtypipe.cm4all.com/
> 
> There's always this gray area between getting a fix merged and disclosing
> all the details of the bug. A bug indeed becomes public once the fix is
> merged, but that doesn't mean that all the details are shared, so the
> reporter still has the opportunity to write their story about it. The
> reporter must only understand that it's only a matter of time between
> the merge of a fix and the moment someone will understand how to exploit
> the bug and publish about it.

I've changed the bit above to address Jon's comments as well:

+Note that the main interest of the kernel security list is in getting
+bugs fixed and getting patches reviewed, tested, and merged; CVE
+assignment, disclosure to distributions, and public disclosure happen
+on different lists with different people, as described below.

We could maybe add something like this to the "Disclosure" section of
"Contacting the security list":

+Please note that although a fix is public, there may still be value
+in withholding the details of its security relevance and/or how to exploit
+it for another while; see below for when and how to properly disclose the
+security impact of your findings.

I'm not totally happy with the wording here, probably because I don't
really agree that patches should be published ahead of disclosure in the
first place. Anyway, happy to take other suggestions as long as we can
keep it short.

>> +Here is a quick overview of the various lists:
>> +
>> +.. list-table::
[snip]
> While this part renders well on your HTML version, I'm afraid it's totally
> unreadable here in the text version, and this document is supposed to be
> the one reporters will use. I suggest to try again with an item list
> instead of a table.

Jon had a good way to do this that looks good in both text and HTML.

>> +**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.
> 
> I'm still having an issue here. Originally it was something along "up
> to 5 days if there's a really compelling reason". Then it was extended
> to 7 days in order to better match the tuesday-to-thursday range. Then
> "up to 14 days" for exceptional cases (i.e. hopefully never). But the
> wording tends to make all reporters think that asking for 7 days is
> normal. We really need to make it even clearer that:
>   - the default is no embargo
> 
>   - if there is a *really compelling reason* (that has to be justified
>     by the reporter), it may reach *up to 7 days*
> 
>   - in exceptional cases (the bug-of-the-year with a risk of massive
>     exploitation requiring coordination) it may be extended to 14 days
> 
>   - "I already contacted this or that list so you must respect THEIR
>     embargo" is NOT a valid justification to withhold a fix
> 
>   - dealing with embargoes is a pain, a withheld patch risks to be
>     forgotten or confused with a previous version of the patch that
>     appeared in discussions, it's difficult to synchronize stable
>     and mainline, and the risk that it leaks by accident grows with
>     time and with the number of participants in a discussion.

I've changed this section to:

+**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.
+However, in exceptional cases, you or an affected party may request that
+the patch be withheld for some days; as a rule, the maximum is 7 days.
+Only in truly exceptional cases will the security list consider deferring
+the publication of a fix beyond this, and the only valid reason for doing
+so would be to accommodate the logistics of QA and large scale rollouts
+that require release coordination.

Note that I'm only trying to clarify the existing policy here -- I'm not
in a position to change it. There is no mention of 5 days in the current
document, which is why I've kept the wording of "the maximum is 7 days".
The justification for the current wording was given in commit
544b03da39e2d7b4961d3163976ed4bfb1fac509. If there's a consensus to
change it back to 5 days then I can incorporate that, or somebody can do
an incremental patch.

In any case, I would assume these are also things that can/should be
discussed on a per-bug basis as long as the overarching rules have been
given here. What do you think?

Thanks,


Vegard

Re: [PATCH] Documentation/security-bugs: overhaul

[Vegard Nossum]

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

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

Re: [PATCH] Documentation/security-bugs: overhaul

[Willy Tarreau]

On Thu, Jun 02, 2022 at 05:34:48PM +0200, Vegard Nossum wrote:
> > Overall it seems that reporters are willing to do their best but that
> > it's never easy to engage in such a bug disclosure process which may
> > involve short times, and that it can be stressful for the reporters
> > who forget to do a lot of the parts they would do for more regular
> > bugs.
> 
> I think there's also an argument for encouraging reports whether the
> person has a patch or not, presumably it is better to know about an
> issue so it can be prioritized against all other known issues, no?

It depends. For a few months now we've seen a huge increase of reports
for things ranging from "if I modify this driver this way I can make it
fail so I think it could be insecure" to "this outdated driver that is
not enabled in any distro anymore has a one-byte info leak bug, can I
get my CVE". There have been weeks with 2 of them every single day. It's
obvious that there's a quest of a CVE to be held as a trophee, and that
for a CVE, a security bug is needed, and that for this it ought to be
demonstrated that some random bugs in certain circumstances could have
a security impact. Thus there is a huge bias.

I would really like it if we could get back to what works fine: use
the security list only for currently exploitable bugs that are not
trivially worked around, and please use public lists for everything
else. It takes way longer to fix a bug in a small team having to
forward messages to maintainers, trying to fix in a small group without
knowing if we're going to break someone's use case than it takes when
a non-critical issue is discussed publicly. And security fixes that
cause regressions are the worst that can happen because they discourage
users from regularly applying fixes. As such the vast majority of bugs
ought to be discussed publicly, on the relevant lists. Bug given that
some reporters are not interested in getting a bug fixed but just in
getting a trophee, that's difficult to get a patch from them and to
move the discussion to a public place where the fix will just be
handled like with any regular bug.

But by doing this we'd get more time to work on real problems. Usually
researchers who found complex problems have some patches to propose
because that was needed to confirm their analysis. It's common that
these patches are not suitable for merging but they illustrate the
problem and help bring in the relevant people. Also they give many
ideas of things to look for much faster than by trying a reproducer,
which many times only works in a specific context. Maybe we should
mention this point by the way, that we're not necessarily asking for
a final patch but at least a candidate or an illustrative one.

> In any case, I have amended the text like this:
> 
> +Reporters are encouraged to propose patches, participate in the
> +discussions of a fix, and test patches.

Looks good.

> > There's always this gray area between getting a fix merged and disclosing
> > all the details of the bug. A bug indeed becomes public once the fix is
> > merged, but that doesn't mean that all the details are shared, so the
> > reporter still has the opportunity to write their story about it. The
> > reporter must only understand that it's only a matter of time between
> > the merge of a fix and the moment someone will understand how to exploit
> > the bug and publish about it.
> 
> I've changed the bit above to address Jon's comments as well:
> 
> +Note that the main interest of the kernel security list is in getting
> +bugs fixed and getting patches reviewed, tested, and merged; CVE
> +assignment, disclosure to distributions, and public disclosure happen
> +on different lists with different people, as described below.

Looks good.

> We could maybe add something like this to the "Disclosure" section of
> "Contacting the security list":
> 
> +Please note that although a fix is public, there may still be value
> +in withholding the details of its security relevance and/or how to exploit
> +it for another while; see below for when and how to properly disclose the
> +security impact of your findings.
> 
> I'm not totally happy with the wording here, probably because I don't
> really agree that patches should be published ahead of disclosure in the
> first place. Anyway, happy to take other suggestions as long as we can
> keep it short.

I don't know how to adjust the wording but I think that the spirit is
there. By the way there's something I would like to see added as well
to this, which is the the ultimate goal is that a bug fixed is perfectly
understood and documented. So either the details of the cause of the bug
are in the commit message, or the researchers prefer not to publish them
yet because they intend to present them at a conference or in a blog
article (pretty common), which will serve as a reference for to get all
the gory details. But in this case there must be a reasonable delay, it's
not acceptable that the details of the problem are withheld for months.

As such I think that we could mention something along:

  Upon reporters' request in case a forthcoming presentation of the issue
  is planned, it may occasionally be accepted to temporarily keep out some
  of the detailed impacts of the issue, however the security team reserves
  the right to publicize these details if no other publication happens in
  a reasonable time frame or as soon as the fixes are found to cause a
  regression.

Because quite frankly, not being able to explain exactly why a patch is
done this way and not slightly differently is not acceptable.

> >> +Here is a quick overview of the various lists:
> >> +
> >> +.. list-table::
> [snip]
> > While this part renders well on your HTML version, I'm afraid it's totally
> > unreadable here in the text version, and this document is supposed to be
> > the one reporters will use. I suggest to try again with an item list
> > instead of a table.
> 
> Jon had a good way to do this that looks good in both text and HTML.

Yeah I liked it as well, thanks Jon!

> >> +**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.
> > 
> > I'm still having an issue here. Originally it was something along "up
> > to 5 days if there's a really compelling reason". Then it was extended
> > to 7 days in order to better match the tuesday-to-thursday range. Then
> > "up to 14 days" for exceptional cases (i.e. hopefully never). But the
> > wording tends to make all reporters think that asking for 7 days is
> > normal. We really need to make it even clearer that:
> >   - the default is no embargo
> > 
> >   - if there is a *really compelling reason* (that has to be justified
> >     by the reporter), it may reach *up to 7 days*
> > 
> >   - in exceptional cases (the bug-of-the-year with a risk of massive
> >     exploitation requiring coordination) it may be extended to 14 days
> > 
> >   - "I already contacted this or that list so you must respect THEIR
> >     embargo" is NOT a valid justification to withhold a fix
> > 
> >   - dealing with embargoes is a pain, a withheld patch risks to be
> >     forgotten or confused with a previous version of the patch that
> >     appeared in discussions, it's difficult to synchronize stable
> >     and mainline, and the risk that it leaks by accident grows with
> >     time and with the number of participants in a discussion.
> 
> I've changed this section to:
> 
> +**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.
> +However, in exceptional cases, you or an affected party may request that
> +the patch be withheld for some days; as a rule, the maximum is 7 days.
> +Only in truly exceptional cases will the security list consider deferring
> +the publication of a fix beyond this, and the only valid reason for doing
> +so would be to accommodate the logistics of QA and large scale rollouts
> +that require release coordination.

I think that's better that way already, thanks!

> Note that I'm only trying to clarify the existing policy here -- I'm not
> in a position to change it.

Of course, rest assured I'm not asking for this, I only mentioned it to
illustrate the existing drift already that happened due to the need to
coordinate, and that I wouldn't like to see the vendor-sec mess resurrected.

> There is no mention of 5 days in the current
> document, which is why I've kept the wording of "the maximum is 7 days".

Of course (that was the good old days when there was less bureaucracy
in the supply chain :-)).

> The justification for the current wording was given in commit
> 544b03da39e2d7b4961d3163976ed4bfb1fac509. If there's a consensus to
> change it back to 5 days then I can incorporate that, or somebody can do
> an incremental patch.

I don't think anyone is asking for this. We just need to make people
understandthat 7 days is already not a normal delay for the vast majority
of bugs, and the reasons Will explained in the commit above definitely
apply to critical bugs that require immediate action, not the "look, I
can make this webcam driver oops".

> In any case, I would assume these are also things that can/should be
> discussed on a per-bug basis as long as the overarching rules have been
> given here. What do you think?

It's already the case, but many reporters are first-timers, and as you
know, security reporting rules are complex things which put a lot of
stress on them (especially when the wording of rules like linux-distros
make them engage on disclosing at certain steps), so they tend to take
the words they read as being very strict and the default rules. Most
returning reporters are completely relaxed about delays and usually
do not even ask for one. And conversely some bugs take a long time to
figure a fix and can drag for a month or more because they're too
difficult. So that's definitely on a case-by-base basis, and I think
it's important that the reporters understand what options are left to
them once they sent their message. Everyone wants efficiency there.

Cheers,
Willy

Re: [PATCH] Documentation/security-bugs: overhaul

[Mauro Carvalho Chehab]

Em Wed, 01 Jun 2022 10:58:50 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

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

Yeah, I guess the right syntax is 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
  =============================== ===== ================= ===============

Regards,
Mauro

Re: [PATCH] Documentation/security-bugs: overhaul

[Vegard Nossum]

On 6/3/22 08:49, Willy Tarreau wrote:
> On Thu, Jun 02, 2022 at 05:34:48PM +0200, Vegard Nossum wrote:
>> I think there's also an argument for encouraging reports whether the
>> person has a patch or not, presumably it is better to know about an
>> issue so it can be prioritized against all other known issues, no?
> 
> It depends. For a few months now we've seen a huge increase of reports
> for things ranging from "if I modify this driver this way I can make it
> fail so I think it could be insecure" to "this outdated driver that is
> not enabled in any distro anymore has a one-byte info leak bug, can I
> get my CVE". There have been weeks with 2 of them every single day. It's
> obvious that there's a quest of a CVE to be held as a trophee, and that
> for a CVE, a security bug is needed, and that for this it ought to be
> demonstrated that some random bugs in certain circumstances could have
> a security impact. Thus there is a huge bias.
> 
> I would really like it if we could get back to what works fine: use> the security list only for currently exploitable bugs that are not
> trivially worked around, and please use public lists for everything
> else. It takes way longer to fix a bug in a small team having to
> forward messages to maintainers, trying to fix in a small group without
> knowing if we're going to break someone's use case than it takes when
> a non-critical issue is discussed publicly. And security fixes that
> cause regressions are the worst that can happen because they discourage
> users from regularly applying fixes. As such the vast majority of bugs
> ought to be discussed publicly, on the relevant lists. Bug given that
> some reporters are not interested in getting a bug fixed but just in
> getting a trophee, that's difficult to get a patch from them and to
> move the discussion to a public place where the fix will just be
> handled like with any regular bug.

I think this points to a bigger problem, but not with CVEs being held up
as trophies. There's already a huge monetary incentive to find bugs and
sell them as 0-days so IMHO we _should_ be encouraging people to find
bugs and either fix or report them, whether privately or publicly. If
having CVEs helps with that, that ought to be a good thing...

If you think a reported issue is not security-relevant, can you not
simply ask/encourage the reporter to make a public post instead?

If the security team is swamped with legitimate, security-relevant
reports, then that sounds like an issue with manpower and/or
organization. In my (admittedly limited) experience, Linus tends to be
one of the first to reply, so maybe having a designated person or group
to triage issues (maybe in a rota system) before engaging the rest of
the team could take some of the pressure off?

> I don't know how to adjust the wording but I think that the spirit is
> there. By the way there's something I would like to see added as well
> to this, which is the the ultimate goal is that a bug fixed is perfectly
> understood and documented. So either the details of the cause of the bug
> are in the commit message, or the researchers prefer not to publish them
> yet because they intend to present them at a conference or in a blog
> article (pretty common), which will serve as a reference for to get all
> the gory details. But in this case there must be a reasonable delay, it's
> not acceptable that the details of the problem are withheld for months.
> 
> As such I think that we could mention something along:
> 
>   Upon reporters' request in case a forthcoming presentation of the issue
>   is planned, it may occasionally be accepted to temporarily keep out some
>   of the detailed impacts of the issue, however the security team reserves
>   the right to publicize these details if no other publication happens in
>   a reasonable time frame or as soon as the fixes are found to cause a
>   regression.
> 
> Because quite frankly, not being able to explain exactly why a patch is
> done this way and not slightly differently is not acceptable.

This unfortunately directly contradicts the current policy as stated:

"All other information submitted to the security list and any followup
discussions of the report are treated confidentially even after the
embargo has been lifted, in perpetuity."

So again, unless there's a clear consensus to change this, I wouldn't be
comfortable making the change now.

If I could make a different suggestion (which is in the same spirit as
the rewrite, actually), the security team could encourage the reporter
to report to linux-distros once there is a patch or the patch is public
-- that way, it's: 1) not on the security team to disclose anything, 2)
distros get a heads up on the patch, and 3) everybody gets to know about
the security impact of the bug when it is eventually posted to
oss-security within 1-2 weeks.

Thanks for your comments/explanations, it certainly helps to have more
perspective.


Vegard

Re: [PATCH] Documentation/security-bugs: overhaul

[Willy Tarreau]

Hi Vegard,

On Mon, Jun 06, 2022 at 04:21:40PM +0200, Vegard Nossum wrote:
> I think this points to a bigger problem, but not with CVEs being held up
> as trophies. There's already a huge monetary incentive to find bugs and
> sell them as 0-days so IMHO we _should_ be encouraging people to find
> bugs and either fix or report them, whether privately or publicly. If
> having CVEs helps with that, that ought to be a good thing...

Yes I'm fine with this approach, provided that we encourage the reporters
to figure by themselves where to report them. In my opinion, what only
refers to very old hardware, to anything that's not built by default,
that requires code change to prove the problem, or that is only
theoretical ought not be sent to a closed list. The purpose of closed
lists is to deal with emergencies, issues that could put users in trouble
if they were disclosed before a fix is merged.

> If you think a reported issue is not security-relevant, can you not
> simply ask/encourage the reporter to make a public post instead?

We regularly do, but it's important also not to send a cold shower to
the person who already prepared their work and report in a direction
that they thought was the most suitable one, just to learn the hard
way that what they found was not that important.

> If the security team is swamped with legitimate, security-relevant
> reports, then that sounds like an issue with manpower and/or
> organization. In my (admittedly limited) experience, Linus tends to be
> one of the first to reply, so maybe having a designated person or group
> to triage issues (maybe in a rota system) before engaging the rest of
> the team could take some of the pressure off?

Actually all of the members are expected to respond. I personally
consider it as a failure when Linus has to respond to a message that
stayed there for a while. And it does happen quite a bit, yes. I guess
that often none of us feels like we're knowledgeable on a particular
report.

> > As such I think that we could mention something along:
> > 
> >   Upon reporters' request in case a forthcoming presentation of the issue
> >   is planned, it may occasionally be accepted to temporarily keep out some
> >   of the detailed impacts of the issue, however the security team reserves
> >   the right to publicize these details if no other publication happens in
> >   a reasonable time frame or as soon as the fixes are found to cause a
> >   regression.
> > 
> > Because quite frankly, not being able to explain exactly why a patch is
> > done this way and not slightly differently is not acceptable.
> 
> This unfortunately directly contradicts the current policy as stated:
> 
> "All other information submitted to the security list and any followup
> discussions of the report are treated confidentially even after the
> embargo has been lifted, in perpetuity."

IMHO there's a big difference between disclosing confidential information
(which we never do) and explaining what makes a bug have a security
impact. The purpose of the commit message is to serve as arguments to
defend the commit's presence in the tree. Most of the info must be there,
except what's not needed to understand the bug (e.g. exploitation method).
Then the rest of the details ought to be disclosed fast enough for the
commit to be defended. Of course the context where the issue was discovered
has to remain confidential.

> So again, unless there's a clear consensus to change this, I wouldn't be
> comfortable making the change now.

Yeah I'm fine with this of course, but I wanted to take the opportunity
of your discussion to bring these concerns since they're also about the
instructions in the doc.

> If I could make a different suggestion (which is in the same spirit as
> the rewrite, actually), the security team could encourage the reporter
> to report to linux-distros once there is a patch or the patch is public
> -- that way, it's: 1) not on the security team to disclose anything, 2)
> distros get a heads up on the patch, and 3) everybody gets to know about
> the security impact of the bug when it is eventually posted to
> oss-security within 1-2 weeks.

Maybe that could work, let's keep thinking about this.

> Thanks for your comments/explanations, it certainly helps to have more
> perspective.

You're welcome. We're all in the same boat :-)

Willy