Re: version of thread ids

[Marcus Brinkmann]

On Tue, May 20, 2003 at 11:32:57PM +0200, Niels Möller wrote:
> After thinking a little more, I'm still not convinced that this is a
> security issue.

Well, imagine the following:

* A user creates a lot of object handles to various system servers.
* He then execs a setuid application.
* The suid application happens to arrange it that it runs as root and
  execs again to a long running system server thread.

If you don't make sure that all object handles are destroyed, they are now
inherited by the long running system thread without any trace of the
original user who created them.  This is unacceptable.

The other issue is for server processes.  If you don't terminate existing
object handles to your server, and the server thread ids get reused, and the
exec'ed task happens to be a server, too, and the old clients get object
handles from the new server, object ids might be reused.  Then the client
has two handles which it thinks point to different objects, but which are
identical.  Furthermore, if it then processes a late notification of the old
server having been replaced, it can not tell anymore what to do.

Depending on the type of the server, the latter can have security
implications.  It is certainly a robustness issue, and it also might lead to
violations of the POSIX standard (like, for example, that you can decide
when the other end of a pipe was closed).

So, I think that the requirement is tighter than just "nice to have".  OTOH,
the second item above is just the user hurting himself (and other users who
might trust him), while the former is clearly a DoS attack on the system.

> And at last, and perhaps most important: When thinking about it as a
> robustness issue, rather than a security issue, this is just as
> applicable for ordinary, non-secure, exec.

That's right.
 
> So I'd suggest that changing the task id, and sending out death
> notifications for the old id, should be done as part of the ordinary
> non-secure exec procedure.

I tend to agree, in particular as this is one requirement for being able to
do exec without exec server ;)  I just wonder why we don't do this already,
I think that maybe it is because once you have the exec server, it has
certain flexibility advantages if you do the minimal changes to a task that
are required.  However, with a completely local exec this would be a
non-issue.

Thanks,
Marcus



-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/