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@xxxxxxxxxxxxxxxxxxx> > > Cc: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> > > Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > > Cc: Kees Cook <keescook@xxxxxxxxxxxx> > > Signed-off-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> > > > > --- > > > > Follow up to: > > https://lore.kernel.org/linux-usb/1425ab4f-ef7e-97d9-238f-0328ab51eb35@xxxxxxxxxxx/ > > --- > > 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
