Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758025AbZFCQ04 (ORCPT ); Wed, 3 Jun 2009 12:26:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753293AbZFCQ0t (ORCPT ); Wed, 3 Jun 2009 12:26:49 -0400 Received: from oblivion.subreption.com ([66.240.236.22]:37779 "EHLO mail.subreption.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752088AbZFCQ0t (ORCPT ); Wed, 3 Jun 2009 12:26:49 -0400 Date: Wed, 3 Jun 2009 09:28:31 -0700 From: "Larry H." To: Christoph Lameter Cc: Stephen Smalley , Linus Torvalds , linux-mm@kvack.org, Alan Cox , Rik van Riel , linux-kernel@vger.kernel.org, pageexec@freemail.hu Subject: Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space) Message-ID: <20090603162831.GF6701@oblivion.subreption.com> References: <20090530192829.GK6535@oblivion.subreption.com> <20090530230022.GO6535@oblivion.subreption.com> <20090531022158.GA9033@oblivion.subreption.com> <20090602203405.GC6701@oblivion.subreption.com> <1244041914.12272.64.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Subreption LLC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2920 Lines: 69 On 11:41 Wed 03 Jun , Christoph Lameter wrote: > On Wed, 3 Jun 2009, Stephen Smalley wrote: > > > > If one remaps page 0 then the kernel checks for NULL pointers of various > > > flavors are bypassed and this may be exploited in various creative ways > > > to transfer data from kernel space to user space. > > > > > > Fix this by not allowing the remapping of page 0. Return -EINVAL if > > > such a mapping is attempted. Christopher, crippling the system is truly not the way to fix this. There are many legitimate users of private|fixed mappings at 0. In addition, if you want to go ahead and break POSIX, at least make sure your patch closes the loophole. Given these circumstances, are you proposing this over my patch? Linus already pointed out the main (functional) problem about it. It seems you are also confusing the issue, albeit already realized it can be a venue of attack, which is good. For instance, there are many scenarios in which a fixed mapping can be used in a non-zero address to abuse kernel flaws... your patch is useless against those. Please let me remind you that my original intent was to prevent kmalloc(0) from leading to potential NULL or offset-from-NULL access issues, and not deterring NULL pointer deferences in kernel-land which is a whole different thing (see PaX UDEREF for clues on this). > > > > You can already prevent unauthorized processes from mapping low memory > > via the existing mmap_min_addr setting, configurable via > > SECURITY_DEFAULT_MMAP_MIN_ADDR or /proc/sys/vm/mmap_min_addr. Then > > cap_file_mmap() or selinux_file_mmap() will apply a check when a process > > attempts to map memory below that address. If SELinux isn't present, that's not useful. If mmap_min_addr is enabled, that still won't solve what my original, utterly simple patch fixes. The patch provides a no-impact, clean solution to prevent kmalloc(0) situations from becoming a security hazard. Nothing else. If you want to solve NULL/ptr deference abuse from userland, you better start thinking about separating kernel virtual address space from userland's, with the performance impact that implies. Few architectures provide this capability without performance hit, and x86 ain't one of them. > mmap_min_addr depends on CONFIG_SECURITY which establishes various > strangely complex "security models". > > The system needs to be secure by default. Correct, so what was wrong with my patch again? That the original two line change was written by the PaX team? Come on chap, It's not like you will lose your bragging rights among your peers for admitting that I was right. Just this one time. I won't tell anybody. Promise. Larry -- 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/