[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKkF61CG_Aiv19p24XvJ7yQ-V+J_RBXbvMbw-cWmzDbmQ@mail.gmail.com>
Date: Fri, 6 Nov 2015 10:11:21 -0800
From: Kees Cook <keescook@...omium.org>
To: "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>, Richard Weinberger <richard@....at>,
Andy Lutomirski <luto@...capital.net>
Subject: Re: Kernel Self Protection Project
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.
> Some features (especially SEC_KERN_LOCKOUT) are really more useful when UDEREF
> and KERNEXEC are available (since those are the most severe violations one can
> find), but it could still apply to other violations.
I think GRKERNSEC_KERN_LOCKOUT is kind of on both sides of the
kernel/userspace defense fence. For now, I think the granularity of
response for KSPP-ported features will likely just be a full system
Oops. But I suspect once more of them land, we'll want the finer
granularity that GRKERNSEC_KERN_LOCKOUT provides.
-Kees
[1] https://lkml.org/lkml/2014/12/24/306
[2] https://lkml.org/lkml/2015/1/5/732
--
Kees Cook
Chrome OS Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
