[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170309024229.GA6638@hopstrocity>
Date: Wed, 8 Mar 2017 18:42:29 -0800
From: Tycho Andersen <tycho@...ker.com>
To: Kees Cook <keescook@...omium.org>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Ahoy!
Hey Kees,
On Wed, Mar 08, 2017 at 03:17:55PM -0800, Kees Cook wrote:
> On Tue, Mar 7, 2017 at 3:37 PM, Tycho Andersen <tycho@...ker.com> wrote:
> > I'm a new engineer at Docker, and I've been given some time to work on
> > kernel security, so I figured I'd introduce myself here. I'm currently
> > trying to figure out what a good first small-ish project that matches up
> > with the company's interests (containers, infrastructure that is used for
> > security primitives like eBPF).
> >
> > Thoughts about areas to poke at are much appreciated!
>
> Hi! Welcome to the fun!
>
> As I understand it (for our earlier chat), Docker is mainly x86, which
> somewhat limits choices from the existing KSPP TODO list which has a
> lot of arm and arm64 stuff on it. :)
Yes, unfortunately :(.
> So, here's one that isn't protection exactly, but rather a requested
> arrangement of Kconfig logic: it would be nice if HARDENED_USERCOPY
> depended on !DEVKMEM and STRICT_DEVMEM=y, but this isn't quite trivial
> since STRICT_DEVMEM doesn't exist for all architectures, but maybe it
> should be looking at ARCH_HAS_DEVMEM_IS_ALLOWED... (it seems Dan
> Williams cleaned this up a lot already in commit 21266be9ed542)
>
> Regardless, no one has snagged this to make sure that hardened
> usercopy isn't bypassed by things like DEVKMEM or DEVMEM and the lack
> of STRICT_DEVMEM. I'd like to have that off the list, and mostly I
> think it just requires staring at the Kconfigs for a bit to figure out
> the right combination so that people wanting hardened usercopy don't
> accidentally undermine themselves.
Yeah, I think it is fairly simple. Does the attached patch look like
what you had in mind? I can send out a real version to the right
people if it looks reasonable.
> So, that's the first thing that pops out at me. What do you think? :)
I was curious about PAX_MEMORY_STACKLEAK, actually. I noticed in the
initial KSPP announcement email you mentioned it, and it's not clear
to me that anything actually got merged for it.
I understand in principle what needs to happen, but I'm not sure I
understand why a gcc plugin is required. Anyway, it seems like a
small-ish change (that could be hid behind a sysctl or a compiler
flag) that is reasonable enough to start with. Thoughts?
Thanks,
Tycho
View attachment "0001-security-Kconfig-further-restrict-HARDENED_USERCOPY.patch" of type "text/x-diff" (942 bytes)
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.
