Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752898AbZLaSdG (ORCPT ); Thu, 31 Dec 2009 13:33:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752649AbZLaSdF (ORCPT ); Thu, 31 Dec 2009 13:33:05 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:39083 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751339AbZLaSdD (ORCPT ); Thu, 31 Dec 2009 13:33:03 -0500 To: "Andrew G. Morgan" Cc: "Serge E. Hallyn" , 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 , =?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: <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> From: ebiederm@xmission.com (Eric W. Biederman) Date: Thu, 31 Dec 2009 10:32:47 -0800 In-Reply-To: <551280e50912311020x2bdc5b1o699a601f67b91662@mail.gmail.com> (Andrew G. Morgan's message of "Thu\, 31 Dec 2009 10\:20\:18 -0800") 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: 1458 Lines: 38 "Andrew G. Morgan" writes: > Why not implement this as another securebit? So far as I can see the > whole thing can be implemented in the capability LSM. > > What is less clear to me is whether per-process 'disabling of setuid > bits on files' should force mandatory disabling of file capabilities. > It seems as if disabling the transition of one luser to another luser > through a setuid executable is something distinct from privilege > escalation. > > Since there is already independent support for disabling file > capabilities (the privilege escalation part), I see these two > mechanisms as separable. The goal is to disable privilege escalation. The anatomy of the sendmail capabilities bug as I understand it was: - unprivileged process took action to prevent gaining a capability. - exec'd suid sendmail. - sendmail took action as root because it could not become someone else. I would like to trivially stop that entire class of exploit by making execing a suid ( or equivalent ) executable impossible. Once that hole is closed we can enable things like chroot without privilege. If there is a way to express this with capabilities today I would be more than happy to. 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/