On Wed, 15 Nov 2000, Greg A. Woods wrote:

# While it is true that careful and complete control of all aspects of
# process control in an entire system can circumvent such vulnerabilities,
# the the fundamental problem with allowing an unprivileged process to
# (re)gain superuser privileges is that it breaks the unix security model
# and screws up peoples perceptions and understandings of how privileged
# processes are created and protected.  This leads to system designers
# introducing new features which do not take the appropriate precautions
# and can thus be used in conjunction with sete*id() to compromise the
# system.  As I say, this has happened several times in the past and it
# will undoubtably happen again in the future.  The correct fix is to obey
# the POSIX rules (and thus the fundamental Unix security model) and never
# allow a process to (re)gain superuser privileges after it has run as an
# ordinary user.

But a process can, as super-user, fork(), setuid(non-superuser), do its
thing and return as it is, and it can communicate state back and forth
with its parent if so written, to the extent that it is performing the
exact same function as though it were allowed to revert to setuid(superuser).

The only thing that POSIX does is make it more inconvenient to do this,
and this is not always a good thing.  If the program is certain it's
not going to need to return to being super-user, it should be written
as such at that point.

This is yet another thing that bothered me about SVID/POSIX/SUS2 in
the first place.  I thought Berkeley, though stepping out on a limb,
did The Right Thing.


				--*greywolf;
--
*BSD: Choose Your Own Slogan.