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, and the technical discussion devolved into people thinking that glibc should handle it. I totally disagree, 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  https://lkml.org/lkml/2014/12/24/306  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.