show me

[Matt Squires]

in article <43200021 at uicsrd.csrd.uiuc.edu>, kai at uicsrd.csrd.uiuc.edu says:
> Nf-ID: #N:uicsrd.csrd.uiuc.edu:43200021:000:427
> Nf-From: uicsrd.csrd.uiuc.edu!kai    Jul 27 20:53:00 1988
> 
> 
> I've seen talk about how unsafe setuid shell scripts are, but haven't ever
> seen any examples that prove this.  Would someone please explain to me know
> why, as a system administrator, I shouldn't ever use setuid/setgid shell
> scripts?                                                           ^^^^^
> ^^^^^^^

meanwhile...
/ hpcvlx:comp.unix.wizards /
rwhite at nusdhub.UUCP (Robert C. White Jr.)
/ 12:27 pm  Aug  1, 1988 /

<As an example, just for nastyness' sake would be (under setuid root or bin
<shell, a use executes teh following):
 ^^^^^
[nasty shell commands deleted...]

The issue is giving a user a setuid shell SCRIPT, not a setuid shell!  Of
course, if you give a user a flippin' root shell, he or she can do anything
under the sun!  That is what root shells are for!

The issue is why are setuid SCRIPTS a security problem.  Ideally, a setuid
script will run with root (or some other) effective uid, execute the commands
in the script file, and exit, leaving the user in his/her original state.
Apparently, that is not the case, i.e. there appears to be some way of breaking
out of the setuid script, giving the user an effective uid of root (or somebody
else).

  Is this true?  How can it be done?  Is there a work-around?  Enquiring
minds want to know!  I remember back in the spring of 88 I saw a BSD bug fix
that said "setuid/gid scripts are a security problem." and included a patch
to the kernal that more or less disabled setuid/gid scripts.  Sounds suspicious
if you ask me...

<There are more [nasty commands], but I think you can get the point.
<
<Rob.

I'm afraid you may have missed the original point, Rob.

mcs