Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753380Ab1CGO4z (ORCPT ); Mon, 7 Mar 2011 09:56:55 -0500 Received: from mx1.vsecurity.com ([209.67.252.12]:62767 "EHLO mx1.vsecurity.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750814Ab1CGO4y (ORCPT ); Mon, 7 Mar 2011 09:56:54 -0500 Subject: Re: [PATCH] Make /proc/slabinfo 0400 From: Dan Rosenberg To: Alan Cox Cc: "Ted Ts'o" , Matt Mackall , Pekka Enberg , Linus Torvalds , Dave Hansen , cl@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton In-Reply-To: <20110306131955.722d9bd5@lxorguk.ukuu.org.uk> References: <1299270709.3062.313.camel@calx> <1299271377.2071.1406.camel@dan> <1299272907.2071.1415.camel@dan> <1299275042.2071.1422.camel@dan> <1299279756.3062.361.camel@calx> <20110305162508.GA11120@thunk.org> <20110306131955.722d9bd5@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Mar 2011 09:56:48 -0500 Message-ID: <1299509808.2071.1445.camel@dan> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1884 Lines: 40 On Sun, 2011-03-06 at 13:19 +0000, Alan Cox wrote: > > If we had wrappers for the most common cases, then any cases that were > > left that used copy_from_user() explicitly could be flagged and > > checked by hand, since they would be exception, and not the rule. > > Arjan's copy_from_user validation code already does verification checks > on the copies using gcc magic. > > Some of the others might be useful - kmalloc_from_user() is a fairly > obvious interface, a copy_from_user_into() interface where you pass > the destination object and its actual length as well is mostly covered by > Arjan's stuff. > > Alan This is all worthwhile discussion, and a good implementation of these kinds of features is available as part of grsecurity (PAX_USERCOPY) - it provides additional bounds-checking for copy operations into both heap and stack buffers. Rather than reinventing the wheel, perhaps it would be a better use of time to extract this patch and make it suitable for inclusion. In the meantime, I'd like to get back to the original patch (make /proc/slabinfo 0400), and the subsequent followup patch (randomize free objects within a slab). While it's clear that these patches by themselves will not entirely prevent kernel heap exploits, they both seem to be sane improvements, won't significantly impact performance, and shouldn't be more than a very minor inconvenience to some small subset of normal users. In addition, the absence of these changes might undermine future hardening improvements (e.g. with a more hardened heap, the readability of /proc/slabinfo may be more necessary for successful exploitation). -Dan -- 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/