On Thu, 23 Nov 2000, Jarom=EDr Dolecek wrote:

> setr*[ug]id() don't offer any useful semantics not achievable via
> other set*[ug]id() and make things difficult for those library routines
> which need to know original real id in order to be able to do exploitable
> things with id of user who runs the binary.

  This is not true.  In fact, setre[ug]id offers two features not
available otherwise: 1) root-started programs can pretend they were
started by another user and/or group, and 2) non-root programs can setuid
to the effective user id.  #1 is valid, but #2 should have been done by
simply allowing setuid to the effective user id (so they are never
swapped) and not allowing non-root users to access setreuid.

  Both switching to the real id and open_as do not really fix the problem
because the id of the user who execed the program may no longer be
available at all, as in the case of the user program that effectively does
setuid(geteuid()).  Furthermore, checking for setuid does not fix the
problem because the program could then exec another program, keeping the
same environment, that then uses the tainted envrionment variable (this
kills file-id).  Disallowing library functions from accessing devices does
not work when the kernel does not know that a file refers to a device (as
could be the case on a network file system).  Also, opening a regular file
may have side effects in non-traditional file systems, such as a portal
file or a file system that can fetch files automaticly from off-line
media.  The abstraction needed to determine if it is safe to open a file
does not exist.

  The real problem here is not considering the environment to be tainted.
One way to make this clear is to start setuid programs with an empty
environment and an additional tainted environment that contains the
environment passed to execve.

  The question now becomes how to untaint the environment for execed
programs and how to safely use as much of the passed environment as is
wanted in this program.  This may mean load the TZ now with the real ID
but do not set the environment or access that file later.  Many setuid
programs might never want to accept a user supplied environment variable
and doing so may have security implications even if the actual reading of
that variable is done securely.

  It will always be possible to abuse setuid, and the current proposals
make the problem worse instead of better.  The current setuid model is
fine, even setreuid; what needs to be done is to make it possible to
untaint the environment in various conditions and document how to do so.

Matthew Orgass
darkstar@pgh.net