svn commit: r268087 - head/sys/kern

[Konstantin Belousov]

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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140702/dc806be7/attachment.sig>