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.