Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965526Ab2JDIVE (ORCPT ); Thu, 4 Oct 2012 04:21:04 -0400 Received: from smtp1.uu.se ([130.238.7.54]:34126 "EHLO smtp1.uu.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932554Ab2JDIVA (ORCPT ); Thu, 4 Oct 2012 04:21:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20589.18026.809848.345606@pilspetsen.it.uu.se> Date: Thu, 4 Oct 2012 10:18:50 +0200 From: Mikael Pettersson To: Ard Biesheuvel Cc: Hugh Dickins , Andrew Morton , Kees Cook , linux-kernel@vger.kernel.org Subject: Re: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect In-Reply-To: <506C4F29.4090303@gmail.com> References: <20120820180037.GV4232@outflux.net> <20121002153841.a03ad73b.akpm@linux-foundation.org> <506C4F29.4090303@gmail.com> X-Mailer: VM 7.17 under Emacs 20.7.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1780 Lines: 42 Ard Biesheuvel writes: > 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. I can see why you might think this is a good idea, but I don't like it for several reasons: - If .text is mapped non-writable and final, how would a debugger (or any ptrace-using monitor-like application) plant a large number of breakpoints in a target process? Breakpoint registers aren't enough because (a) they're few in number, and (b) not all CPUs have them. - You're proposing to give one component (the dynamic linker/ loader) absolute power to impose new policies on all applications. How would an application that _deliberately_ does something the new policies don't allow tell the dynamic linker or kernel to get out of its way? This clearly changes the de-facto ABIs, and as such I think it needs much more detailed analysis than what you've done here. At the very least I think this change should be opt-in, but that would require a kernel option or sysctl, or some config file for the user-space dynamic linker/loader. -- 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/