[RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[Willy Tarreau]

The linux-distros list relaxed their rules to try to adapt better to
how the Linux kernel works. Let's update the Coordination part to
explain why and when to contact them or not to and how to avoid trouble
in the future.

Link: https://www.openwall.com/lists/oss-security/2023/09/08/4
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Solar Designer <solar@openwall.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 33 ++++++++++++++++++-------
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 5a6993795bd2..8bbad669af1f 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -66,15 +66,30 @@ lifted, in perpetuity.
 Coordination with other groups
 ------------------------------
 
-The kernel security team strongly recommends that reporters of potential
-security issues NEVER contact the "linux-distros" mailing list until
-AFTER discussing it with the kernel security team.  Do not Cc: both
-lists at once.  You may contact the linux-distros mailing list after a
-fix has been agreed on and you fully understand the requirements that
-doing so will impose on you and the kernel community.
-
-The different lists have different goals and the linux-distros rules do
-not contribute to actually fixing any potential security problems.
+While the kernel security team solely focuses on getting bugs fixed,
+other groups focus on fixing issues in distros and coordinating
+disclosure between operating system vendors.  Coordination is usually
+handled by the "linux-distros" mailing list and disclosure by the
+public "oss-security" mailing list, both of which are closely related
+and presented in the linux-distros wiki:
+<https://oss-security.openwall.org/wiki/mailing-lists/distros>
+
+Please note that the respective policies and rules are different since
+the 3 lists pursue different goals.  Coordinating between the kernel
+security team and other teams is difficult since occasional embargoes
+start from the availability of a fix for the kernel security team, while
+for other lists they generally start from the initial post to the list,
+regardless of the availability of a fix.
+
+As such, the kernel security team strongly recommends that reporters of
+potential security issues DO NOT contact the "linux-distros" mailing
+list BEFORE a fix is accepted by the affected code's maintainers and you
+have read the linux-distros wiki page above and you fully understand the
+requirements that doing so will impose on you and the kernel community.
+This also means that in general it doesn't make sense to Cc: both lists
+at once, except for coordination if a fix remains under embargo. And in
+general, please do not Cc: the kernel security list about fixes that
+have already been merged.
 
 CVE assignment
 --------------
-- 
2.17.5

Re: [RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[Vegard Nossum]

On 07/10/2023 16:04, Willy Tarreau wrote:
> +As such, the kernel security team strongly recommends that reporters of
> +potential security issues DO NOT contact the "linux-distros" mailing
> +list BEFORE a fix is accepted by the affected code's maintainers and you

is s/BEFORE/UNTIL/ clearer?

> +have read the linux-distros wiki page above and you fully understand the
> +requirements that doing so will impose on you and the kernel community.
> +This also means that in general it doesn't make sense to Cc: both lists
> +at once, except for coordination if a fix remains under embargo. And in
> +general, please do not Cc: the kernel security list about fixes that
> +have already been merged.

I was thinking about this Cc: thing and would it make sense to:

1) have LKML and other public vger lists reject messages that include
s@k.o or (linux-)distros@ on Cc? The idea being that this is probably a
mistake -- I believe it has happened a few times recently by mistake.

2) have (linux-)distros@ reject NEW threads (i.e. no In-Reply-To:) that
also include s@k.o on Cc? We could include a nice message explaining why
and to please resend when a patch has been developed and/or a disclosure
is planned in the next 7 days. I guess the problem with this would be if
somebody on s@k.o does a reply-all which would add distros right back in
the loop -OR- a patch has already been developed and included.


Vegard

Re: [RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[Willy Tarreau]

Hi Vegard,

On Sat, Oct 07, 2023 at 06:30:11PM +0200, Vegard Nossum wrote:
> 
> On 07/10/2023 16:04, Willy Tarreau wrote:
> > +As such, the kernel security team strongly recommends that reporters of
> > +potential security issues DO NOT contact the "linux-distros" mailing
> > +list BEFORE a fix is accepted by the affected code's maintainers and you
> 
> is s/BEFORE/UNTIL/ clearer?

Probably, yes.

> > +have read the linux-distros wiki page above and you fully understand the
> > +requirements that doing so will impose on you and the kernel community.
> > +This also means that in general it doesn't make sense to Cc: both lists
> > +at once, except for coordination if a fix remains under embargo. And in
> > +general, please do not Cc: the kernel security list about fixes that
> > +have already been merged.
> 
> I was thinking about this Cc: thing and would it make sense to:
> 
> 1) have LKML and other public vger lists reject messages that include
> s@k.o or (linux-)distros@ on Cc? The idea being that this is probably a
> mistake -- I believe it has happened a few times recently by mistake.
> 
> 2) have (linux-)distros@ reject NEW threads (i.e. no In-Reply-To:) that
> also include s@k.o on Cc? We could include a nice message explaining why
> and to please resend when a patch has been developed and/or a disclosure
> is planned in the next 7 days.

I don't know, maybe it would add extra config burden, but on the other
hand it could avoid the mistake from newcomers who have not read the
docs first (which happened a few times already), but if l-d becomes a
bit more flexible and tolerant to reporters' mistakes, as now documented,
it should also be less of a problem.

> I guess the problem with this would be if
> somebody on s@k.o does a reply-all which would add distros right back in
> the loop -OR- a patch has already been developed and included.

Then this would be deliberate, there would an in-reply-to so that would
not be a problem. I really doubt anyone from s@k.o would Cc linux-distros
anyway since it would imply disclosing some details from a reporter, and
we do not do that, it's up to the reporter to do it if they want.

Thanks,
Willy

Re: [RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[Solar Designer]

Hi all,

Thank you (especially Willy) for your effort on this.

Out of the 3 paragraphs, the first one looks good to me as-is, but for
the last two I propose the slightly edited versions below.

On Sat, Oct 07, 2023 at 04:04:54PM +0200, Willy Tarreau wrote:
> +Please note that the respective policies and rules are different since
> +the 3 lists pursue different goals.  Coordinating between the kernel
> +security team and other teams is difficult since occasional embargoes
> +start from the availability of a fix for the kernel security team, while
> +for other lists they generally start from the initial post to the list,
> +regardless of the availability of a fix.

---
Please note that the respective policies and rules are different since
the 3 lists pursue different goals.  Coordinating between the kernel
security team and other teams is difficult since for the kernel security
team occasional embargoes (as subject to a maximum allowed number of
days) start from the availability of a fix, while for "linux-distros"
they start from the initial post to the list regardless of the
availability of a fix.
---

I added the part in braces to explain why the difference in when
embargoes start matters.  I also moved part of that sentence for
consistency.  Finally, I replaced "other lists" with specific reference
to "linux-distros" because this paragraph talks only about 3 specific
lists and on "oss-security" there are no embargoes.

On Sat, Oct 07, 2023 at 06:39:36PM +0200, Willy Tarreau wrote:
> On Sat, Oct 07, 2023 at 06:30:11PM +0200, Vegard Nossum wrote:
> > On 07/10/2023 16:04, Willy Tarreau wrote:
> > > +As such, the kernel security team strongly recommends that reporters of
> > > +potential security issues DO NOT contact the "linux-distros" mailing
> > > +list BEFORE a fix is accepted by the affected code's maintainers and you
> > 
> > is s/BEFORE/UNTIL/ clearer?
> 
> Probably, yes.

I agree.  Also, the sentence jumps from "reporters" to "you" implying
that "you" is a reporter, but maybe it's better to make that explicit.

> > > +have read the linux-distros wiki page above and you fully understand the
> > > +requirements that doing so will impose on you and the kernel community.
> > > +This also means that in general it doesn't make sense to Cc: both lists
> > > +at once, except for coordination if a fix remains under embargo. And in
> > > +general, please do not Cc: the kernel security list about fixes that
> > > +have already been merged.

This implies that in general a fix does not remain under embargo.
However, contacting "linux-distros" only makes sense when a fix does
remain under embargo (either not yet pushed to a public list/repo, or
under the Linux kernel exception for a public not-too-revealing fix) -
otherwise, the issue should be brought to "oss-security" right away.

Edited:

---
As such, the kernel security team strongly recommends that as a reporter
of a potential security issue you DO NOT contact the "linux-distros"
mailing list UNTIL a fix is accepted by the affected code's maintainers
and you have read the distros wiki page above and you fully understand
the requirements that contacting "linux-distros" will impose on you and
the kernel community.  This also means that in general it doesn't make
sense to Cc: both lists at once, except maybe for coordination if and
while an accepted fix has not yet been merged.  In other words, until a
fix is accepted do not Cc: "linux-distros", and after it's merged do not
Cc: the kernel security team.
---

This allows possible Cc'ing of both lists in the time window between
"fix is accepted by the affected code's maintainers" and "merged".
Makes sense?  I worry this distinction between accepted and merged may
be overly complicated for some, but I don't have better wording.

> > I was thinking about this Cc: thing and would it make sense to:
> > 
> > 1) have LKML and other public vger lists reject messages that include
> > s@k.o or (linux-)distros@ on Cc? The idea being that this is probably a
> > mistake -- I believe it has happened a few times recently by mistake.
> > 
> > 2) have (linux-)distros@ reject NEW threads (i.e. no In-Reply-To:) that
> > also include s@k.o on Cc? We could include a nice message explaining why
> > and to please resend when a patch has been developed and/or a disclosure
> > is planned in the next 7 days.
> 
> I don't know, maybe it would add extra config burden, but on the other
> hand it could avoid the mistake from newcomers who have not read the
> docs first (which happened a few times already), but if l-d becomes a
> bit more flexible and tolerant to reporters' mistakes, as now documented,
> it should also be less of a problem.
> 
> > I guess the problem with this would be if
> > somebody on s@k.o does a reply-all which would add distros right back in
> > the loop -OR- a patch has already been developed and included.
> 
> Then this would be deliberate, there would an in-reply-to so that would
> not be a problem. I really doubt anyone from s@k.o would Cc linux-distros
> anyway since it would imply disclosing some details from a reporter, and
> we do not do that, it's up to the reporter to do it if they want.

I think we don't want to complicate the setup, which we'd then have to
explain somewhere.  With my concern/edit above, also the logic isn't
that simple.

Alexander

Re: [RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[Willy Tarreau]

On Thu, Oct 12, 2023 at 11:51:22PM +0200, Solar Designer wrote:
> Hi all,
> 
> Thank you (especially Willy) for your effort on this.
> 
> Out of the 3 paragraphs, the first one looks good to me as-is, but for
> the last two I propose the slightly edited versions below.
> 
> On Sat, Oct 07, 2023 at 04:04:54PM +0200, Willy Tarreau wrote:
> > +Please note that the respective policies and rules are different since
> > +the 3 lists pursue different goals.  Coordinating between the kernel
> > +security team and other teams is difficult since occasional embargoes
> > +start from the availability of a fix for the kernel security team, while
> > +for other lists they generally start from the initial post to the list,
> > +regardless of the availability of a fix.
> 
> ---
> Please note that the respective policies and rules are different since
> the 3 lists pursue different goals.  Coordinating between the kernel
> security team and other teams is difficult since for the kernel security
> team occasional embargoes (as subject to a maximum allowed number of
> days) start from the availability of a fix, while for "linux-distros"
> they start from the initial post to the list regardless of the
> availability of a fix.
> ---
> 
> I added the part in braces to explain why the difference in when
> embargoes start matters.  I also moved part of that sentence for
> consistency.  Finally, I replaced "other lists" with specific reference
> to "linux-distros" because this paragraph talks only about 3 specific
> lists and on "oss-security" there are no embargoes.

It's fine by me as it doesn't change the spirit but improves the wording.

> On Sat, Oct 07, 2023 at 06:39:36PM +0200, Willy Tarreau wrote:
> > On Sat, Oct 07, 2023 at 06:30:11PM +0200, Vegard Nossum wrote:
> > > On 07/10/2023 16:04, Willy Tarreau wrote:
> > > > +As such, the kernel security team strongly recommends that reporters of
> > > > +potential security issues DO NOT contact the "linux-distros" mailing
> > > > +list BEFORE a fix is accepted by the affected code's maintainers and you
> > > 
> > > is s/BEFORE/UNTIL/ clearer?
> > 
> > Probably, yes.
> 
> I agree.  Also, the sentence jumps from "reporters" to "you" implying
> that "you" is a reporter, but maybe it's better to make that explicit.

Ah, I hate doing this, I generally avoid "you" and "we" in docs but
given these ones are instructions it's easy to fall in the trap. I'll
try to improve it.

> > > > +have read the linux-distros wiki page above and you fully understand the
> > > > +requirements that doing so will impose on you and the kernel community.
> > > > +This also means that in general it doesn't make sense to Cc: both lists
> > > > +at once, except for coordination if a fix remains under embargo. And in
> > > > +general, please do not Cc: the kernel security list about fixes that
> > > > +have already been merged.
> 
> This implies that in general a fix does not remain under embargo.

This is most often the case.

> However, contacting "linux-distros" only makes sense when a fix does
> remain under embargo (either not yet pushed to a public list/repo, or
> under the Linux kernel exception for a public not-too-revealing fix) -
> otherwise, the issue should be brought to "oss-security" right away.
> 
> Edited:
> 
> ---
> As such, the kernel security team strongly recommends that as a reporter
> of a potential security issue you DO NOT contact the "linux-distros"
> mailing list UNTIL a fix is accepted by the affected code's maintainers
> and you have read the distros wiki page above and you fully understand
> the requirements that contacting "linux-distros" will impose on you and
> the kernel community.  This also means that in general it doesn't make
> sense to Cc: both lists at once, except maybe for coordination if and
> while an accepted fix has not yet been merged.  In other words, until a
> fix is accepted do not Cc: "linux-distros", and after it's merged do not
> Cc: the kernel security team.
> ---
> 
> This allows possible Cc'ing of both lists in the time window between
> "fix is accepted by the affected code's maintainers" and "merged".
> Makes sense?  I worry this distinction between accepted and merged may
> be overly complicated for some, but I don't have better wording.

I think it's fine as is. I care a lot about giving clear instructions,
especially for first-time reporters, for whom it's always particularly
stressful to report a bug. With this update I think there's enough
guidance and it should help, so OK for me.

> > > I guess the problem with this would be if
> > > somebody on s@k.o does a reply-all which would add distros right back in
> > > the loop -OR- a patch has already been developed and included.
> > 
> > Then this would be deliberate, there would an in-reply-to so that would
> > not be a problem. I really doubt anyone from s@k.o would Cc linux-distros
> > anyway since it would imply disclosing some details from a reporter, and
> > we do not do that, it's up to the reporter to do it if they want.
> 
> I think we don't want to complicate the setup, which we'd then have to
> explain somewhere.  With my concern/edit above, also the logic isn't
> that simple.

Agreed, let's leave it to the reporter to do what they want with the
instructions above and be done with it.

Jiri, does your Acked-by still stand with these adjustment ? If so, I'll
resend the updated version today or this week-end, as time permits.

Thanks!
Willy

Re: [RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[Jiri Kosina]

On Fri, 13 Oct 2023, Willy Tarreau wrote:

> Jiri, does your Acked-by still stand with these adjustment ? If so, I'll
> resend the updated version today or this week-end, as time permits.

As it doesn't change the spirit but pretty much just improves the wording, 
my Ack still holds.

Thanks again,

-- 
Jiri Kosina
SUSE Labs

Re: [RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[Willy Tarreau]

On Fri, Oct 13, 2023 at 08:54:03AM +0200, Jiri Kosina wrote:
> On Fri, 13 Oct 2023, Willy Tarreau wrote:
> 
> > Jiri, does your Acked-by still stand with these adjustment ? If so, I'll
> > resend the updated version today or this week-end, as time permits.
> 
> As it doesn't change the spirit but pretty much just improves the wording, 
> my Ack still holds.

Perfect, thank you!
Willy

Re: [RFC PATCH] Documentation: security-bugs.rst: linux-distros relaxed their rules

[Jiri Kosina]

On Sat, 7 Oct 2023, Willy Tarreau wrote:

> The linux-distros list relaxed their rules to try to adapt better to
> how the Linux kernel works. Let's update the Coordination part to
> explain why and when to contact them or not to and how to avoid trouble
> in the future.
> 
> Link: https://www.openwall.com/lists/oss-security/2023/09/08/4
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Solar Designer <solar@openwall.com>
> Cc: Vegard Nossum <vegard.nossum@oracle.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>

With my distro hat on:

	Acked-by: Jiri Kosina <jkosina@suse.cz>

Thanks a lot,

-- 
Jiri Kosina
SUSE Labs