[v3,0/7] Documentation/security-bugs: overhaul

  Hi,

This is v3 of clarifying our documentation for reporting security
issues.

The current document is 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.

Lots of people have been confused about the 7/14 days of the kernel list
vs. the 7/14 days of the distros list, the fact that these are two
separate lists, etc. Many reporters contact distros first, or submit
their report to both lists at the same time (which has the unfortunate
effect of starting off the disclosure countdown for the distros list
before s@k.o has had a chance to look at the report). I've shared the v2
document with a couple of people who submitted reports and they said
they found it a lot clearer. 

Probably the easiest way to see the end result of this series is to view the
rendered HTML which I've put here:
https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html

oss-security discussion prompting the change:
https://www.openwall.com/lists/oss-security/2022/05/15/1

v1 submission:
https://lore.kernel.org/all/20220531230309.9290-1-vegard.nossum@oracle.com/

v2 submission:
https://lore.kernel.org/all/20220606194850.26122-1-vegard.nossum@oracle.com/

Changes:

v2: address feedback from Willy Tarreau and Jonathan Corbet

v3: move from admin-guide/ to process/; address feedback from Will
Deacon (including reverting back to some of the original phrasing);
split into multiple patches


Vegard

Vegard Nossum (7):
  Documentation/security-bugs: move from admin-guide/ to process/
  Documentation/security-bugs: misc. improvements
  Documentation/security-bugs: improve security list section
  Documentation/security-bugs: add linux-distros and oss-security
    sections
  Documentation/security-bugs: add table of lists
  Documentation/security-bugs: clarify hardware vs. software
    vulnerabilities
  Documentation/security-bugs: document document design

 Documentation/admin-guide/index.rst           |   1 -
 .../admin-guide/reporting-issues.rst          |   4 +-
 Documentation/admin-guide/security-bugs.rst   |  96 ----------
 Documentation/process/howto.rst               |   2 +-
 Documentation/process/index.rst               |   9 +-
 .../process/researcher-guidelines.rst         |   2 +-
 Documentation/process/security-bugs.rst       | 181 ++++++++++++++++++
 Documentation/process/stable-kernel-rules.rst |   2 +-
 Documentation/process/submitting-patches.rst  |   2 +-
 .../it_IT/admin-guide/security-bugs.rst       |   2 +-
 .../it_IT/process/submitting-patches.rst      |   2 +-
 Documentation/translations/ja_JP/howto.rst    |   2 +-
 Documentation/translations/ko_KR/howto.rst    |   2 +-
 Documentation/translations/sp_SP/howto.rst    |   2 +-
 .../sp_SP/process/submitting-patches.rst      |   2 +-
 .../zh_CN/admin-guide/security-bugs.rst       |   2 +-
 .../translations/zh_CN/process/howto.rst      |   2 +-
 .../zh_TW/admin-guide/security-bugs.rst       |   2 +-
 .../translations/zh_TW/process/howto.rst      |   2 +-
 MAINTAINERS                                   |   4 +-
 20 files changed, 207 insertions(+), 116 deletions(-)
 delete mode 100644 Documentation/admin-guide/security-bugs.rst
 create mode 100644 Documentation/process/security-bugs.rst
  

On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
> Hi,
> 
> This is v3 of clarifying our documentation for reporting security
> issues.
> 
> The current document is 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.
> 
> Lots of people have been confused about the 7/14 days of the kernel list
> vs. the 7/14 days of the distros list, the fact that these are two
> separate lists, etc. Many reporters contact distros first, or submit
> their report to both lists at the same time (which has the unfortunate
> effect of starting off the disclosure countdown for the distros list
> before s@k.o has had a chance to look at the report). I've shared the v2
> document with a couple of people who submitted reports and they said
> they found it a lot clearer. 
> 
> Probably the easiest way to see the end result of this series is to view the
> rendered HTML which I've put here:
> https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html

Thanks for doing this, it looks much better, but I do have some
objections with it.

First off, you didn't cc: the security@k.o group to see if they agree
with this, any specific reason why?  :)

Secondly, and the bigger one, I think we should just drop all of the
references to linux-distros and oss-security entirely, as those are
groups that are outside of our control and interaction and have
different rules that we might not agree with.  They also just a tiny
subset of Linux users and companies and as such do not really reflect
the majority of where Linux is used anymore.

But overall I like the slimmer size, so perhaps the end result just
being the first two major sections would be best.  Let me take those
changes first and we can see how the result looks for now to see if that
will resolve some of the major issues the security@k.o group have right
now with reports (i.e. CVE requests, other group's disclosure rules and
dates).

thanks,

greg k-h
  

On Mon, Mar 06, 2023 at 07:02:14AM +0100, Greg Kroah-Hartman wrote:
> Secondly, and the bigger one, I think we should just drop all of the
> references to linux-distros and oss-security entirely, as those are
> groups that are outside of our control and interaction and have
> different rules that we might not agree with.  They also just a tiny
> subset of Linux users and companies and as such do not really reflect
> the majority of where Linux is used anymore.

I'm wondering if instead they shouldn't just be mentioned as a warning
about the risk of leak or forced disclosure. We know that reporters may
find the address from various places, including various sites that may
enumerate the long list of potential contacts, and not just this doc.
It can be useful to have just a paragraph warning about the fact that
oss-sec is public and that linux-distros has this strict disclosure
policy without consideration for the availability of a fix, in order
to warn them to only contact such lists once the fix is available and
tested if they want to, but never before. Anything we can do to help
serious reporters (i.e. those who are really embarrassed with a bug,
not those who seek a Curiculum Vitae Enhancer) should be done. It's
always a stressful moment to report a security issue on a project,
you always fear that you might be doing an irreversible mistake, so
whatever info we can pass about the risks (or lack of) should be
welcome I guess.

Willy
  

On Mon, Mar 06, 2023 at 07:35:34AM +0100, Willy Tarreau wrote:
> On Mon, Mar 06, 2023 at 07:02:14AM +0100, Greg Kroah-Hartman wrote:
> > Secondly, and the bigger one, I think we should just drop all of the
> > references to linux-distros and oss-security entirely, as those are
> > groups that are outside of our control and interaction and have
> > different rules that we might not agree with.  They also just a tiny
> > subset of Linux users and companies and as such do not really reflect
> > the majority of where Linux is used anymore.
> 
> I'm wondering if instead they shouldn't just be mentioned as a warning
> about the risk of leak or forced disclosure. We know that reporters may
> find the address from various places, including various sites that may
> enumerate the long list of potential contacts, and not just this doc.
> It can be useful to have just a paragraph warning about the fact that
> oss-sec is public and that linux-distros has this strict disclosure
> policy without consideration for the availability of a fix, in order
> to warn them to only contact such lists once the fix is available and
> tested if they want to, but never before. Anything we can do to help
> serious reporters (i.e. those who are really embarrassed with a bug,
> not those who seek a Curiculum Vitae Enhancer) should be done. It's
> always a stressful moment to report a security issue on a project,
> you always fear that you might be doing an irreversible mistake, so
> whatever info we can pass about the risks (or lack of) should be
> welcome I guess.

That's a good idea, if it can be worded in a way that reflects that is
is not any sort of requirement or that it is normal part of our
development process.

thanks,

greg k-h
  

Hi Vegard,

first, thanks for doing this work.

On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
> Probably the easiest way to see the end result of this series is to view the
> rendered HTML which I've put here:
> https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html

I'm seeing a few points that could be improved but I don't have much to
propose right now, I'll just enumerate issues we've faced in the past or
that continue to pop up from time to time and that require extra effort
from the team:

  - I'm not seeing anywhere that the security list is *exclusively*
    for kernel issues. That might explain why about once a week or so
    we receive messages like "there's a bug in that userland tool" or
    "we've found an XSS issue on your website". It's written that kernel
    bugs should be reported to the security list but I think we should
    strengthen that by adding "This list is exclusively used for Linux
    kernel security reports, please do not report issues affecting any
    other component there".

  - we always need to be able to describe the nature of a bug in the
    commit message so that if the patch is found to cause a regression,
    its purpose can at least be understood and argumented. It happened
    at least once that we were requested not to explain the details
    because a paper was about to be issued, and that's not acceptable
    at all because it means that it becomes very complicated to have
    public discussions about possible forthcoming issues. I think that
    after the paragraph suggesting that the details of an issue or its
    exploit code might not always be published, it could be useful to
    mention something along the fact that the reporter shall not
    request the security team to withhold technical details about the
    issue as long as it doesn't represent an imminent danger.

  - it's quite frequent that reporters post from dummy addresses,
    looking like randomly generated ones (we even had one looking
    like a smiley). It doesn't help to communicate with them at all.
    I can understand how some working as consultants for a customer
    would want to avoid disclosing a particular relation between their
    finding and their customer, but at least they should indicate how
    they should be called. I.e. "call me Margarett" is not difficult
    and simplifies exchanges when the address is "69236836@example.com".
    And often we see at the end that they're willing to provide a real
    name to be credited for the finding, so most likely starting with
    this real name could be easier.

  - it's more a discussion for the list itself, but the wording continues
    to make one think that the reporter should expect the list members to
    develop a patch, while in practise the first thing that's asked is
    "since you've studied the problem well, do you happen to have a patch?".
    And it happened a few times that in response we got "oops sorry, I
    analysed it wrong, there's no issue there". I think the text should
    emphasize more on encouraging submitters to complete their work with
    a patch proposal (that's also helpful to confirm an analysis). And
    conversely I think that reports for non-immediately exploitable issues
    that are found by code analyzers (and almost always come without a
    patch) should not be sent to this list and should be discussed and
    addressed publicly instead. It's more efficient and allows more
    knowledgeable participants to have their say on the root cause of
    the problem and its possible solutions. That's of course not always
    the case, but common sense should prevail here.

Thanks,
Willy
  

On Mon, Mar 06, 2023 at 08:11:38AM +0100, Willy Tarreau wrote:
>   - I'm not seeing anywhere that the security list is *exclusively*
>     for kernel issues. That might explain why about once a week or so
>     we receive messages like "there's a bug in that userland tool" or
>     "we've found an XSS issue on your website". It's written that kernel
>     bugs should be reported to the security list but I think we should
>     strengthen that by adding "This list is exclusively used for Linux
>     kernel security reports, please do not report issues affecting any
>     other component there".

I think the wording would be "Please report security bugs against Linux
kernel to security@kernel.org list. Security bugs against userspace
applications should be reported to appropriate channels for affected
applications instead."

>   - it's quite frequent that reporters post from dummy addresses,
>     looking like randomly generated ones (we even had one looking
>     like a smiley). It doesn't help to communicate with them at all.
>     I can understand how some working as consultants for a customer
>     would want to avoid disclosing a particular relation between their
>     finding and their customer, but at least they should indicate how
>     they should be called. I.e. "call me Margarett" is not difficult
>     and simplifies exchanges when the address is "69236836@example.com".
>     And often we see at the end that they're willing to provide a real
>     name to be credited for the finding, so most likely starting with
>     this real name could be easier.
> 

Something like temporary addresses (à la maildrop or mail.gw)?

>   - it's more a discussion for the list itself, but the wording continues
>     to make one think that the reporter should expect the list members to
>     develop a patch, while in practise the first thing that's asked is
>     "since you've studied the problem well, do you happen to have a patch?".
>     And it happened a few times that in response we got "oops sorry, I
>     analysed it wrong, there's no issue there". I think the text should
>     emphasize more on encouraging submitters to complete their work with
>     a patch proposal (that's also helpful to confirm an analysis). And
>     conversely I think that reports for non-immediately exploitable issues
>     that are found by code analyzers (and almost always come without a
>     patch) should not be sent to this list and should be discussed and
>     addressed publicly instead. It's more efficient and allows more
>     knowledgeable participants to have their say on the root cause of
>     the problem and its possible solutions. That's of course not always
>     the case, but common sense should prevail here.

I think the wording would be "It is preferrable to have a proposed patch
for the bug you report. See
Documentation/process/submitting-patches.rst for details on how to
submit patches."

Thanks.
  

On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
> Hi,
> 
> This is v3 of clarifying our documentation for reporting security
> issues.
> 
> The current document is 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.
> 
> Lots of people have been confused about the 7/14 days of the kernel list
> vs. the 7/14 days of the distros list, the fact that these are two
> separate lists, etc. Many reporters contact distros first, or submit
> their report to both lists at the same time (which has the unfortunate
> effect of starting off the disclosure countdown for the distros list
> before s@k.o has had a chance to look at the report). I've shared the v2
> document with a couple of people who submitted reports and they said
> they found it a lot clearer. 
> 

The docs LGTM, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
  

On 3/6/23 07:02, Greg Kroah-Hartman wrote:
> On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
>> Lots of people have been confused about the 7/14 days of the kernel list
>> vs. the 7/14 days of the distros list, the fact that these are two
>> separate lists, etc. Many reporters contact distros first, or submit
>> their report to both lists at the same time (which has the unfortunate
>> effect of starting off the disclosure countdown for the distros list
>> before s@k.o has had a chance to look at the report). I've shared the v2
>> document with a couple of people who submitted reports and they said
>> they found it a lot clearer.
>>
>> Probably the easiest way to see the end result of this series is to view the
>> rendered HTML which I've put here:
>> https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html
> 
> Thanks for doing this, it looks much better, but I do have some
> objections with it.
> 
> First off, you didn't cc: the security@k.o group to see if they agree
> with this, any specific reason why?  :)

I did consider it, but thought it was better not to since this is not
a security issue -- but I see it's actually listed in MAINTAINERS (in an
entry I'm changing, no less... *facepalm*)

Added to Cc, beginning of the thread is here:
https://lore.kernel.org/all/20230305220010.20895-1-vegard.nossum@oracle.com/

> Secondly, and the bigger one, I think we should just drop all of the
> references to linux-distros and oss-security entirely, as those are
> groups that are outside of our control and interaction and have
> different rules that we might not agree with.

I find this a strange sentiment. All the major Linux distros have a
presence on the distros list and it remains a valuable resource for
coordination.

I think most of the friction of the past should have been resolved by
the distros list actually updating its rules last year (if not 100%
according to your wishes, at least a good step in that direction), any
remaining problems should hopefully be resolved by improving the
documentation so that issues are not sent to the distros list prematurely.

> They also just a tiny subset of Linux users and companies and as such
> do not really reflect the majority of where Linux is used anymore.
Is the elephant in the room that Android vendors are not rolling out
kernel updates in the 7-14 days given by distros to publicly disclose
the reported issues? If so, then I think this is the real issue here,
and it should be stated outright.

> But overall I like the slimmer size, so perhaps the end result just
> being the first two major sections would be best.  Let me take those
> changes first and we can see how the result looks for now to see if that
> will resolve some of the major issues the security@k.o group have right
> now with reports (i.e. CVE requests, other group's disclosure rules and
> dates).

I personally think it would be a mistake not to include the info about
the other lists, both because I think they have real value (and I do
think they represent Linux kernel users, if not kernel developers) but
also because, as Willy said, people will find the wrong information
elsewhere and submit issues anyway, people are still going to want to
request CVEs (regardless of what you or I think about them), etc.

Anyway, I don't represent s@k.o so I don't decide, I really just want
security for end users and as responsible disclosure as we can hope for.
The patches are out there so feel free to use whatever you want from them.

Thanks for looking it over.


Vegard