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

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

On Mon, 2015-07-13 at 16:25 -0700, Kees Cook wrote:
> On Sat, Jul 11, 2015 at 12:31 AM, James Bottomley
> <James.Bottomley@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. :)

Right, so there's no point having a huge lock on your front door if you
know there's a weak catch on the back one.

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

No, that was part of my point: detection of forged commits via stolen
ssh credentials without compromising the laptop are easily detectable.

The other part is that security is a chain: it's only as strong as its
weakest link.  One consideration in making a chain is that you try to
have all the links be of roughly equal strength.  In security terms you
do this because security is a tradeoff: there's no point having onerous
security on one link if another is weak because people just bitch about
the pointless problems this causes.  That's precisely why security is a
tradeoff: you assess the threats and counter what you can in a way that
makes the least impact to usability.  What you should never do (unless
you're a government) is make an elaborate show of security to give a
false impression because clever people notice and real security suffers.

> >> - 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. :(

While security fixes (and the kernel security list) aren't transparent,
I don't really see what else we can do.  Stable is our last best effort
before it gets handed off, unless you have another proposal?

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

So you seem to be implying this is a funding problem?  We could easily
apply to the CII for a full time position if that's the case (and we
have a good job description).

James