Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752846AbZLaRcX (ORCPT ); Thu, 31 Dec 2009 12:32:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752722AbZLaRcW (ORCPT ); Thu, 31 Dec 2009 12:32:22 -0500 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:60486 "EHLO www.etchedpixels.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752690AbZLaRcV (ORCPT ); Thu, 31 Dec 2009 12:32:21 -0500 Date: Thu, 31 Dec 2009 17:33:34 +0000 From: Alan Cox To: Bryan Donlan Cc: "Eric W. Biederman" , "Serge E. Hallyn" , "Andrew G. Morgan" , Benny Amorsen , Michael Stone , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-security-module@vger.kernel.org, Andi Kleen , David Lang , Oliver Hartkopp , Herbert Xu , Valdis Kletnieks , Evgeniy Polyakov , "C. Scott Ananian" , James Morris , Bernie Innocenti , Mark Seaborn , Randy Dunlap , =?UTF-8?B?QW3DqXJpY28=?= Wang , Tetsuo Handa , Samir Bellabes , Casey Schaufler , Pavel Machek , Al Viro Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges Message-ID: <20091231173334.5e3d7557@lxorguk.ukuu.org.uk> In-Reply-To: <3e8340490912301844p4fddaf57ke58ceeba9582e0fa@mail.gmail.com> References: <551280e50912300652r1007dee0j8de750bf33af9b3c@mail.gmail.com> <20091230183513.GC14493@us.ibm.com> <20091230201712.GA23999@us.ibm.com> <20091230212931.233003b9@lxorguk.ukuu.org.uk> <20091230230042.5d2e78ac@lxorguk.ukuu.org.uk> <3e8340490912301844p4fddaf57ke58ceeba9582e0fa@mail.gmail.com> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3179 Lines: 68 > I see this as being a security-model agnostic API - the reason being, Thats what everyone else says about their security model too > the application is specifying a policy for itself that has meaning in > all existing security models, and which does not require administrator > intervention to configure. Rather than reimplementing this for each > security model, it's far better to do it just once. Moreover, by > having a single, common API, the application can state the general > policy "I will never need to gain priviliges over exec" without > needing to know what LSM is in use. So it can sit in the security hooks and stack. > The future goal of this API is to allow us to relax restrictions on > creating new namespaces, chrooting, and otherwise altering the task's > environment in ways that may confuse privileged applications. Since All of which are security policy, general purpose and frequently part of the main LSM module loaded - in other words it's nothing of the sort when it comes to being separate. Its just another magic interface hook, and as I think the history of capability stuff in kernel shows it doesn't work that way. > security hooks are all about making the existing security restrictions > _stricter_, it's not easy to later relax these using the security hook > model. And once we put in the general requirement that "this task > shall never gain privilege", it should be safe to relax these > restrictions for _all_ security models. In which case the hooks can be tweaked. It's an interface it can be tuned - and has been - eg for Tomoyo. > In short, this is something which is meaningful for all existing LSMs But is it - and if its combined with 500 other similar hooks and a set of system policies can you even work out the result ? > restrictions later, it doesn't make sense to put it in a LSM as they > stand now. And it certainly doesn't make sense to add this and the several hundred other variants of this "can't open sockets, can't mount, can't this, can't that ...." stuff continually being suggested by randomly extending other unrelated interfaces. Look up the sendmail security archive and you'll even find examples where enforcing extra security on setuid *caused* security problems to show up that were basically impossible to hit otherwise. We have a security system, with a set of interfaces for attaching security models, please stop trying to go round the back of the kernel design because you can't be bothered to do the required work to do the job right and would rather add more unmaintainable crap all over the place. Yes it might mean the hooks need tweaking, yes it probably means the people who want these need to do some trivial stacking work, but if as many people are actually really interested as are having random 'lets add a button to disable reading serial ports on wednesday' ideas there should be no shortage of people to do the job right. Alan -- 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/