Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752177Ab0AAXTB (ORCPT ); Fri, 1 Jan 2010 18:19:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751740Ab0AAXS6 (ORCPT ); Fri, 1 Jan 2010 18:18:58 -0500 Received: from smtp110.prem.mail.sp1.yahoo.com ([98.136.44.55]:34847 "HELO smtp110.prem.mail.sp1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751360Ab0AAXS5 (ORCPT ); Fri, 1 Jan 2010 18:18:57 -0500 X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- X-YMail-OSG: 4P5IkxkVM1nezXd_XwDE_eiezgugkzP6q.C82Ic6EXqUD22jfqxiPl6D5.wd9YV3PCQoNfOHNIzgbD5GRvvTKcYEv.tY_ZmHwBOfjK.gtrRO4nLbY13_TbQGhVJ00eAj7n2nvXIE2sXNzaYyiinFBHnqcT1eCZPuUoju4fbf_LXCZ8bA3XCx0ALKZ8tgvBmxNDL6PcA66QlCOlx7xb.dnG2rbDGViDByZc.17HK3thztYcybtNVKmvQza08LP8Lfob1sDjbRsJkoIybmhUk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B3E82D9.7050708@schaufler-ca.com> Date: Fri, 01 Jan 2010 15:18:49 -0800 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alan Cox CC: "Eric W. Biederman" , "Andrew G. Morgan" , "Serge E. Hallyn" , Bryan Donlan , 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 , Pavel Machek , Al Viro , Casey Schaufler Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges References: <551280e50912300652r1007dee0j8de750bf33af9b3c@mail.gmail.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> <20091231175257.GA7210@us.ibm.com> <551280e50912311020x2bdc5b1o699a601f67b91662@mail.gmail.com> <20100101144300.023f47a5@lxorguk.ukuu.org.uk> <4B3E6A8B.7060705@schaufler-ca.com> <20100101223919.00b60938@lxorguk.ukuu.org.uk> In-Reply-To: <20100101223919.00b60938@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3871 Lines: 93 Alan Cox wrote: >> Sure. Not that it would be hard to do so. And have a careful look >> at the recent discussions on checkpoint/restart. >> > > Indeed the LSM "no removal of restrictions" is simply a policy decision > that came about early on - no reason to assume it is a right policy > decision if it can be shown otherwise. > > >> Application developers want systems that work the way the man pages >> say they work. They do not want additional or conditional restrictions. >> > > I disagree somewhat. They want them to work they way they did when they > tested it and the way they believe it works. Most of them never read the > manual or the standards documents. Take a look at the whining when stat() > size data stopped happening by chance to reflect bytes queued in a pipe. > Yeah, the good ones do at least try to consider both the documented and traditional behaviors. > >> How many commercial applications start their installation instructions >> with "disable SELinux"? (Hint: lots) >> > > And I am sure it time the sequence is going to go "Why did your business > web site get taken out for four weeks" / "We disabled SELinux as the app > said" / "Sue the app vendor" > You have to demonstrate that SELinux would be prevented the outage. Not so easy. > If you tell someone to disable the safety systems on a crane you get > prosecuted. > If you survive. The difference is the obvious physical harm. >>> I am sick and fed up with the conversations that go: >>> - I want to do X. >>> - X has been implemented. >>> - Sorry I can't use X as implemented because you have to be root to >>> use X. >>> >>> >> Exasperated sigh. Privileged operations are privileged for a reason, >> not always a good reason mind you, but a reason nonetheless. If >> your application developers want to do things that require privilege >> you need to teach them how to write privileged programs safely. We've >> been working on exotic variations of system controls for decades >> and in the end your programmers have to write decent code because >> we haven't yet come up with a way to make all the things that people >> want their programs to do safe. >> > > A useful question here would be to ask what it means to containerise > security. At the moment you can do this with virtual machines and while > its a nasty managability/security trade off the choice is there for the > most part and you can point at things like the amazon cloud as working > examples. We don't really have the notion of what setuidness means within > a container or how you can create a container which has its own internal > setuid, security model, LSM and 'superuser' but can't mess anything else > up, only for a virtual machine. > I've said it many times. Separation is easy, sharing is hard. Isolated machines, dedicated machines, virtual machines, containers, Mandatory Access Control, and Discretionary Access Control and all means for separation. Each has mechanisms to allow controlled sharing. The setuid mechanism is primarily a DAC mechanism to allow Fred to give Barney access to resources that Fred has access to that Barney does not. Overloading the user ID with the root privilege model offered advantages in the days of computers with 64k of RAM, and we have that legacy to deal with. This tends to obfuscate the value of setuid for DAC. > [I'll note Hurd tried to explore this area in part because Hurd was > designed around a model that history proved bogus - a big computer being > equitably shared with all the power possible but without messing up other > users] > > 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/