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

[Kees Cook <keescook@chromium.org>]

On Mon, Aug 24, 2015 at 4:54 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Aug 24, 2015 at 04:20:47PM -0700, Kees Cook wrote:
>>
>> Could we assign this as homework instead?  There are countless examples
>> of well described kernel exploits already visible on the web....
>
> Might I suggest a somewhat higher-level homework?  What are the kernel
> self-protection features that would be most useful for us to
> implement, and --- this is critically important --- why aren't we

I listed a bunch in my earlier reply. You can see a nice breakdown of
them in pageexec's slides on the topic:
https://pax.grsecurity.net/docs/PaXTeam-H2HC12-PaX-kernel-self-protection.pdf

> doing them already, and how can we fix that higher-order issue?

They are each complex, and no one has the interest, skills, tenacity,
and work-priority available to them yet. I continue to chip away at
pieces here and there, but I'm just one person, and I'm probably
lacking in skill too.

> Is it because adding a particular feature would incur a huge
> performance penalty?

Some do, yes. Most don't. Mostly it's just the will to fight for the
changes. I think the concepts behind grsec/PaX's KERNEXEC would be a
great first target. Many other features depend on being able to trust
various aspects of kernel's resulting memory footprint.

> Is it because no company has been willing to fund developers to work
> on that particular feature to date?  (BTW, I consider the fact that

Yes, that's a big part of it. Also, the political navigation of the
feature is time-consuming. But I've been trying to socialize these
ideas for a while now, so they shouldn't be too much of a shock to
anyone. The concept and benefits of defensive features (as opposed to
bug killing) has been traditionally difficult to get people to see.

> various companies collectively wasn't able to find a place for the
> trinity maintainer to find a place to land to be somewhat of a failure
> of the ecosystem, but maybe the tool wasn't as useful as we think, or
> it maybe we failed to make the case to the correct set of
> bean-counters.)

Agreed. Though AIUI, loss of trinity maintenance had more to do with
people not contributing back to it. He should speak for himself,
though. :)

> If the answer is that it's obvious what needs to be done, but (a) we
> can't find anyone to bell the cat, or (b) the patches are going to be
> rejected out of hand for one reason or another, the kernel summit is a
> great opportunity to see if some face-to-face discussion address the
> problem.  OTOH, if the fundamental problem is that we can't get the
> headcount funded, then discussion at the kernel summit is probably not
> going to be a good use of our time.  :-/

Understanding the value of self-protection technologies will go a long
way to accepting them when someone tries to present them for upstream.
Accepting the limitations they present (e.g. gcc plugins may only work
with certain compiler versions, etc) can be a hard pill to swallow,
but I think it's best for the end users.

-Kees

-- 
Kees Cook
Chrome OS Security