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

[Jason Cooper]

On Fri, Jul 10, 2015 at 03:08:57PM -0700, Kees Cook wrote:
> On Fri, Jul 10, 2015 at 9:23 AM, Theodore Ts'o <tytso at 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.

I am as well, but most of those can be discussed openly.  I thought the
KS would be a good opportunity to sit down and compare notes about
things we may not be comfortable discussing in public.

> 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?

I'm open to these for sure, but it's time dependent.  This could easily
turn into the KSS, Kernel Security Summit.  *I* think that would fun,
but a lot of others might not.

> - supply chain security: I see two parts:
>   - intentionally malicious commits (as Ted describes below)
>   - personal security (keep commit credentials secure from theft)

> - reactive security: bug fix workflow
>   - getting fixes _to end users_ (not the same as publishing to stable)
>   - documenting impact when known (avoiding intentional obfuscation)

This one is a can of worms that no one has solved yet.  It's the
conflict between the 'open' in "open source" and the reality of patch
propagation.  Or complete lack there of when users don't update.  I
doubt we could add anything new to the discussion, let alone solve the
problem at KS.

> - 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)

These are fun, but in the traditional security vein.  Not to say they
aren't worthy of discussion, but that they can and are discussed in
public.  If we choose to add this to the agenda, perhaps a summary of
the state of the art from the parties involved would suffice?

> My question would be: where do we need discussion? "Supply chain
> security" was discussed a fair bit after the kernel.org incident.

That was pre-Snowden.  Also prior to a bunch of game-changing hacks and
vulnerability disclosures.  I think it's safe to say everyone's security
awareness and imagined art-of-the-possible has opened up in the past
couple of years.  Particularly for non-security minded folks.

I think that merits revisiting the topic.  As Olof said, what are the
convenience-vs-security tradeoffs everyone is doing today?  Which of
them sound sane, which need tweaking?

thx,

Jason.