l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: version of thread ids


From: Marcus Brinkmann
Subject: Re: version of thread ids
Date: Wed, 21 May 2003 13:28:27 +0200
User-agent: Mutt/1.5.3i

On Wed, May 21, 2003 at 08:54:19AM +0200, Niels Möller wrote:
> Marcus Brinkmann <address@hidden> writes:
> 
> > There is a difference between an object handle wrapped into an fd and a
> > stray object handle that is lost and not accounted for anymore.  The first
> > one is just an extra object the suid app can deal with, the other is a
> > potential resource leak or DoS attack.
> 
> The only way the setuid app can "deal" with the fd:s is to close them.
> So if the user program has set up the setuid app to inherit fd 10, 11,
> ..., 4711 to refer to extra objects, and that is a problem, then the
> setuid app have to loop over all fd:s (not entirely trivial, as
> there's no MAX_FD) and close them. I would think that's *not*
> recommended practice in any program, but I haven't written any setuid
> programs.

Me neither.  However, I think that is the same issue on POSIX.  Well, it
could also inspect the fds and carefully use some of them.  For example, if
you have a suid encryption program and the user asks you to print the output
on /dev/fd/3 and he arranges it that /dev/fd/3 points to something, then
that is fine.  The object handles come from the user, and they are
authenticated with the users IDs and not with the suid applications IDs.
So they only have the users access rights.

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]