kernel-hardening - Re: Kernel Self Protection Project

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <563CF235.7030105@nod.at>
Date: Fri, 6 Nov 2015 19:32:21 +0100
From: Richard Weinberger <richard@....at>
To: Kees Cook <keescook@...omium.org>,
 "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Cc: Solar Designer <solar@...nwall.com>, Greg KH
 <gregkh@...uxfoundation.org>, Ben Hutchings <ben@...adent.org.uk>,
 Ard Biesheuvel <ard.biesheuvel@...aro.org>, James Morris
 <jmorris@...ei.org>, Andy Lutomirski <luto@...capital.net>
Subject: Re: Kernel Self Protection Project

Am 06.11.2015 um 19:11 schrieb Kees Cook:
> On Fri, Nov 6, 2015 at 5:28 AM, Yves-Alexis Perez <corsac@...ian.org> wrote:
>> On jeu., 2015-11-05 at 12:59 -0800, Kees Cook wrote:
>>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
>>> gcc plugin, which will also get us the gcc plugin infrastructure.
>>> Other people, please speak up on what you'd like to tackle.
>>
>> Hi Kees, and first many thanks for the initiative. That's definitely something
>> of interest for me (both personally and professionally).
>>
>> Something which might also be interesting in kernel self protection is the
>> “active response” found in grsecurity (GRKERNSEC_SEC_KERN_LOCKOUT) and the
>> “deter exploite bruteforcing” (GRKERNSEC_BRUTE), which can help prevent
>> exploitation with repeated attempts.
> 
> I don't want to discourage work on any of this, but for now, I'm
> trying to focus on kernel protections (rather than the userspace
> hardening features). If other people (you?) want to coordinate the
> userspace hardening work, then let's add it to the list, and create a
> separate kernsec.org wiki landing place for it. I think it should be
> organized in the same way, though: discuss a problem, give examples,
> list potential mitigations.
> 
> FWIW, GRKERNSEC_BRUTE was attempted earlier[1], and the technical
> discussion devolved into people thinking that glibc should handle it.
> I totally disagree[2], since not all systems use glibc (Android).
> Bruteforcing protection should be in the kernel: it is the manager of
> processes, full stop.

Thanks for bringing up my patch again.
Given the push back I've received (on and off list) I gave up.
But maybe it is time to try a second time. :-)

> [1] https://lkml.org/lkml/2014/12/24/306
> [2] https://lkml.org/lkml/2015/1/5/732

Thanks,
//richard

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.