From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964986Ab1GMGcI (ORCPT ); Wed, 13 Jul 2011 02:32:08 -0400 Received: from mother.openwall.net ([195.42.179.200]:54579 "HELO mother.openwall.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S964930Ab1GMGcH (ORCPT ); Wed, 13 Jul 2011 02:32:07 -0400 Date: Wed, 13 Jul 2011 10:31:42 +0400 From: Solar Designer To: NeilBrown Cc: Linus Torvalds , Vasiliy Kulikov , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Andrew Morton , "David S. Miller" , kernel-hardening@lists.openwall.com, Jiri Slaby , James Morris , Alexander Viro , linux-fsdevel@vger.kernel.org, KOSAKI Motohiro Subject: Re: [PATCH] move RLIMIT_NPROC check from set_user() to do_execve_common() Message-ID: <20110713063142.GA19976@openwall.com> References: <20110612130953.GA3709@albatros> <20110706173631.GA5431@albatros> <20110706185932.GB3299@albatros> <20110707075610.GA3411@albatros> <20110707081930.GA4393@albatros> <20110712132723.GA3193@albatros> <20110713091408.0d456352@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110713091408.0d456352@notabene.brown> User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus, Neil, Motohiro - thank you for your comments! On Wed, Jul 13, 2011 at 09:14:08AM +1000, NeilBrown wrote: > The contrast is really "failing when trying to use reduced privileges is > safer than failing to reduce privileges - if the reduced privileges are not > available". Right. > Note that there is room for a race that could have unintended consequences. > > Between the 'setuid(ordinary-user)' and a subsequent 'exit()' after execve() > has failed, any other process owned by the same user (and we know where are > quite a few) would fail an execve() where it really should not. It is not obvious to me that this is unintended, and that dealing with it in some way makes much of a difference. (Also, it's not exactly "any other process owned by the same user" - this only affects processes that also run with similar or lower RLIMIT_NPROC. So, for example, if a web server is set to use RLIMIT_NPROC of 30, but interactive logins use 40, then the latter may succeed and allow for shell commands to succeed. This is actually a common combination of settings that we've been using on some systems for years.) > I think it would be safer to add a test for PF_SUPERPRIV and PF_FORKNOEXEC > in current->flags and only fail the execve if both are set. > i.e. > (current->flags & (PF_SUPERPRIV|PF_FORKNOEXEC)) == (PF_SUPERPRIV|PF_FORKNOEXEC) > > That should narrow it down to only failing in the particular case that we are > interested in. That's a curious idea, and apparently this is what NetBSD does, but unfortunately it does not match a common use case that we are interested in - specifically, Apache with suEXEC (which is part of the Apache distribution). Here's what happens: httpd runs as non-root. It forks, execs suexec (SUID root). suexec calls setuid() to the target non-root user and execve() on the CGI program (script, interpreter, whatever). Notice how the fork() and the setuid() are separated by execve() of suexec itself. Thus, we need to apply the RLIMIT_NPROC check on execve() unconditionally (well, we may allow processes with CAP_SYS_RESOURCE to proceed despite of the failed check, like it's done in -ow patches), or at least not on the condition proposed above. Alexander