From owner-svn-src-head@FreeBSD.ORG Wed Jul 2 08:43:35 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 824D5284; Wed, 2 Jul 2014 08:43:35 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EB7428EE; Wed, 2 Jul 2014 08:43:34 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id z12so10673644wgg.13 for ; Wed, 02 Jul 2014 01:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=AseMYvzBW7vig6STSeGHU1WEp59q7CwhDpHJqvqbtvw=; b=xy0osFEwaRFDZyyCicHJW8zdE8BckLnuehHXFdQq6KwvCJ9ZKeIsvp23/Nu3hSe6g7 brbnalYEzLvh+ZgxSpgrEYiaPxBOyVPRSTwhd9weGj09IzvhGajhfLYWVdvW7xp7OqJb +c2RI72dks3o6DchNfrVbkP5FTH0UO+a1CMGDReYqy6hJNqYezw5x7tg2L2uZXzFMlkF ht8HAINZwBkTp633xJdkIl8YxSnjZi4XXEUiz5B63/KdRwG0Cnq8/OJEpY08LZzdsOZS 0yfC4EcBz5Z559NoproypIYYwIIwFYTBj1Euw+D1HGsTFJo8zAtCI79t9zAz0uzlGcoK tXYg== X-Received: by 10.180.108.103 with SMTP id hj7mr42680553wib.82.1404290611108; Wed, 02 Jul 2014 01:43:31 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id lo18sm52820942wic.1.2014.07.02.01.43.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 02 Jul 2014 01:43:30 -0700 (PDT) Date: Wed, 2 Jul 2014 10:43:28 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: svn commit: r268087 - head/sys/kern Message-ID: <20140702084327.GH26696@dft-labs.eu> References: <201407010921.s619LXHL063077@svn.freebsd.org> <20140701143238.GD26696@dft-labs.eu> <20140701180717.GS93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140701180717.GS93733@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "svn-src-head@freebsd.org" , Matthew Fleming , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Mateusz Guzik X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 08:43:35 -0000 On Tue, Jul 01, 2014 at 09:07:17PM +0300, Konstantin Belousov wrote: > On Tue, Jul 01, 2014 at 04:32:38PM +0200, Mateusz Guzik wrote: > > All other threads have to be blocked, otherwise there are more dangerous > > races - for instance we support sharing file descriptor tables, so > > execve makes sure to unshare the table (fdunshare()), which is > > especially important for suid binaries. If other threads could execute, > > they could fork off after fdunshare() and then have a table shared with > > now privileged process. > In fact, other threads can execute, just not in this process. > If rfork(2) was used, then the filedesc table can be shared, but > not the address space. > There is no problem with threads using different struct proc. If there are rforked threads with shared fdatble, refcount is > 1 and fdunshare() copies the table. If refcount is 1, there is no rforked thread which could modify the table. Either way, execing thread is safe in that regard. > I somehow thought that you already ensured that this does not happen. My guess is you are referring to reading the table by kern_proc_filedesc_out & friends when locks are dropped after permission checks and nothing prevents target process from execing a suid binary and leaking information if fdtable is read late enough. This is not fixed yet. I had a tour over the kernel and several other p_candebug users have this problem since they just PHOLD and drop locks. Most PHOLD users need to also block execve, this requires some more time to make sure all holes are spotted. -- Mateusz Guzik