[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Mar 2017 15:17:55 -0800
From: Kees Cook <keescook@...omium.org>
To: Tycho Andersen <tycho@...ker.com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Ahoy!
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. :)
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.
So, that's the first thing that pops out at me. What do you think? :)
-Kees
--
Kees Cook
Pixel 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.
