ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Laura Abbott <labbott@redhat.com>
To: Dan Carpenter <dan.carpenter@oracle.com>,
	James Morris <jmorris@namei.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Security
Date: Sun, 23 Sep 2018 06:15:59 -0700	[thread overview]
Message-ID: <5a6f441f-89ae-454b-3689-2e5e605988ce@redhat.com> (raw)
In-Reply-To: <20180922131640.pxjwukrckggxtg3s@mwanda>

On 09/22/2018 06:16 AM, Dan Carpenter wrote:
> Sort of related to this.  I think we should have a public email list to
> discuss potential security problems.  We've actually talked about making
> the security@kernel.org list public at some point when people started
> flooding it with static checker warnings about potential SELinux missing
> checks.
> 
> The downsides are 1) Maintainers will be annoyed.  They don't want me or
> anyone to forward them static checker output (they are polite about
> this).  But they also want to be the first to know about real bugs found
> by static analysis.  These are conflicting and impossible desires...  2)
> Script kiddies will follow the list and learn about bugs earlier.  I
> don't see this as a huge issue if we restricted it to driver specific
> bugs.
> 
> Security work is lonely.  Everyone expects *all* the bugs to be fixed
> perfectly and in absolute secrecy.
> 
> Every other special interest group has a mailing list linux in
> automotive or small kernels.  Security would be the same.  Also I
> sometimes see obviously bad security fixes.  There is one integer
> overflow fixes which I have re-fixed three times.  Older me is able to
> review other people's integer overflow fixes and spot bugs.  It would be
> good to have a way to share that knowledge.
> 
> Most maintainers do not want to deal with more than a 5% false positive
> rate in static checker warnings.  I, on the other hand, regularly deal
> with a 95% false positive checks and there are probably other people
> like me who can spend a whole day looking and feel happy to find one
> bug.
> 

I think there's two different categories here: there's a general
security interest group and security response. security@kernel.org
is supposed to be security response for coordination. kernel-hardening
kind of fills the security interest list but maybe it's still separate.
I do support having more discussion of security bugs publicly while
also having a discussion about security response since we get a non-zero
number of reports that requires more careful handling.

Thanks,
Laura

  reply	other threads:[~2018-09-23 13:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-21 21:14 James Morris
2018-09-22 13:16 ` Dan Carpenter
2018-09-23 13:15   ` Laura Abbott [this message]
2018-09-23 13:20   ` Jiri Kosina
2018-09-23 18:34     ` Theodore Y. Ts'o
2018-09-23 18:54       ` Jiri Kosina
2018-09-24  9:21     ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a6f441f-89ae-454b-3689-2e5e605988ce@redhat.com \
    --to=labbott@redhat.com \
    --cc=dan.carpenter@oracle.com \
    --cc=jmorris@namei.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox