[Ksummit-discuss] [TECH TOPIC] Kernel Hardening

[Rafael J. Wysocki]

On Monday, August 24, 2015 05:05:25 PM Greg KH wrote:
> 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 at linutronix.de> wrote:
> > > On Mon, 24 Aug 2015, Kees Cook wrote:
> > >> On Mon, Aug 24, 2015 at 4:56 AM, James Morris <jmorris at 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.

Right.

And not just input, but also everything you created and then allowed
someone else to modify.

Thanks,
Rafael