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

[Kees Cook <keescook@chromium.org>]

On Mon, Aug 24, 2015 at 11:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> 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.

Well... open_kernel turns off preempt. With the inlining, no-preempt,
and barriers, it should be correct, yes? Used as:

kernel_open();
readonly_thing = whatever;
kernel_close();

This should be way better than what we have already.

>>>>  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.

Oh, instead of just 87983c66bc02 plus =none, you want a per-process
runtime config? I think =none should just become the global default.
:)

-Kees

-- 
Kees Cook
Chrome OS Security