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 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. Thank you for clarifying, this is what I asked about.
> > > 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>
pgpJxK3FTX6jJ.pgp
Description: PGP signature
