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

[Greg KH <greg@kroah.com>]

On Mon, Aug 24, 2015 at 12:00:15PM -0700, Kees Cook wrote:
> On Mon, Aug 24, 2015 at 11:52 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Mon, 24 Aug 2015, Kees Cook wrote:
> >> On Mon, Aug 24, 2015 at 4:56 AM, James Morris <jmorris@namei.org> 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.