Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752914AbZLaRxI (ORCPT ); Thu, 31 Dec 2009 12:53:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752882AbZLaRxH (ORCPT ); Thu, 31 Dec 2009 12:53:07 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.142]:44978 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752886AbZLaRxD (ORCPT ); Thu, 31 Dec 2009 12:53:03 -0500 Date: Thu, 31 Dec 2009 11:52:57 -0600 From: "Serge E. Hallyn" To: Alan Cox Cc: Bryan Donlan , "Eric W. Biederman" , "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 , =?iso-8859-1?Q?Am=E9rico?= Wang , Tetsuo Handa , Samir Bellabes , Casey Schaufler , Pavel Machek , Al Viro Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges Message-ID: <20091231175257.GA7210@us.ibm.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> <20091231173334.5e3d7557@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091231173334.5e3d7557@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4433 Lines: 104 Quoting Alan Cox (alan@lxorguk.ukuu.org.uk): > > I see this as being a security-model agnostic API - the reason being, > > Thats what everyone else says about their security model too LOL > > 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. That's exactly what we're trying to avoid :) But I'm personally not against making this an LSM. As you say: > 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 Yes, and in particular, we'll need to do something about data ->security annotations, since, if we make this an LSM, then we can't use a per-thread flag. This feature is used during exec and ptrace, not on hot-paths, so dereferencing task->security would be fine. But finding a way to multiplex task->security so it can be used by Eric's nosuid lsm, Michael's disablenetwork LSM, and SELinux/smack/apparmor, that will likely take months, and, history shows, may never happen. > 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. Eric, the thing is, once an API goes upstream, we can't change it, but in contrast we can change how task->security is used at any time. So I'd suggest just adding #ifdef CONFIG_SECURITY_NOSUID short nosuid; #endif or something like it next to the #ifdef CONFIG_SECURITY void *security; #endif in struct cred and doing that for a first go. You could share that field with Michael's disablenetwork, or not if you prefer - either way, it keeps you and SELinux out of each other's ways. -serge -- 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/