by Willy Tarreau

[permalink] [raw]

Subject: Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

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 "[email protected]".
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

2023-03-06 08:47:31

by Bagas Sanjaya

[permalink] [raw]

Subject: Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

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 [email protected] 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 "[email protected]".
> 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.

--
An old man doll... just what I always wanted! - Clara

Attachments:

(No filename) (2.93 kB)
signature.asc (228.00 B)
Download all attachments

On Sun, Mar 05, 2023 at 11:00:05PM +0100, Vegard Nossum wrote:
> This mostly just clarifies things and moves a few things around in
> preparation for the subsequent changes.
>
> Most notably, pull the "[email protected]" address up into the first
> paragraph as this the most vital piece of information in the whole
> document.
>
> Also fix a few markup issues.

When you have "also" in a patch changelog, that usually means this
should be a separate patch. Can you just fix up the markup issues first
please?

Also, a few minor comments below:

>
> Signed-off-by: Vegard Nossum <[email protected]>
> ---
> Documentation/process/security-bugs.rst | 37 ++++++++++++++-----------
> 1 file changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 82e29837d589..f1326d4e9718 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -1,36 +1,41 @@
> .. _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.
> +Linux kernel security team at [email protected], 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.
>
> -Contact
> --------
> +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.
>
> -The Linux kernel security team can be contacted by email at
> -<[email protected]>. 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.
> +Note that the main interest of the kernel security list is in getting
> +bugs fixed and getting patches reviewed, tested, and merged; CVE

It's not "main interest", it is the "only task" of it. That's all the
list does, nothing else.

> +assignment, disclosure to distributions, and public disclosure happen on
> +different lists with different people.

How about this rephrasing:

The only tasks of the kernel security list are to triage
reported potential security bugs, generate and test a fix, and
get the fix merged into Linus's and the stable kernel trees.
The security list does not deal with CVE assignment or any sort
of disclosure at all.

thanks,

greg k-h