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

[josh@joshtriplett.org]

On Mon, Aug 24, 2015 at 01:09:01PM -0700, James Bottomley wrote:
> On Mon, 2015-08-24 at 09:35 -0700, Kees Cook wrote:
> > On Mon, Aug 24, 2015 at 5:29 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Mon, Aug 24, 2015 at 6:20 AM, James Morris <jmorris@namei.org> wrote:
> > >
> > >> There are also potentially promising approaches to mitigation with other
> > >> technologies such as KASan and gcc plugins, as well as evolving hardware
> > >> features.
> > >
> > > What I've discovered when running KASan the last few weeks is that
> > > this points back to the question of tests ... I've been using Trinity
> > > to find bugs, but it is more likely to kill itself or cause OOM than
> > > trigger any boundary overrun bugs.
> > >
> > > Kselftest may be helpful, but basically any loads that heavily
> > > exercise the kernel internals are helpful to harden the kernel.
> > > Some of these are custom test suites I suspect. Any good hints
> > > for a simple embedded developer like me?
> > 
> > I agree with the sentiment here, but not with the language. Finding
> > flaws (which is what selftests, KASan, Trinity, etc do) isn't
> > hardening. Hardening is stopping the exploitation of flaws.
> 
> 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).

There's a difference between fixing an individual vulnerability
discovered by fuzzing and other tools, and fixing (or at least making it
easier to do the right thing for) an entire *class* of
vulnerabilities.  We should fix the former when we find them, but any
time we see more than a couple bugs of the same time, we should be
asking "how can we never have another?".

- Josh Triplett