From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EAEFAC18 for ; Mon, 24 Aug 2015 18:57:40 +0000 (UTC) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31765198 for ; Mon, 24 Aug 2015 18:57:40 +0000 (UTC) Received: by igfj19 with SMTP id j19so63454916igf.1 for ; Mon, 24 Aug 2015 11:57:39 -0700 (PDT) MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: References: Date: Mon, 24 Aug 2015 11:57:39 -0700 Message-ID: From: Kees Cook To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jiri Kosina , "ksummit-discuss@lists.linuxfoundation.org" , Emily Ratliff Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Aug 24, 2015 at 11:19 AM, Andy Lutomirski wro= te: > On Mon, Aug 24, 2015 at 11:01 AM, Kees Cook wrote= : >> On Mon, Aug 24, 2015 at 10:28 AM, Andy Lutomirski = wrote: >>> On Mon, Aug 24, 2015 at 10:17 AM, Kees Cook wro= te: >>>> On Mon, Aug 24, 2015 at 4:56 AM, James Morris wrot= e: >>>>> 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 i= n >>>>>> > kernel hardening. I think it would be good to invite one or two e= xpert >>>>>> > security researchers in this area -- Kees would know who. In term= s 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 =3D whatever; kernel_close(); This should be way better than what we have already. >>>> =EF=82=98 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=3Dnone 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 =3Dnone, you want a per-process runtime config? I think =3Dnone should just become the global default. :) -Kees --=20 Kees Cook Chrome OS Security