Date: Wed, 2 Jul 2014 15:06:57 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Mateusz Guzik <mjguzik@gmail.com> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Matthew Fleming <mdf@FreeBSD.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Mateusz Guzik <mjg@freebsd.org> Subject: Re: svn commit: r268087 - head/sys/kern Message-ID: <20140702120657.GZ93733@kib.kiev.ua> In-Reply-To: <20140702084327.GH26696@dft-labs.eu> References: <201407010921.s619LXHL063077@svn.freebsd.org> <CAMBSHm-T1mjXXevOe=EMy2WuMsXE6Y=VoFBD-4mN_er0PB2b7w@mail.gmail.com> <20140701143238.GD26696@dft-labs.eu> <20140701180717.GS93733@kib.kiev.ua> <20140702084327.GH26696@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <mjguzik gmail.com> --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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140702120657.GZ93733>