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 C1152B13 for ; Mon, 24 Aug 2015 20:17:38 +0000 (UTC) Received: from namei.org (tundra.namei.org [65.99.196.166]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4EEBF174 for ; Mon, 24 Aug 2015 20:17:38 +0000 (UTC) Date: Tue, 25 Aug 2015 06:17:30 +1000 (AEST) From: James Morris To: James Bottomley In-Reply-To: <1440446941.2201.32.camel@HansenPartnership.com> Message-ID: References: <1440446941.2201.32.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: "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, 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 -- James Morris