Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751982AbZLaVqc (ORCPT ); Thu, 31 Dec 2009 16:46:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751810AbZLaVqb (ORCPT ); Thu, 31 Dec 2009 16:46:31 -0500 Received: from e38.co.us.ibm.com ([32.97.110.159]:33967 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751594AbZLaVqa (ORCPT ); Thu, 31 Dec 2009 16:46:30 -0500 Date: Thu, 31 Dec 2009 15:46:21 -0600 From: "Serge E. Hallyn" To: "Eric W. Biederman" Cc: "Andrew G. Morgan" , Alan Cox , 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 , Casey Schaufler , Pavel Machek , Al Viro Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges Message-ID: <20091231214621.GA14116@us.ibm.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 2321 Lines: 57 Quoting Eric W. Biederman (ebiederm@xmission.com): > "Andrew G. Morgan" writes: > > > Since there is already independent support for disabling file > > capabilities (the privilege escalation part), I see these two > > mechanisms as separable. > > I guess there is something that resembles support for disabling > privilege escalation. The problem is that it requires privilege to > use it. > > I have no problem with expressing this in a fine grained manner internally > to the kernel but the user space interface needs to be atomic so that > we can enable this all without privilege. > > Further I may be off but I think the implementation would be more > challenging than what I have already posted. That doesn't mean it > won't be more useful long term. > > Eric Right, what we can currently do with capabilities is: 1. drop capabilities from the bounding set. This is privileged because it is fine-grained, and can trick capability-unaware privileged programs. 2. drop CAP_SETUID from pP, pI, and the bounding set, to prevent any future setuids. Privileged for the same reason as 1. 3. set SECURE_NOROOT and SECURE_NOSUIDFIXUP, so that uid 0 won't automatically get privileges. It doesn't provide a way for stopping setuid on setuid binaries, though, and as we've previously noted, while we'd *like* to say that uids and privileges can be treated separately, in reality the unprivileged root user still owns most of the system. So we should also provide the per-task nosuid bit, meaning do not change uid for a setuid binary. This could be treated as another securebit, SECURE_NOSUID So if the capabilities module supports a special prctl(PR_SET_NOSUID) which at the same time completely empties pP, pE, pI, and the bounding set, and sets the SECURE_NOSUID securebit, that should be safe for an unprivileged user. (There is no need for SECURE_NOROOT and SECURE_NOSUIDFIXUP in that case obviously). Or, it could set SECURE_NOSUID|SECURE_NOROOT|SECURE_NOSUID_FIXUP (and the corresponding _LOCKED bits). -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/