Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757382AbZFCQp1 (ORCPT ); Wed, 3 Jun 2009 12:45:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754805AbZFCQpQ (ORCPT ); Wed, 3 Jun 2009 12:45:16 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:36432 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753390AbZFCQpP (ORCPT ); Wed, 3 Jun 2009 12:45:15 -0400 Date: Wed, 3 Jun 2009 09:44:30 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Eric Paris cc: Christoph Lameter , "Larry H." , 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) In-Reply-To: <7e0fb38c0906030932o28d5c963y8059672e5c2c7ecf@mail.gmail.com> Message-ID: References: <20090530192829.GK6535@oblivion.subreption.com> <20090531022158.GA9033@oblivion.subreption.com> <20090602203405.GC6701@oblivion.subreption.com> <7e0fb38c0906030922u3af8c2abi8a2cfdcd66151a5a@mail.gmail.com> <7e0fb38c0906030932o28d5c963y8059672e5c2c7ecf@mail.gmail.com> User-Agent: Alpine 2.01 (LFD 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1681 Lines: 45 On Wed, 3 Jun 2009, Eric Paris wrote: > > > > We probably should, since the "capability" security version should > > generally essentially emulate the regular non-SECURITY case for root. > > Will poke/patch this afternoon. Btw, a perhaps more interesting case would be to _really_ make the "!SECURITY" case just be essentially a hardcoding of the capability case. Right now the Kconfig option is actually actively misleading, because it says that "if you don't enable SECURITY, the default security model will be used". And that's not automatically true, as shown by this example. You can easily get out of sync between security/capability.c and the hardcoded non-security rules in include/linux/security.h. Wouldn't it be kind of nice if the "security/capability.c" file would work something like - make the meat of it just a header file ("") - if !SECURITY, the functions become inline functions named "security_xyz()", and the header file gets included from - if SECURITY, the functions become static functions named "cap_xyz()", and get included from security/capability.c. IOW, we'd _guarantee_ that the !SECURITY case is exactly the same as the SECURITY+default capabilities case, because we'd be sharing the source code. Hmm? Wouldn't that be a nice way to always avoid the potential "oops, !SECURITY has different semantics than intended". Linus -- 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/