Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, 25 Aug 2015, James Morris wrote:
> On Mon, 24 Aug 2015, James Bottomley wrote:
> 
> > Um, forgive me for being dense, but doesn't fixing the flaws stop their
> > exploitation?  In any event, Hardening means "reducing the attack
> > surface" and that encompasses both active and passive means (including
> > actual bug fixing).
> 
> Hardening is mitigating those flaws.  You'll never find every flaw, but 
> you can mitigate against entire classes of flaws being exploited.

Fair enough, but I agree with James, that we should not make this an
isolated topic.

Let's look at it from a different POV. 10+ years ago locking was
something which was only understood by a minority of the developers
and they had to figure out (or not) the horrible once per year
deadlocks.

Then RT happened to expose a gazillion of those issues and once we got
tired of debugging this hard to understand problems we came up with a
tool which tells Joe Developer where he screwed up.

As a consequence developers got more aware of locking semantics and
the number of hard to figure out lock inversion problems got reduced
significantly.

We added a lot of other mechanisms to detect different classes of
failure (use after free, ....). Both runtime debugging facilities and
static code analysis have helped to improve the code quality and the
awareness of developers.

Security and the pitfalls of user space facing code are still a riddle
wrapped up in an enigma for most developers, so the question is how
can we improve that situation.

While we certainly want to add mechanisms which prevent flaws to be
exploited we surely want to do something about educating people how to
avoid the flaws in the first place.

One can read about interesting ways to subvert a lot of the hardening
techniques every other day, so while we certainly want to add
hardening techniques, it's even more important that these techniques
become the last parachute and not the catch it all mechanism because
we gave up on the underlying issues.

I totally agree that we cannot prevent all flaws, but we certainly can
do better in reducing the quantity. And that means that we need to
educate people. And that education involves traditional training,
documentation and clever usage of tools. If we can use hardening
techniques to slap developers on their fingers, that's certainly a
good thing. But we don't want to decouple the hardening from 'reduce
the flaws' as you might create the impression that it's not that
important to think security aware because the hardering techniques
will prevent the exploits anyway.

Thanks,

	tglx