Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752038AbZLaI6S (ORCPT ); Thu, 31 Dec 2009 03:58:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751443AbZLaI6R (ORCPT ); Thu, 31 Dec 2009 03:58:17 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:50925 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751220AbZLaI6Q (ORCPT ); Thu, 31 Dec 2009 03:58:16 -0500 To: Alan Cox Cc: "Serge E. Hallyn" , "Andrew G. Morgan" , 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 , =?utf-8?Q?Am=C3=A9rico?= Wang , Tetsuo Handa , Samir Bellabes , Casey Schaufler , Pavel Machek , Al Viro Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges References: <20091229223631.GB22578@us.ibm.com> <3e8340490912291954v5a837a26p64bd776102d281d7@mail.gmail.com> <3e8340490912292057g3e87eaabn115f85b78af2b08c@mail.gmail.com> <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> From: ebiederm@xmission.com (Eric W. Biederman) Date: Thu, 31 Dec 2009 00:57:49 -0800 In-Reply-To: <20091230230042.5d2e78ac@lxorguk.ukuu.org.uk> (Alan Cox's message of "Wed\, 30 Dec 2009 23\:00\:42 +0000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-XM-SPF: eid=;;;mid=;;;hst=in01.mta.xmission.com;;;ip=76.21.114.89;;;frm=ebiederm@xmission.com;;;spf=neutral X-SA-Exim-Connect-IP: 76.21.114.89 X-SA-Exim-Mail-From: ebiederm@xmission.com X-SA-Exim-Scanned: No (on in01.mta.xmission.com); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2173 Lines: 52 Alan Cox writes: > On Wed, 30 Dec 2009 13:36:57 -0800 > ebiederm@xmission.com (Eric W. Biederman) wrote: > >> Alan Cox writes: >> >> >> Added bprm->nosuid to make remove the need to add >> >> duplicate error prone checks. This ensures that >> >> the disabling of suid executables is exactly the >> >> same as MNT_NOSUID. >> > >> > Another fine example of why we have security hooks so that we don't get a >> > kernel full of other "random security idea of the day" hacks. >> >> Well it comes from plan 9. Except there they just simply did not >> implement suid. What causes you to think dropping the ability >> to execute suid executables is a random security idea of the day? > > Well to be fair its random regurgitated security idea of every year or > two. > > More to the point - we have security_* hooks so this kind of continuous > security proposal turdstream can stay out of the main part of the kernel. > > Cleaning up the mechanism by which NOSUID is handled in kernel seems a > good idea. Adding wacky new prctls and gunk for it doesn't, and belongs > in whatever security model you are using via the security hooks. I am more than happy to make this a proper system call, instead of a prctl. The way this code is evolving that seems to be the clean way to handle this. No point in hiding the functionality away in a corner in shame. In my book SUID applications are the root of all evil. They are exploitable if you twist their environment in a way they have not hardened themselves against, and simply supporting them prevents a lot of good features from being used by ordinary applications. To get SUID out of my way I have to do something. A disable SUID from this process and it's children is a simple and direct way there. My other path is much more complicated. As this also has security related uses it seems even better as a feature. Eric -- 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/