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

[Kees Cook]

On Sat, Jul 11, 2015 at 12:31 AM, James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Fri, 2015-07-10 at 15:08 -0700, Kees Cook wrote:
>>   - 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?

Well, I meant it in a general sense. Whether that's your ssh key, or
direct access to your entire network through backdoored network card
firmware and SMM code, there are TONS of way to be owned 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.

We have one thing that a lot of other workflows don't: transparency,
so we can examine commit histories, etc. This makes credential theft
much less useful (which I think was your point).

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

I don't agree with this. Distros are just one consumer. I think it's
worth examining how real-world devices end up running Linux. Telcos
pushing kernel updates, for example, jumps to mind. I think it's a
weak stance to say "well, they should update to the latest kernel". Is
it a failing of our community that it's so much work for these vendors
to update kernels? Is offering an LTS "good enough", or can we do
more? It's Linux's name that gets smeared by vendors who are terrible
at updating kernels. :(

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

I actually think the issue is body count. We have a lot of tools
already. We have coverity, for example, but it needs full-time work
(by a few people, I think) to trim false-positives, improve rules, and
extract the real bugs. Which companies are paying people to do this
full-time? Our numbers aren't improving much in this area. We've
actually been getting smaller... Dave Jones, come back, we all still
love Trinity! :)

-Kees

-- 
Kees Cook
Chrome OS Security