From patchwork Thu Mar 9 02:42:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tycho Andersen X-Patchwork-Id: 9612251 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AD73F6016C for ; Thu, 9 Mar 2017 02:42:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9961F28610 for ; Thu, 9 Mar 2017 02:42:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8A63F2861C; Thu, 9 Mar 2017 02:42:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 0511E28610 for ; Thu, 9 Mar 2017 02:42:45 +0000 (UTC) Received: (qmail 24282 invoked by uid 550); 9 Mar 2017 02:42:44 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 24264 invoked from network); 9 Mar 2017 02:42:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=docker.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yUNYHpZKR6iY9vIzLhTdDEWYmUvz8NstrACA2hwr+U0=; b=EA/Ei2BpTHow3Dw9Mm3mXEMTQ3Wbom/kc+YiG2/RbVbZfWH3eMYC3zJu7mhJuJcoTf Jn7m4kxe1KO/OvatmshBcLPONjvpTLRkd3P1jZdaFyxJ+OVcXnHZtbIUhW3dIPxUkhjM BNMq0YcMFXXmcUEmgX/dBUaNcs1jgVWp7ZXKI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yUNYHpZKR6iY9vIzLhTdDEWYmUvz8NstrACA2hwr+U0=; b=arhHAMTuT12tMogOobcnXpHF63C+Md078PvoWj0QWao8qUxW1h7xDuO9HNgfpt9mtt giMDOWxz2F8Y6/ChZTEXpK5aQTdUsTN8NEO5gTWp4DOI/IRc70y4wJaXrh637JnVkzwP /ZZg+jiAJvQ2EJ2GoGtjTUQBzLVT5btTPJ9ISO6ZVZ6Oa+F7cHyOKHkgqAql9o97f0KE /npFTsm1/jaxoOSGrh5qjgBYTXuYtTVH79tccqPt7XFfoKnIx4lkmDExagohBEhu0Kmx IvDhF7/UHH3SjJQS6ldM7Bhr6czhWnYOyV14tIKhWe/Fzr+roveFZzpgM8gtWjqkVBd5 Xo+A== X-Gm-Message-State: AMke39kSFqKNJA5B3mTSV7I8ixkO2ok00oXtldNiBy23Xd6n+sAvksYnVmkVUTSjvhQawHEE X-Received: by 10.99.102.134 with SMTP id a128mr10629196pgc.215.1489027351028; Wed, 08 Mar 2017 18:42:31 -0800 (PST) Date: Wed, 8 Mar 2017 18:42:29 -0800 From: Tycho Andersen To: Kees Cook Cc: "kernel-hardening@lists.openwall.com" Message-ID: <20170309024229.GA6638@hopstrocity> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [kernel-hardening] Ahoy! X-Virus-Scanned: ClamAV using ClamSMTP 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 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 From 96f0e3764bb3c764cd103b2829ab10176cf5b8c7 Mon Sep 17 00:00:00 2001 From: Tycho Andersen Date: Wed, 8 Mar 2017 16:19:26 -0800 Subject: [PATCH] security/Kconfig: further restrict HARDENED_USERCOPY It doesn't make sense to have HARDENED_USERCOPY when either /dev/kmem is enabled or /dev/mem can be used to read kernel memory. Signed-off-by: Tycho Andersen --- security/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/security/Kconfig b/security/Kconfig index d900f47..8ff32d3 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -137,6 +137,7 @@ config HARDENED_USERCOPY bool "Harden memory copies between kernel and userspace" depends on HAVE_ARCH_HARDENED_USERCOPY depends on HAVE_HARDENED_USERCOPY_ALLOCATOR + depends on !DEVKMEM && (!ARCH_HAS_DEVMEM_IS_ALLOWED || STRICT_DEVMEM) select BUG help This option checks for obviously wrong memory regions when -- 2.7.4