From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [RFC][PATCH] Unprivileged: Disable acquisition of privileges Date: Wed, 30 Dec 2009 04:47:02 -0800 Message-ID: References: <20091229050114.GC14362@heat> <3e8340490912290805s103fb789y13acea4a84669b20@mail.gmail.com> <20091229211139.0732a0c1@lxorguk.ukuu.org.uk> <20091229223631.GB22578@us.ibm.com> <3e8340490912291954v5a837a26p64bd776102d281d7@mail.gmail.com> <3e8340490912292057g3e87eaabn115f85b78af2b08c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Serge E. Hallyn" , Alan Cox , 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 , To: Bryan Donlan Return-path: In-Reply-To: <3e8340490912292057g3e87eaabn115f85b78af2b08c@mail.gmail.com> (Bryan Donlan's message of "Tue\, 29 Dec 2009 23\:57\:50 -0500") Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Bryan Donlan writes: > On Tue, Dec 29, 2009 at 11:33 PM, Eric W. Biederman > wrote: >> Bryan Donlan writes: >> >>> Is this sufficient for other security models such as selinux or >>> TOMOYO? Can processes in these models gain privileges through means >>> not restricted here? >> >> The LSM is primarily about returning -EPERM more often. >> Except for the prctl and the capability hooks I am not aware >> of anywhere a LSM can increase a processes capabilities. > > I'm more concerned about a case where a privilege that the LSM > currently denies is lifted by execing some executable - this is still > an increase in privilege, even though the LSM only adds additional > restrictions. That is: > > 1) Initial state: LSM denies access to /somefile (although normal > POSIX permissions would permit access) > 2) Disable capability-gaining > 3) Disable network access with proposed API > 4) Exec some application, which is labeled in a way that permits > access to /somefile > 5) Application fails to access the network, then does something to /somefile > > I'm not entirely sure if step 4) can happen in any of the currently > existing LSMs - if it's not possible to gain privileges in them via a > suid-like mechanism, this isn't a problem, but it's something that > needs to be checked for. A reasonable concern. When the glitches get worked out of this patch I intend to allow much more dangerous things like unprivileged unsharing of all of the namespaces, and unprivileged mounts. It appears I missed a place where MNT_NOSUID was handled in selinux. So I will be adding a bprm->nosuid field so I don't have to duplicate the MNT_NOSUID check everywhere it is used. I don't understand TOMOYO I think it is file based access control, which suggests there is not a suid like mechanism. Smack and selinux are label based. Selinux at least can switch labels on exec, but it handles NOSUID already. Looking a little farther if I assume that lsm implementations that implement the set_creds hook need attention. Only selinux has an interesting set_creds implementation and it handles nosuid already. So I think we are ok. Eric