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 0E9DE15CC for ; Mon, 31 Aug 2015 20:22:28 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12140F4 for ; Mon, 31 Aug 2015 20:22:26 +0000 (UTC) Date: Mon, 31 Aug 2015 13:22:20 -0700 From: josh@joshtriplett.org To: "Eric W. Biederman" Message-ID: <20150831202220.GA3733@cloud> References: <20150824220525.GA15701@kroah.com> <871tejdxt2.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871tejdxt2.fsf@x220.int.ebiederm.org> Cc: Emily Ratliff , ksummit-discuss@lists.linuxfoundation.org, Jiri Kosina Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Aug 31, 2015 at 03:10:01PM -0500, Eric W. Biederman wrote: > Greg KH writes: > > > On Mon, Aug 24, 2015 at 12:00:15PM -0700, Kees Cook wrote: > >> On Mon, Aug 24, 2015 at 11:52 AM, Thomas Gleixner wrote: > >> > On Mon, 24 Aug 2015, Kees Cook wrote: > >> >> On Mon, Aug 24, 2015 at 4:56 AM, James Morris wrote: > >> >> This is far from a comprehensive list, though. The biggest value, I > >> >> think, would be in using KERNEXEC, UDEREF, USERCOPY, and the plugins > >> >> for constification and integer overflow. > >> > > >> > There is another aspect. We need to make developers more aware of the > >> > potential attack issues. I learned my lesson with the futex disaster > >> > and since then I certainly look with a different set of eyes at user > >> > space facing code. I doubt that we want that everyone experiences the > >> > disaster himself (though that's a very enlightening experience), but > >> > we should try to document incidents and the lessons learned from > >> > them. Right now we just rely on those who are deep into the security > >> > realm or the few people who learned it the hard way. > >> > >> Yeah, it can be a hard perspective shift to make. And shifting the > >> thinking about the kernel itself to always operating in a compromised > >> state makes thinking about how to protect it much easier. User space > >> is trying to hurt us! :) > > > > Microsoft's security team, which was responsible for forcing all of > > their developers to undergo some security training every year, has > > boiled it all down to these simple 4 words: > > > > All input is evil. > > I have a linux version of that one. > > An unprivileged user can call that. > > It is absolutely amazing how much kernel code does not worry > about evil input after it checks that the caller is root. Another that has only started getting consideration recently: relative to the kernel, root has less privilege. - Josh Triplett