[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5299cec-6ec4-d69a-188c-36b88618947b@oracle.com>
Date: Tue, 24 May 2022 15:56:46 +0200
From: Vegard Nossum <vegard.nossum@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros list policy and Linux kernel
On 5/24/22 15:29, Solar Designer wrote:
> On Sun, May 22, 2022 at 09:19:51PM +0200, Solar Designer wrote:
>> it looks like Vegard Nossum and maybe Thadeu Lima de Souza Cascardo
>> intend to propose changes to the kernel's
>> Documentation/admin-guide/security-bugs.rst:
>>
>> On Fri, May 20, 2022 at 10:14:07AM +0200, Vegard Nossum wrote:
>>> I'll respond a bit later with a slightly more detailed option
>>> that also includes potential modifications to the in-kernel
>>> documentation as displayed on kernel.org.
[...]
> If there are no objections, Vegard can you please suggest specific
> edits accordingly, and if there are no objections to those either,
> then submit them as a patch?
I was going to propose completely rewriting the document to be clearer
for reporters and to be more in line with both s@k.o and linux-distros
policies. I'll include the full rewritten document here so you can reply
to specific bits of it and I'll also give people a chance to comment on
it here before attempting to submit it upstream (if somebody wants a Cc
on that submission let me know).
Rendered HTML:
https://vegard.github.io/security/Documentation/output/admin-guide/security-bugs.html
And just for comparison, this is the current upstream version:
https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
Vegard
8<--------------------------------------
..
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@...nel.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:
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 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.
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
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 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.
**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@...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@...ts.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
.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
