[ On Sat, May 25, 1996 at 12:17:35 (EDT), Greg Hudson wrote: ]
> Subject: Re: setreuid() and setregid() 
>
> (a) is not a terribly useful guideline, since any stack-smash bug can
> be exploited to do a setuid() back to root.  (b) is the important
> issue; there are cases where you really want to do operations as a
> non-root user (making sure you don't do anything to the filesystem
> that said user can't do) before you're ready to revoke root
> privileges.  Doing a fork() and setuid() for such operations doesn't
> always work when there are library interfaces in the way.

Is this issue truely the case?  I've always wished I had the time,
energy, and resources to try out a hypothesis:  It has been often
suggested by security gurus and others that there are only a very few
reasons for code to run with euid==0, and that a redesign of the way
various programs interface with the system might make it possible to
reduce the amount of setuid-root code to a few very small programs.

I think the "new" Research UNIX mail system (UPAS) is a good example of
such a design.

At times in the past, when my life was more focused on security
analysis, rather than programming and systems, I had some rather angry
debates with folks who sided with the BSD view that it's better to
re-write the security policy and try complex programming tricks to
reduce the risk than to work with the existing security policy.  These
days I'm not responsible for that level of security.  ;-)

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>