From owner-svn-src-all@FreeBSD.ORG Wed Jul 2 12:07:02 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 914A679E; Wed, 2 Jul 2014 12:07:02 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FF2A2D5C; Wed, 2 Jul 2014 12:07:01 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s62C6vN2082442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2014 15:06:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s62C6vN2082442 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s62C6vK5082441; Wed, 2 Jul 2014 15:06:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Jul 2014 15:06:57 +0300 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: svn commit: r268087 - head/sys/kern Message-ID: <20140702120657.GZ93733@kib.kiev.ua> References: <201407010921.s619LXHL063077@svn.freebsd.org> <20140701143238.GD26696@dft-labs.eu> <20140701180717.GS93733@kib.kiev.ua> <20140702084327.GH26696@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UpdKy7mRHviOTiWe" Content-Disposition: inline In-Reply-To: <20140702084327.GH26696@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "svn-src-head@freebsd.org" , Matthew Fleming , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Mateusz Guzik X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 12:07:02 -0000 --UpdKy7mRHviOTiWe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 02, 2014 at 10:43:28AM +0200, Mateusz Guzik wrote: > 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 danger= ous > > > 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 execut= e, > > > they could fork off after fdunshare() and then have a table shared wi= th > > > 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. > >=20 >=20 > There is no problem with threads using different struct proc. >=20 > 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. Thank you for clarifying, this is what I asked about. >=20 > > I somehow thought that you already ensured that this does not happen. >=20 > 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. >=20 > 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. >=20 > --=20 > Mateusz Guzik --UpdKy7mRHviOTiWe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTs/XgAAoJEJDCuSvBvK1B348P+gLP99dg3L51uBkamMnMxm0V kFTkebITM8LtOYoOiFqvLw/eeWJ6Bi//bgy8bGH7sw8HWpcfpRoTya3GF/zdS99C 46W8wtoXNvnFC05d4dbbFDQmKfihwy7AABhBGmPsK52MgOpytVbFAqR2P8FhYYvk eHoBMXPnUpqVOUQyp00tWpc24bYanXZTpQ88AUYT7fVuCE7BMxOlQVQhuV6RyVi2 vu4IxPPU2zZyjv+Kym9a7rRDvwYw5vaEEjZw9ir5foAFKP414klY0yPvHeCe8DGd UMuy5hJZWfxvY0S7t20PD3AJD7zttpcuFK9xi9VjpnQnnbx2P/+sR9mkA6HhNVe3 wyQsEPMLuZ+ZFPtE/+CnIQpGEzOBf4k7b0fqnWlECkQsZYM/P7u6aOXvHhf61U/p EK5zzpjT9hhej1A4XOvjZOfopz1RQmP+98KnU98mCjoDm0BDK2x35Y0s6Qam3uf5 SHlc7Iq5gioYRN1DOwm1OQupFWoDBemciSV8fcMHlKe36zA/23AGRetPyiofWPGR OyKRKt0hKgiXsECKTSRHIGxZMgF8e2kygoZWrS796CNzU+JIkjwgWM5jioh01ltm enCqRmM0tG2fSOiX7BBMjpX20Q3nFYzT2y19EStp10LObPg1k6HVGWpESuX+XVrg 8rCrNlC7Ac9+dYq/kV7m =9Mnb -----END PGP SIGNATURE----- --UpdKy7mRHviOTiWe--