show me

[Robert C. White Jr.]

in article <62472 at sun.uucp>, guy at gorodish.Sun.COM (Guy Harris) says:
> 
>> > Are these problems specific to particular versions of UNIX, or particular
>> > shell types (sh, csh, ksh, perl) or version of those shells?
>> 
>> As an example, just for nastyness' sake would be (under setuid root or bin
>> shell, a use executes teh following):
> 
> No, that's not what the problem is.  The list of things you can do if you
> already *have* super-user privileges is extremely long, but not really relevant
> here since the super-user (in systems that have such a notion) had better be
> trusted (which is why some systems - e.g., proposed secure UNIX systems - don't
> have the notion of super-user).

Read the text please; to whit: "[run these commands] under a setuid root or
bin shell, a user executes the following:"  [Typos corrected]

The poster asked what the danger of a setuid shell was.  This is a danger.
Because this theoretical shell gives any user the right to execute
as root or bin (ethier/or) and therefore the right to "correct" the
contents of "ls" thereby setting the entire system up for a fall.

This example comes from one peice of comercial code (we have it here)
where a single program, setuid root, invokes it's arguments as a
child process.  If there are no arguments, you get a shell.
Ncest pa?

The point being that if you setuid a program as broad as the shell
you are assuming that everybody who can log in at all is
trustworthy;  an obvious phalacy.

My statement stands un-altered.

Rob.