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 10453847 for ; Mon, 24 Aug 2015 23:25:56 +0000 (UTC) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7FC9C1FC for ; Mon, 24 Aug 2015 23:25:55 +0000 (UTC) Received: by iodt126 with SMTP id t126so167879933iod.2 for ; Mon, 24 Aug 2015 16:25:55 -0700 (PDT) MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: References: <1440446941.2201.32.camel@HansenPartnership.com> Date: Mon, 24 Aug 2015 16:25:54 -0700 Message-ID: From: Kees Cook To: James Morris Content-Type: text/plain; charset=UTF-8 Cc: James Bottomley , "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 3:57 PM, Kees Cook wrote: > On Mon, Aug 24, 2015 at 1:17 PM, James Morris wrote: >> On Mon, 24 Aug 2015, James Bottomley wrote: >> >>> Um, forgive me for being dense, but doesn't fixing the flaws stop their >>> exploitation? In any event, Hardening means "reducing the attack >>> surface" and that encompasses both active and passive means (including >>> actual bug fixing). >> >> Hardening is mitigating those flaws. You'll never find every flaw, but >> you can mitigate against entire classes of flaws being exploited. >> >>> > The >>> > hardening the kernel needs is about taking away exploitation tools, >>> > not killing bugs. (Though killing bugs is still great.) >>> >>> It's both. One of the old standards for attacking C code was buffer >>> overruns. Remove those via detection tools and you reduce the attack >>> surface. >> >> In this case, we're specifically talking about hardening the kernel to >> mitigate exploitation of flaws. Kernel self-protection may be a better >> term (and recently surfaced in an NSA presentation at LSS: p.23 of >> >> http://kernsec.org/files/lss2015/lss2015_selinuxinandroidlollipopandm_smalley.pdf > > Yup. Using "kernel self-protection" cuts right to the point. I'm in > debt to Stephen for finding the right marketing term for "kernel > memory corruption vulnerability exploit mitigation". :) pageexec informs me he used the term earlier... https://pax.grsecurity.net/docs/PaXTeam-H2HC12-PaX-kernel-self-protection.pdf Regardless, you're all awesome. -Kees -- Kees Cook Chrome OS Security