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

[Andy Lutomirski <luto@amacapital.net>]

On Mon, Aug 24, 2015 at 11:01 AM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Aug 24, 2015 at 10:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> 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? :)
>
> You appear to enjoy fixing deep x86 madness. :)
>
>> 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,
>
> Right. That's the constification and KERNEXEC pieces.
>
>> 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 don't think it would be that clean: there are many targets that
> legitimately need updating at runtime, but should be otherwise
> read-only. The idea with solving that is to use inline
> open/close_kernel calls to make them writable briefly and in a way
> that is ROP-defensive.

I really dislike open_kernel.  It's basically "turn off RO completely
-- please ROP me".  If we had a nice, conservative "poke this value
into this place that is hopefully actually a compile-time constant
address", I'd be much happier with it.

>
>>>  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).
>
> I would love this. :)
>
>>>  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.
>
> If that's what's needed, I am fine killing compat performance. (We
> could attempt to make this a CONFIG for those that expect to run
> compat loads for their kernels.)

We would need to change the default behavior or arch_set_fs, too,
since some 64-bit processes use that mechanism as well.  But that's
easy.

>
>>>  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.
>
> What uses it? I can run with vsyscall=none without problems...

Nothing, but it's still mapped by default.  I want something like the
stack access flags or an arch_prctl so glibc can turn it off by
default.

--Andy