[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 5 Nov 2015 16:14:22 -0500
From: David Windsor <dave@...141.net>
To: kernel-hardening@...ts.openwall.com
Subject: Re: Kernel Self Protection Project
Hi,
I've done some work towards adding PAX_REFCOUNT to Ubuntu previously [1],
so I can resurrect those patches. Note that those patches were directly
cherrypicked from PaX/grsec, without any sort of controls (sysctl, proc,
ioctl or otherwise) governing runtime behavior of this feature. I can add
them if desired.
I also proposed a patch for adding overflow protection to kref [2], but
that patch was ultimately shot down. Point being, I have some related
patches laying around that directly relate to refcount-based protection
which might be useful here.
Thanks,
David Windsor
[1]
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg3420821.html
[2] https://lkml.org/lkml/2012/2/24/331
On Thu, Nov 5, 2015 at 3:59 PM, Kees Cook <keescook@...omium.org> wrote:
> I'm organizing a community of people to work on the various kernel
> self-protection technologies (most of which are found in PaX and
> Grsecurity). I'm building on the presentation I gave at Kernel Summit
> where I sought to convince the other upstream Linux kernel developers
> that security is more than fixing bugs, and that we need to bring in
> proactive defenses:
> http://lwn.net/Articles/662219/
>
> This is especially highlighted by the Washington Post article today:
>
> http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/
>
> Between the companies that recognize the critical nature of this work,
> and with Linux Foundation's Core Infrastructure Initiative happy to
> start funding specific work in this area, I think we can really make a
> dent.
>
> Let's start the work. I've built some wiki pages around my slides,
> where we can take notes, list examples, and coordinate:
> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
>
> 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.
>
> I recommend PAX_REFCOUNT, PAX_USERCOPY, and GRKERNSEC_KSTACKOVERFLOW
> for some non-plugin stuff to look at.
>
> Once we've got plugins, then we should look at PAX_MEMORY_STACKLEAK
> and PAX_CONSTIFY_PLUGIN.
>
> If you're feeling like disrupting people who depend on debugging, do
> GRKERNSEC_HIDESYM.
>
> If you're feeling especially bold, start on PAX_KERNEXEC and follow it
> up with PAX_MEMORY_UDEREF.
>
> Of course, there's plenty of other things, and tons I haven't listed
> in the wiki -- please add them and bring them up for discussion here.
>
> -Kees
>
> --
> Kees Cook
> Chrome OS Security
>
Content of type "text/html" skipped
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.
