[Ksummit-discuss] [TECH TOPIC] Security

[Ksummit-discuss] [TECH TOPIC] Security

[James Morris]

I'd like to propose a security discussion topic again this year, as folk 
may have security-related development issues (e.g. cross-subsystem 
merges, points of conflict) to discuss with the broader kernel group.

For reference, here is last year's agenda:
http://kernsec.org/wiki/index.php/Linux_Kernel_Summit_2017,_Security_Session

The agenda for 2018 would be finalized closer to November.

-- 
James Morris
<jmorris@namei.org>

Re: [Ksummit-discuss] [TECH TOPIC] Security

[Dan Carpenter]

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.

regards,
dan carpenter

Re: [Ksummit-discuss] [TECH TOPIC] Security

[Laura Abbott]

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

Re: [Ksummit-discuss] [TECH TOPIC] Security

[Jiri Kosina]

On Sat, 22 Sep 2018, 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.

3) there simply is a need for CRD process for the kernel (which pretty 
   much by definition is not happening publicly). Currently, security@ 
   serves that purpose, so if you make that public, you have to 
   instantiate some other process to deal with CRDs.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [TECH TOPIC] Security

[Theodore Y. Ts'o]

On Sun, Sep 23, 2018 at 03:20:22PM +0200, Jiri Kosina wrote:
> 3) there simply is a need for CRD process for the kernel (which pretty 
>    much by definition is not happening publicly). Currently, security@ 
>    serves that purpose, so if you make that public, you have to 
>    instantiate some other process to deal with CRDs.

Can you expand the acronym "CRD".

					- Ted

Re: [Ksummit-discuss] [TECH TOPIC] Security

[Jiri Kosina]

On Sun, 23 Sep 2018, Theodore Y. Ts'o wrote:

> > 3) there simply is a need for CRD process for the kernel (which pretty 
> >    much by definition is not happening publicly). Currently, security@ 
> >    serves that purpose, so if you make that public, you have to 
> >    instantiate some other process to deal with CRDs.
> 
> Can you expand the acronym "CRD".

"Coordinated release date" across the various affected vendors.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [TECH TOPIC] Security

[Dan Carpenter]

On Sun, Sep 23, 2018 at 03:20:22PM +0200, Jiri Kosina wrote:
> On Sat, 22 Sep 2018, 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.
> 
> 3) there simply is a need for CRD process for the kernel (which pretty 
>    much by definition is not happening publicly). Currently, security@ 
>    serves that purpose, so if you make that public, you have to 
>    instantiate some other process to deal with CRDs.

I'm not saying we would eliminate security@kernel.org.  We would keep
that.  security@kernel.org also does not want to answer questions about
every "suspicious code" that people find.

For coordinated responses you need linux-distros. security@kernel.org
does not do it.

security@kernel.org is there for two reasons.  First we need a contact
to deal with security issues.  About half the time when people send us
security reports to security@kernel.org then we just forward it to the
appropriate maintainer.  Second, it's has a bunch of core developers for
serious bugs in ptrace or similar which affect everyone.  Those kinds of
fixes are risky and complicated.  But after a fix is found then distros
are expected to handle the release and getting the CVE etc.

regards,
dan carpenter