Date: Wed, 2 Jul 2014 10:43:28 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Konstantin Belousov <kostikbel@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: <20140702084327.GH26696@dft-labs.eu> In-Reply-To: <20140701180717.GS93733@kib.kiev.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140702084327.GH26696>