[ On Wed, May 22, 1996 at 16:04:44 (-0400), der Mouse wrote: ]
> Subject: Re: setreuid() and setregid()
>
> Whether this upsets you according to the criterion you described
> depends on what it means to "go [] to" a user.  If it means just that
> euid is that user's, then all of these schemes will upset you, because
> they all allow a setuid-root executable to run as the real user and
> re-empower itself whenever it chooses.  (Nor do I think this is a bad
> property.)

It may not be a bad property in terms of ease of use and functionality,
but it is generally not accepted by the security establishment.

As I understand the DoD "orange book" C2 requirements (and especially
those of the Canadian equivalent to this document, the CTCPEC) state
that any "object" (such as a process) which lowers its clearance must
not be permitted to regain a higher level of clearance.

Most interpretations of these requirements w.r.t. UNIX security, that
I'm aware of, suggest that when a process running with uid==0 changes
its uid (and the implicitly gives up superuser status), it must not be
permitted to regain this status.  This is because in the UNIX the
implementation of security policy is done by forcing all transitions
where priviledges are gained through the SETUID facility (and because in
[traditional] UNIX there's really only one "trusted" user).

Indeed I've encountered several operating systems and applications which
allow users to gain root privs through holes opened by these types of
functions.  Couriously the majority of the applications involved are
mailers which probably shouldn't run as root in the first place!  ;-)

>  But all three schemes allow a process to permanently give
> up its privilege by copying the ruid into all other IDs it has, at
> which point there is no way back (unless the ID thus copied was 0).

Of course!  ;-)

-- 
							Greg A. Woods

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