Secure setuid shell scripts

[David Goodenough]

>From article <14069 at mimsy.UUCP>, by chris at mimsy.UUCP (Chris Torek):
> In article <4409 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) asks:
>>If a 4.3BSD system has not been patched to disallow set-user-id shell
>>scripts, but root uses no set-user-id scripts, does a security hole
>>still exist that will allow an unprivileged user to obtain root
>>privileges?
> 
> If I can modify that to `... but there are no set-user-id scripts that
> set the user ID to root', the answer is no (discounting other avenues,
> e.g., the `::0:0:::' entries sometimes found in /etc/passwd).  If the
> system has not been patched, and there is a set-ID script somewhere,
> that script can be used as the basis for gaining the privileges granted
> by that ID (user or group) in a way that the author of the script most
> likely did not intend.

One question. What does an

execl("/bin/sh", "/bin/sh", "-", "-i", 0);

do. I.e. what happens when the first line is:

#! /bin/sh -

rather than plain old:

#! /bin/sh

This closes up the security hole very nicely here (unless there's some
sneaky way of getting in that I didn't know about). Incidentally, lakart
is BSD4.3, so we DO have symbolic links: it was suggested that if no
symbolic links existed, then by denying write permission to general users
on all filesystems where suid 0 reside the problem could be reduced. (I'm
not going to say solved, nothing in this world is certain except death
and taxes :-) :-) )

As an aside on the IFS problem: the following is taken from man 1 sh:

          IFS  Internal field separators, normally space, tab,
               and newline.  IFS is ignored if sh is running as
               root or if the effective user id differs from the
               real user id.

i.e. with our shell setting IFS to "/" (or anything) won't help a whole
lot
-- 
	dg at lakart.UUCP - David Goodenough		+---+
							| +-+-+
	....... !harvard!xait!lakart!dg			+-+-+ |
AKA:	dg%lakart.uucp at harvard.harvard.edu	  	  +---+