Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!ucsd!ucsdhub!jack!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.unix.wizards
Subject: Re: show me
Message-ID: <1126@nusdhub.UUCP>
Date: 3 Aug 88 19:15:34 GMT
References: <62472@sun.uucp>
Organization: National University, San Diego
Lines: 34

in article <62472@sun.uucp>, guy@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.