[Ksummit-discuss] [TECH TOPIC] Kernel Hardening

Eric W. Biederman ebiederm at xmission.com
Mon Aug 31 20:10:01 UTC 2015


Greg KH <greg at kroah.com> 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 <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.

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.

Eric


More information about the Ksummit-discuss mailing list