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

[Kees Cook <keescook@chromium.org>]

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

My question would be: where do we need discussion? "Supply chain
security" was discussed a fair bit after the kernel.org incident.
"Reactive security" has seen endless discussion, and there are a
number of stale-mate topics. "Proactive security" is what I'm most
interested in, but tends to lack enough engineering resources to
really make strong headway. There are a number of dedicated folks, but
we need more people on that topic, not really more discussion.

I'm not saying we shouldn't have a discussion: I'm more curious to
hear where people think we should focus for a single session's time.

> This ends up relating to the code reviewer problem, and I've always
> been convinced that if I had a a few dozen students to coach in a
> computer security class, tasked as part of a semester-long class
> project to attempt to sneak an obfuscated security bug as part of some
> code cleanup or refactoring patch, at least one of them would end up
> getting into Linus's tree.  The only reason why I haven't done this is
> no one would have forgiven me afterwards, and the resulting bad
> publicity wouldn't be good for Linux.

My paranoid brain thinks this has likely already happened. :)

> I wonder if this might be better done as a panel session during the
> wider technical session day?

As mentioned in other replies, I think this would be best served as a
panel session to keep the audience tighter. It's a large field of
discussion and we might have problems staying on track even in the
smaller group.

-Kees

-- 
Kees Cook
Chrome OS Security