Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756666Ab2JCWT2 (ORCPT ); Wed, 3 Oct 2012 18:19:28 -0400 Received: from mail-ie0-f174.google.com ([209.85.223.174]:34536 "EHLO mail-ie0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755342Ab2JCWT1 (ORCPT ); Wed, 3 Oct 2012 18:19:27 -0400 MIME-Version: 1.0 In-Reply-To: <20121003141804.f9896690.akpm@linux-foundation.org> References: <20120820180037.GV4232@outflux.net> <20121002153841.a03ad73b.akpm@linux-foundation.org> <506C4F29.4090303@gmail.com> <20121003141804.f9896690.akpm@linux-foundation.org> Date: Wed, 3 Oct 2012 15:19:26 -0700 X-Google-Sender-Auth: uIaut_B1qTZhPsThDe4Kh_NfxiI Message-ID: Subject: Re: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect From: Kees Cook To: Andrew Morton Cc: Ard Biesheuvel , Hugh Dickins , linux-kernel@vger.kernel.org, pageexec@freemail.hu, Roland McGrath Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2097 Lines: 52 On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton wrote: > On Wed, 03 Oct 2012 16:43:53 +0200 > Ard Biesheuvel wrote: > >> This patch adds support for the PROT_FINAL flag to >> the mmap() and mprotect() syscalls. >> >> The PROT_FINAL flag indicates that the requested set >> of protection bits should be final, i.e., it shall >> not be allowed for a subsequent mprotect call to >> set protection bits that were not set already. >> >> This is mainly intended for the dynamic linker, >> which sets up the address space on behalf of >> dynamic binaries. By using this flag, it can >> prevent exploited code from remapping read-only >> executable code or data sections read-write. > > Again: has this proposal been reviewed by the glibc maintainers? If > so, what was their position on it? Ard have you talked with them? I would expect it would be welcomed. Roland, do you know who would be the right person to ask about this for glibc? (patch: https://lkml.org/lkml/2012/10/3/262) > Also, you earlier stated that "It's a more direct version of PaX's > "MPROTECT" feature[1]". This is useful information. Please update the > changelog to describe that PaX feature and to describe the difference > between the two, and the reasons for that difference. AIUI, it's much more aggressive. It tries to protect all processes automatically (rather than this which is at the request of the process) and gets in the way of things like Java that expect to be able to do w+x mappings. > It sounds as though the PaX developers could provide useful review > input on this proposal. Do they know about it? If so, what is their > position? I'd rather not speak for them, but I understood it to be along the lines of "that's nice, we'll keep ours." :) (Now added to CC.) -Kees -- Kees Cook Chrome OS Security -- 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/