[PATCH 1/2] docs: process: Add cross-link to security-bugs

[PATCH 1/2] docs: process: Add cross-link to security-bugs

[Krzysztof Kozlowski]

The submitting patches mentions criteria for a fix to be called
"security fix".  Add a link to document explaining the entire process
of handling security bugs.

Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 Documentation/process/submitting-patches.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 5219bf3cddfc..d5b3c5a74d5d 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -299,7 +299,8 @@ sending him e-mail.
 If you have a patch that fixes an exploitable security bug, send that patch
 to security@kernel.org.  For severe bugs, a short embargo may be considered
 to allow distributors to get the patch out to users; in such cases,
-obviously, the patch should not be sent to any public lists.
+obviously, the patch should not be sent to any public lists. See also
+:ref:`Documentation/admin-guide/security-bugs.rst <security-bugs>`.
 
 Patches that fix a severe bug in a released kernel should be directed
 toward the stable maintainers by putting a line like this::
-- 
2.17.1

[PATCH 2/2] docs: admin-guide: Not every security bug should be kept hidden

[Krzysztof Kozlowski]

Document describes the process of handling security bugs but does not
mention any criteria what is a "security bug".  Unlike
submitting-patches.rst which explicitly says - publicly exploitable bug.

Many NULL pointer exceptions, off-by-one errors or overflows tend
to look like security bug, so there might be a temptation to discuss
them behind security list which is not an open list.

Such discussion limits the amount of testing and independent reviewing.
Sacrificing open discussion is understandable in the case of real
security issues but not for regular bugs.  These should be discussed
publicly.

At the end, "security problems are just bugs".

Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Follow up to:
https://lore.kernel.org/linux-usb/1425ab4f-ef7e-97d9-238f-0328ab51eb35@samsung.com/
---
 Documentation/admin-guide/security-bugs.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
index c32eb786201c..7ebddbd4bbcd 100644
--- a/Documentation/admin-guide/security-bugs.rst
+++ b/Documentation/admin-guide/security-bugs.rst
@@ -78,6 +78,12 @@ include linux-distros from the start. In this case, remember to prefix
 the email Subject line with "[vs]" as described in the linux-distros wiki:
 <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
 
+Fixes for non-exploitable bugs which do not pose a real security risk, should
+be disclosed in a regular way of submitting patches to Linux kernel (see
+:ref:`Documentation/process/submitting-patches.rst <submitting-patches>`).
+Just because patch fixes some off-by-one or NULL pointer exception, does not
+classify it as a security bug which should be discussed in closed channels.
+
 CVE assignment
 --------------
 
-- 
2.17.1

Re: [PATCH 1/2] docs: process: Add cross-link to security-bugs

[Greg Kroah-Hartman]

On Thu, Aug 27, 2020 at 12:53:18PM +0200, Krzysztof Kozlowski wrote:
> The submitting patches mentions criteria for a fix to be called
> "security fix".  Add a link to document explaining the entire process
> of handling security bugs.
> 
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
>  Documentation/process/submitting-patches.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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

Re: [PATCH 2/2] docs: admin-guide: Not every security bug should be kept hidden

[Greg Kroah-Hartman]

On Thu, Aug 27, 2020 at 12:53:19PM +0200, Krzysztof Kozlowski wrote:
> Document describes the process of handling security bugs but does not
> mention any criteria what is a "security bug".  Unlike
> submitting-patches.rst which explicitly says - publicly exploitable bug.
> 
> Many NULL pointer exceptions, off-by-one errors or overflows tend
> to look like security bug, so there might be a temptation to discuss
> them behind security list which is not an open list.
> 
> Such discussion limits the amount of testing and independent reviewing.
> Sacrificing open discussion is understandable in the case of real
> security issues but not for regular bugs.  These should be discussed
> publicly.
> 
> At the end, "security problems are just bugs".
> 
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> 
> ---
> 
> Follow up to:
> https://lore.kernel.org/linux-usb/1425ab4f-ef7e-97d9-238f-0328ab51eb35@samsung.com/
> ---
>  Documentation/admin-guide/security-bugs.rst | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> index c32eb786201c..7ebddbd4bbcd 100644
> --- a/Documentation/admin-guide/security-bugs.rst
> +++ b/Documentation/admin-guide/security-bugs.rst
> @@ -78,6 +78,12 @@ include linux-distros from the start. In this case, remember to prefix
>  the email Subject line with "[vs]" as described in the linux-distros wiki:
>  <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
>  
> +Fixes for non-exploitable bugs which do not pose a real security risk, should
> +be disclosed in a regular way of submitting patches to Linux kernel (see
> +:ref:`Documentation/process/submitting-patches.rst <submitting-patches>`).
> +Just because patch fixes some off-by-one or NULL pointer exception, does not
> +classify it as a security bug which should be discussed in closed channels.

I said this on another thread, but almost always, when we get reports
like this on security@k.o, we do push them back to public lists.

For the most part, this paragraph is not going to help much (mostly for
the reason that no one seems to read it, but that's a different
topic...)  We get crazy reports all the time, and that's fine, because
sometimes, there is a real issue in some of them.  And for that, we do
want to be careful.  We also have many docuemented "off-by-one" bugs
that were real security issues (there's a blog post somewhere about how
a developer turned such a bug into a root hole, can't find it right
now...)

So while I understand the temptation here, based on the current
security@k.o traffic, I doubt this will really change much :(

Also, you should have cc:ed that group when you are changing things that
will affect them.

thanks,

greg k-h

Re: [PATCH 2/2] docs: admin-guide: Not every security bug should be kept hidden

[Krzysztof Kozlowski]

On Thu, Aug 27, 2020 at 02:11:23PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 27, 2020 at 12:53:19PM +0200, Krzysztof Kozlowski wrote:
> > Document describes the process of handling security bugs but does not
> > mention any criteria what is a "security bug".  Unlike
> > submitting-patches.rst which explicitly says - publicly exploitable bug.
> > 
> > Many NULL pointer exceptions, off-by-one errors or overflows tend
> > to look like security bug, so there might be a temptation to discuss
> > them behind security list which is not an open list.
> > 
> > Such discussion limits the amount of testing and independent reviewing.
> > Sacrificing open discussion is understandable in the case of real
> > security issues but not for regular bugs.  These should be discussed
> > publicly.
> > 
> > At the end, "security problems are just bugs".
> > 
> > Cc: Greg KH <gregkh@linuxfoundation.org>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > 
> > ---
> > 
> > Follow up to:
> > https://lore.kernel.org/linux-usb/1425ab4f-ef7e-97d9-238f-0328ab51eb35@samsung.com/
> > ---
> >  Documentation/admin-guide/security-bugs.rst | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> > index c32eb786201c..7ebddbd4bbcd 100644
> > --- a/Documentation/admin-guide/security-bugs.rst
> > +++ b/Documentation/admin-guide/security-bugs.rst
> > @@ -78,6 +78,12 @@ include linux-distros from the start. In this case, remember to prefix
> >  the email Subject line with "[vs]" as described in the linux-distros wiki:
> >  <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
> >  
> > +Fixes for non-exploitable bugs which do not pose a real security risk, should
> > +be disclosed in a regular way of submitting patches to Linux kernel (see
> > +:ref:`Documentation/process/submitting-patches.rst <submitting-patches>`).
> > +Just because patch fixes some off-by-one or NULL pointer exception, does not
> > +classify it as a security bug which should be discussed in closed channels.
> 
> I said this on another thread, but almost always, when we get reports
> like this on security@k.o, we do push them back to public lists.

Then let's hope that next time someone will read this documentation
before submitting such report to @security.

> 
> For the most part, this paragraph is not going to help much (mostly for
> the reason that no one seems to read it, but that's a different
> topic...)

All of our documentation is our wish that someone will read it and
follow it. Just because people might not follow it, is not necessarily a
reason to skip documentation.

> We get crazy reports all the time, and that's fine, because
> sometimes, there is a real issue in some of them.  And for that, we do
> want to be careful.  We also have many docuemented "off-by-one" bugs
> that were real security issues (there's a blog post somewhere about how
> a developer turned such a bug into a root hole, can't find it right
> now...)

I understand. That's why I also mentioned the criteria of exploitable
and posing a security risk. First case (even stricter - publicly
exploitable) is already mentioned in submitting-patches so I am not
changing the current status.

I merely want to document it based on recent discussion.

> So while I understand the temptation here, based on the current
> security@k.o traffic, I doubt this will really change much :(
> 
> Also, you should have cc:ed that group when you are changing things that
> will affect them.

Indeed, I will update the maintainers as well.

Best regards,
Krzysztof

Re: [PATCH 1/2] docs: process: Add cross-link to security-bugs

[Felipe Balbi]

Hi,

On Thu, Aug 27, 2020 at 1:54 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The submitting patches mentions criteria for a fix to be called
> "security fix".  Add a link to document explaining the entire process
> of handling security bugs.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
>  Documentation/process/submitting-patches.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 5219bf3cddfc..d5b3c5a74d5d 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -299,7 +299,8 @@ sending him e-mail.
>  If you have a patch that fixes an exploitable security bug, send that patch
>  to security@kernel.org.  For severe bugs, a short embargo may be considered
>  to allow distributors to get the patch out to users; in such cases,
> -obviously, the patch should not be sent to any public lists.
> +obviously, the patch should not be sent to any public lists. See also
> +:ref:`Documentation/admin-guide/security-bugs.rst <security-bugs>`.
>
>  Patches that fix a severe bug in a released kernel should be directed
>  toward the stable maintainers by putting a line like this::
> --
> 2.17.1

Reviewed-by: Felipe Balbi <balbi@kernel.org>

-- 
balbi

Re: [PATCH 2/2] docs: admin-guide: Not every security bug should be kept hidden

[Kees Cook]

On Thu, Aug 27, 2020 at 02:11:23PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 27, 2020 at 12:53:19PM +0200, Krzysztof Kozlowski wrote:
> > --- a/Documentation/admin-guide/security-bugs.rst
> > +++ b/Documentation/admin-guide/security-bugs.rst
> > @@ -78,6 +78,12 @@ include linux-distros from the start. In this case, remember to prefix
> >  the email Subject line with "[vs]" as described in the linux-distros wiki:
> >  <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
> >  
> > +Fixes for non-exploitable bugs which do not pose a real security risk, should
> > +be disclosed in a regular way of submitting patches to Linux kernel (see
> > +:ref:`Documentation/process/submitting-patches.rst <submitting-patches>`).
> > +Just because patch fixes some off-by-one or NULL pointer exception, does not
> > +classify it as a security bug which should be discussed in closed channels.
> 
> I said this on another thread, but almost always, when we get reports
> like this on security@k.o, we do push them back to public lists.
> 
> For the most part, this paragraph is not going to help much (mostly for
> the reason that no one seems to read it, but that's a different
> topic...)  We get crazy reports all the time, and that's fine, because
> sometimes, there is a real issue in some of them.  And for that, we do
> want to be careful.  We also have many docuemented "off-by-one" bugs
> that were real security issues (there's a blog post somewhere about how
> a developer turned such a bug into a root hole, can't find it right
> now...)
> 
> So while I understand the temptation here, based on the current
> security@k.o traffic, I doubt this will really change much :(

And given our relatively low traffic, I'd rather we (the
security@kernel.org folks) make the determination if things should be
public or private. We should be the ones on the hook for those judgement
calls, not the reporter reading our documentation. :)

-- 
Kees Cook

Re: [PATCH 1/2] docs: process: Add cross-link to security-bugs

[Jonathan Corbet]

On Thu, 27 Aug 2020 12:53:18 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> The submitting patches mentions criteria for a fix to be called
> "security fix".  Add a link to document explaining the entire process
> of handling security bugs.
> 
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
>  Documentation/process/submitting-patches.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 5219bf3cddfc..d5b3c5a74d5d 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -299,7 +299,8 @@ sending him e-mail.
>  If you have a patch that fixes an exploitable security bug, send that patch
>  to security@kernel.org.  For severe bugs, a short embargo may be considered
>  to allow distributors to get the patch out to users; in such cases,
> -obviously, the patch should not be sent to any public lists.
> +obviously, the patch should not be sent to any public lists. See also
> +:ref:`Documentation/admin-guide/security-bugs.rst <security-bugs>`.

I've applied this (but not part 2).

Thanks,

jon