Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755664Ab2HTVsm (ORCPT ); Mon, 20 Aug 2012 17:48:42 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:39491 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643Ab2HTVsi (ORCPT ); Mon, 20 Aug 2012 17:48:38 -0400 MIME-Version: 1.0 In-Reply-To: <20120820180037.GV4232@outflux.net> References: <20120820180037.GV4232@outflux.net> Date: Mon, 20 Aug 2012 23:48:37 +0200 Message-ID: Subject: Re: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect From: Ard Biesheuvel To: Kees Cook Cc: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1206 Lines: 34 > This seems like a good idea to me. It would allow more than just the > loader to harden userspace allocations. It's a more direct version of > PaX's "MPROTECT" feature[1]. That feature hardens existing loaders, > but doesn't play nice with JITs (like Java), but this lets a loader > (or JIT) opt-in to the protection and have some direct control over it. > If desired, additional restrictions can be imposed by using the security framework, e.g,, disallow non-final r-x mappings. > It seems like there needs to be a sensible way to detect that this flag is > available, though. > I am open for suggestions to address this. Our particular implementation of the loader (on an embedded system) tries to set it on the first mmap invocation, and stops trying if it fails. Not the most elegant approach, I know ... -- Ard. > -Kees > > [1] http://pax.grsecurity.net/docs/mprotect.txt > > -- > Kees Cook @outflux.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/