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

[Andy Lutomirski <luto@amacapital.net>]

On Mon, Aug 24, 2015 at 10:17 AM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Aug 24, 2015 at 4:56 AM, James Morris <jmorris@namei.org> wrote:
>> On Mon, 24 Aug 2015, Jiri Kosina wrote:
>>
>>> On Mon, 24 Aug 2015, James Morris wrote:
>>>
>>> > I'd recommend Kees Cook be involved, due to his existing efforts in
>>> > kernel hardening.  I think it would be good to invite one or two expert
>>> > security researchers in this area -- Kees would know who.  In terms of
>
> Many of the folks that are good at kernel exploitation don't want to
> help us fix the situation. :)
>
> I'd recommend Lee Campbell, he's got a solid bit of experience from
> the offense side. I think we should extend an invite to spender and
> pageexec as well. They've been on the cutting edge of this for
> decades, and it would be silly not to invite them.
>
>>> > core kernel folk, I'd suggest Ingo and akpm, as a starting point.
>
> Perhaps also Linus and rmk? Some of the protections are very central
> to the kernel (e.g. constification, "read-mostly", segmentation
> through page table swaps or domains, etc). I'd also want Andy
> Lutomirski around, as he's got a lot of deep chipset knowledge. :)
>

What is this chipset knowledge you speak of? :)

One thing that grsecurity addresses (partially or fully?  I haven't
looked that closely): we have tons of static, non-const data structure
that contain function pointers, and we can't make them const because
they get filled in when things are initialized.  Grsecurity mitigates
this with some combination of compiler plugins and pax_open_kernel,
but we could probably come up with a more straightforward solution.
We could add an ro_after_init section, or we could even have a section
for things that are const but are writable through a special function.

>>>
>>> I am pretty sure spender will also have a lot to tell us :p
>>
>> He actually presented at the 2010 security summit:
>> https://grsecurity.net/spender_summit.pdf
>
> This was his bullet list of things that grsecurity/PaX already does
> and that should be in mainline (with my notes in parens). He suggested
> it would take us 10 years to catch up. We're 5 years into that, with
> only a few things partially off this list:
>
>  Remove infoleaks
>  o Symbol information (partial improvement via kptr_restrict)
>  o Slabinfo (partial improvement with 0400 root perms)
>  o PAX_USERCOPY (even if gcc fixed their sizeof bug, we'd be no where
> near this plugin's level of protection)
>  Remove RWX from kernel (in good shape on x86, started on arm)

We still need to do something about the direct map, IIRC.  Or did we
already fix that?

>  Protect sensitive data
>  o Constify function pointers! (no where close to this plugin)

As above, this would be nice.  If we did this upstream, we could do
even better if we outright disallowed non-const function pointers (as
opposed to fixing them up semi-transparently as the plugin does).

>  o IDT/GDT/syscall table/etc (this is partially done, aliases are
> writable still)

I don't think the RO GDT patches ever happened.

FWIW, we can't really eliminate a writable GDT alias without killing
compat performance: set_thread_area rather critically depends on
writing to the GDT at context switch time.

>  o Vsyscall shadow table, see sgrakkyu's remote
> SELinux-disabling exploit
> (http://sgrakkyu.antifork.org/sctp_houdini.c, luto fixed this via
> vsyscall emulation)

Not done yet, because even modern binaries still have the thing
mapped.  We could devote two or three minutes of a KS session to
figuring out how to kill it off for real for modern binaries.

>
> This is far from a comprehensive list, though. The biggest value, I
> think, would be in using KERNEXEC, UDEREF, USERCOPY, and the plugins
> for constification and integer overflow.

At the risk of poking a big elephant, I think we should do something
about perf, too.  Perf is really useful, but it's also a *huge* attack
surface.

--Andy