Re: [Ksummit-discuss] [CORE TOPIC] dev/maintainer workflow security

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2015-07-10 at 15:08 -0700, Kees Cook wrote:
> On Fri, Jul 10, 2015 at 9:23 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> > On Fri, Jul 10, 2015 at 11:50:30AM -0400, Josh Boyer wrote:
> >> > This is a topic of interest to me that I think would best benefit from a
> >> > conference room discussion.
> >> >
> >> > Items to discuss:
> >> >
> >> >  - Survey the room on workflows and security posture for kernel work
> >> >  - Discussion of threat models, attack vectors
> >> >  - Discuss mitigation methods, tools and techniques
> >> >  - Identify missing tools or features of tools
> >> >
> >> > The intent is to discuss end point security with regards to protecting
> >> > the kernel source tree.
> >>
> >> Interesting.  Though I think it needs a broader audience to be honest.
> >> It would be far easier to use distros as an attack vector than to try
> >> subverting the upstream source code.  This might be a good topic for
> >> something like Linux Plumbers.
> >
> > I agree that the issue of trusting distros and the possibility of
> > hiding malware in distro software is an important one, and one which
> > is best addressed at something like Plumbers.
> >
> > However, there are a number of Kernel-specific security issues which
> > are just as important --- how we maintain our own personal security,
> > and how we make sure a backdoor doesn't get slipped into the kernel
> > source tree.
> 
> I'm curious about the larger set of security topics. Jason's topic
> seems to surround "supply chain security", but I think we've got a lot
> of other areas. Is focusing on just that topic the right thing to do?
> 
> - supply chain security: I see two parts:
>   - intentionally malicious commits (as Ted describes below)

You're missing a huge one and the usual way we get security breaches:
accidental commits that weren't reviewed properly (or which the
reviewers didn't spot the potential security problem).  All of the
recent spate of serious vulnerabilities (heartbleed, shellshock, etc)
have been accidental.

If we can concentrate on this one, and find a way of fixing it, the
malicious but obfuscated commit will be covered under that.

>   - personal security (keep commit credentials secure from theft)

This second one is a bit of a red herring:  Assuming you did steal my
credentials, how would you use them without being detected?

Security is not an absolute, it's a tradeoff.  The point of the tradeoff
is to make sure you address the significant threats while not impeding
the workflow too much.  If we start worrying about and addressing
insignificant threats, eventually you won't get on to kernel.org without
going through airport theatre style security.

> - reactive security: bug fix workflow
>   - getting fixes _to end users_ (not the same as publishing to stable)

Stable is our last point.  After that, it's up to the distros

>   - documenting impact when known (avoiding intentional obfuscation)
> - proactive security: stop security flaws from happening in the first place
>   - scope analysis (defending both userspace and kernel from attack)
>   - threat analysis (how are attacks being made now and in future?)
>   - exposure analysis (syscall interface, device firmware, etc)
>   - static checkers (find and eliminate bug classes in the code)
>   - run-time mitigation features (endless list: memory protection, CFI,
>     ASLR, anti-bruteforcing, etc)

Perhaps the question here is would we be interested in making use of the
core infrastructure initiative to give us a security analysis of parts
of the kernel (and if so, which parts).

James