[PATCH] [v2] docs: clarify security-bugs disclosure policy

[PATCH] [v2] docs: clarify security-bugs disclosure policy

[Dave Hansen]

From: Dave Hansen <dave.hansen@linux.intel.com>

I think we need to soften the language a bit.  It might scare folks
off, especially the:

	 We prefer to fully disclose the bug as soon as possible.

which is not really the case.  Linus says:

	It's not full disclosure, it's not coordinated disclosure,
	and it's not "no disclosure".  It's more like just "timely
	open fixes".

I changed a bit of the wording in here, but mostly to remove the word
"disclosure" since it seems to mean very specific things to people
that we do not mean here.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@google.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Mark Rutland <mark.rutland@arm.com>
---

 b/Documentation/admin-guide/security-bugs.rst |   24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff -puN Documentation/admin-guide/security-bugs.rst~embargo2 Documentation/admin-guide/security-bugs.rst
--- a/Documentation/admin-guide/security-bugs.rst~embargo2	2018-03-07 13:23:49.390228208 -0800
+++ b/Documentation/admin-guide/security-bugs.rst	2018-03-07 13:42:37.618225395 -0800
@@ -29,18 +29,20 @@ made public.
 Disclosure
 ----------
 
-The goal of the Linux kernel security team is to work with the
-bug submitter to bug resolution as well as disclosure.  We prefer
-to fully disclose the bug as soon as possible.  It is reasonable to
-delay disclosure when the bug or the fix is not yet fully understood,
-the solution is not well-tested or for vendor coordination.  However, we
-expect these delays to be short, measurable in days, not weeks or months.
-A disclosure date is negotiated by the security team working with the
-bug submitter as well as vendors.  However, the kernel security team
-holds the final say when setting a disclosure date.  The timeframe for
-disclosure is from immediate (esp. if it's already publicly known)
+The goal of the Linux kernel security team is to work with the bug
+submitter to understand and fix the bug.  We prefer to publish the fix as
+soon as possible, but try to avoid public discussion of the bug itself
+and leave that to others.
+
+Publishing the fix may be delayed when the bug or the fix is not yet
+fully understood, the solution is not well-tested or for vendor
+coordination.  However, we expect these delays to be short, measurable in
+days, not weeks or months.  A release date is negotiated by the security
+team working with the bug submitter as well as vendors.  However, the
+kernel security team holds the final say when setting a timeframe.  The
+timeframe varies from immediate (esp. if it's already publicly known bug)
 to a few weeks.  As a basic default policy, we expect report date to
-disclosure date to be on the order of 7 days.
+release date to be on the order of 7 days.
 
 Coordination
 ------------
_

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Linus Torvalds]

That patch looks fine to me, avoiding any terms that might be
misunderstood, and being pretty straightforward.

I'm guessing this will go through Jon?

               Linus

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Kees Cook]

On Wed, Mar 7, 2018 at 1:46 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> I think we need to soften the language a bit.  It might scare folks
> off, especially the:
>
>          We prefer to fully disclose the bug as soon as possible.
>
> which is not really the case.  Linus says:
>
>         It's not full disclosure, it's not coordinated disclosure,
>         and it's not "no disclosure".  It's more like just "timely
>         open fixes".
>
> I changed a bit of the wording in here, but mostly to remove the word
> "disclosure" since it seems to mean very specific things to people
> that we do not mean here.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Kees Cook <keescook@google.com>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-doc@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Mark Rutland <mark.rutland@arm.com>
> ---
>
>  b/Documentation/admin-guide/security-bugs.rst |   24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff -puN Documentation/admin-guide/security-bugs.rst~embargo2 Documentation/admin-guide/security-bugs.rst
> --- a/Documentation/admin-guide/security-bugs.rst~embargo2      2018-03-07 13:23:49.390228208 -0800
> +++ b/Documentation/admin-guide/security-bugs.rst       2018-03-07 13:42:37.618225395 -0800
> @@ -29,18 +29,20 @@ made public.
>  Disclosure
>  ----------
>
> -The goal of the Linux kernel security team is to work with the
> -bug submitter to bug resolution as well as disclosure.  We prefer
> -to fully disclose the bug as soon as possible.  It is reasonable to
> -delay disclosure when the bug or the fix is not yet fully understood,
> -the solution is not well-tested or for vendor coordination.  However, we
> -expect these delays to be short, measurable in days, not weeks or months.
> -A disclosure date is negotiated by the security team working with the
> -bug submitter as well as vendors.  However, the kernel security team
> -holds the final say when setting a disclosure date.  The timeframe for
> -disclosure is from immediate (esp. if it's already publicly known)
> +The goal of the Linux kernel security team is to work with the bug
> +submitter to understand and fix the bug.  We prefer to publish the fix as
> +soon as possible, but try to avoid public discussion of the bug itself
> +and leave that to others.
> +
> +Publishing the fix may be delayed when the bug or the fix is not yet
> +fully understood, the solution is not well-tested or for vendor
> +coordination.  However, we expect these delays to be short, measurable in
> +days, not weeks or months.  A release date is negotiated by the security
> +team working with the bug submitter as well as vendors.  However, the
> +kernel security team holds the final say when setting a timeframe.  The
> +timeframe varies from immediate (esp. if it's already publicly known bug)

Nit: I think "a" is missing. I was expecting: "... already a publicly known ...

>  to a few weeks.  As a basic default policy, we expect report date to
> -disclosure date to be on the order of 7 days.
> +release date to be on the order of 7 days.

Otherwise, yeah, looks good.

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Greg KH]

On Wed, Mar 07, 2018 at 01:46:24PM -0800, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> I think we need to soften the language a bit.  It might scare folks
> off, especially the:
> 
> 	 We prefer to fully disclose the bug as soon as possible.
> 
> which is not really the case.  Linus says:
> 
> 	It's not full disclosure, it's not coordinated disclosure,
> 	and it's not "no disclosure".  It's more like just "timely
> 	open fixes".
> 
> I changed a bit of the wording in here, but mostly to remove the word
> "disclosure" since it seems to mean very specific things to people
> that we do not mean here.
> 
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Kees Cook <keescook@google.com>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-doc@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Mark Rutland <mark.rutland@arm.com>
> ---
> 

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Jonathan Corbet]

On Wed, 7 Mar 2018 13:53:06 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> I'm guessing this will go through Jon?

Sounds like a fine guess to me; will apply shortly.

Thanks,

jon

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Alan Cox]

On Wed, 07 Mar 2018 13:46:24 -0800
Dave Hansen <dave.hansen@linux.intel.com> wrote:

> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> I think we need to soften the language a bit.  It might scare folks
> off, especially the:
> 
> 	 We prefer to fully disclose the bug as soon as possible.
> 
> which is not really the case.  Linus says:
> 
> 	It's not full disclosure, it's not coordinated disclosure,
> 	and it's not "no disclosure".  It's more like just "timely
> 	open fixes".
> 
> I changed a bit of the wording in here, but mostly to remove the word
> "disclosure" since it seems to mean very specific things to people
> that we do not mean here.
> 

If you want to be taken seriously then I think minimum you also need to
- Give a GPG key for messages to the list
- State what security is in place (encryption etc) to protect the list
  itself

There are probably a lot more things people would ask but given the
policy now clear that it's basically just an 'early tip off'/'make sure
Linus doesn't miss this' list for very short notification periods doesn't
matter so much.

Alan

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Linus Torvalds]

On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>
> If you want to be taken seriously then I think minimum you also need to
> - Give a GPG key for messages to the list

Oh, I don't want to be taken seriously by people who use gpg encrypted email.

It's garbage and should be shunned as such.

I keep quoting this:

   https://motherboard.vice.com/en_us/article/vvbw9a/even-the-inventor-of-pgp-doesnt-use-pgp

and anybody who thinks pgp encrypted email is fine is a clown.

> - State what security is in place (encryption etc) to protect the list
>   itself

That could be stated, but it's worth noting the other rules.

If you have some long corrupt vendor disclosure period and are worried
about any good guys finding out (the bad guys probably already have
it), we're not the list for you anyway.

Keep your "we'll keep security problems under wraps so that they can
be exploited for a long time" emails to yourself, or send them to
/dev/null.

                   Linus

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Hi!

On Fri 2018-03-09 13:15:31, Linus Torvalds wrote:
> On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
> >
> > If you want to be taken seriously then I think minimum you also need to
> > - Give a GPG key for messages to the list
> 
> Oh, I don't want to be taken seriously by people who use gpg
> encrypted email.

Heh. I see that gpg has some usability problems, but we do encrypt our
http connections, and email is at least as sensitive.

> > - State what security is in place (encryption etc) to protect the list
> >   itself
> 
> That could be stated, but it's worth noting the other rules.
> 
> If you have some long corrupt vendor disclosure period and are worried
> about any good guys finding out (the bad guys probably already have
> it), we're not the list for you anyway.
> 
> Keep your "we'll keep security problems under wraps so that they can
> be exploited for a long time" emails to yourself, or send them to
> /dev/null.

Umm, they will not sent it to /dev/null, as that is not encrypted :-).

I guess I can act as this kind of /dev/null. It might be useful to
note the issues, and for the serious ones notify you few days before
the "long" embargo is going to expire...

Best regards,

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Linus Torvalds]

On Sun, Apr 22, 2018 at 3:00 AM, Pavel Machek <pavel@ucw.cz> wrote:
>
> On Fri 2018-03-09 13:15:31, Linus Torvalds wrote:
>>
>> Oh, I don't want to be taken seriously by people who use gpg
>> encrypted email.
>
> Heh. I see that gpg has some usability problems, but we do encrypt our
> http connections, and email is at least as sensitive.

It's not about sensitivity.

It's about the technology actually *working*.

PGP does not work for email. Never has, never will. It's unusable
crap. Nobody sane uses it, because the cost is just too damn high.

Make it as easy to use as https, and things will change. As it is,
don't even bother.

Thomas helped me get S/MIME working, and even for that I had to fix an
alpine bug that caused alpine to SIGSEGV. And that's _convenient_
compared to pgp email. Whee.

             Linus