>> 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.

Of course.  The question is, does simply running with euid set to
joe-user mean that the process has lowered its clearance?  I don't
think so, because as you say implicit in lowering clearance is that one
not then be able to raise it again.  Only an irrevocable change of uid
can count as lowering clearance, meaning the setuid() call that sets
all three uids the same.

So, I can almost hear you saying, why bother with having multiple UIDs
at all?  The first need is for the ruid, so that a setuid program can
tell who invoked it.  The suid one arguably does not actually need; I
don't quite understand why POSIX added it, but like the other POSIX
braindamages, we appear to be stuck with it for now, because it's not
quite braindamaged enough to make core dump it.  The reasons for
allowing a setuid process to switch its uid back to that of the invoker
while still retaining the potential to return to what it had are (a)
convenience of programming - it limits, to some extent, the damage bugs
can do, and (b) the closing of some race windows.

> 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.

And depending on what "changes its uid" means, this may or may not be
true of the UNIX model.  If it refers to any euid change, it's not true
and probably never will be; if it means giving up all other IDs, then
it is true and always has been.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu