Secure setuid shell scripts

[Barry Shein]

From: terryl at tekcrl.CRL.TEK.COM
>In article <4409 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
>>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?
>
>     Yes. The problem is not that root uses a set-user-id shell script,
>but that there exists anywhere in the file system a set-user-id shell
>script THAT I CAN EXECUTE AS A MERE MORTAL(i.e. normal user). If such
>a set-user-id shell script does exist, then in a manner of minutes
>(depending on how fast I can type!!! (-:) I can become the id of that
>shell script!!!!

I think Rahul is asking the same question I asked and we're both being
misunderstood (I've also gotten some private mail indicating a
misunderstanding.)

Rephrase: If there are NO setuid scripts on the entire system does
there exist a bug which can be exploited?

For example, is there a bug such that a (non-priv'd) user could make a
new script, perhaps setuid'd, and by some machination get it to be
setuid root (eg. link punning to a file owned by, but not setuid, root
or some such thing.)

The reason for the question is, and I think Rahul was also getting at
this, that this would seem to be minimal sufficient cause to shut off
the feature in the system. Anything less (ie. being able to hack at
setuid shell scripts) seems a questionable cause and might be better
handled by merely advising those interested in security not to create
setuid scripts. Put it in the distribution motd or some such thing.

As a counter-example, I've created setuid scripts which setuid to a
psuedo-user who owned some files which, although a nuisance, I
wouldn't lose a lot of sleep over having trashed.

Specifically, I had a psuedo-user "recipes" who owned the recipes
directory and entries for our local alt.gourmand collection and that
was all.

There was a setuid (user=recipes, non-priv'd) script in there which
allowed someone to put a new recipe into the directory and another to
rebuild an index file to incorporate new recipes. It was nice for
random users on a reasonably trustable system to be able to take care
of these things if they noticed them out of synch and I couldn't
imagine any damage they could do I couldn't repair in 15 minutes
(especially cuz I kept a mirror image of everything on another system
for another group, and besides, tape backups were good on that
system.)

I could think of other useful examples, none of them critical (I'm
hardly saying the above is critical, but it fits a pattern I've used
over and again, some non-priv'd setuid scripts to allow users to
manage non-critical files w/o having to go bother a systems person.)
Another was that the games files were owned by a non-priv psuedo-user
"scores" and a script to let a user with a wayward lock file (which
some games created and then refused to let you play again if it
existed, typically a problem after a crash) remove it. So they could
trash all the scores files and lock files in the games area, so what?
Nuisance, but hardly worth the alternative, having people bug
operations to unscrew their rogue games (I know, all can be handled by
C programs, but is it worth it? hardly.)

>But, after thinking about it for a week or so, the little light
>(literally!!) when on inside my head,

I doubt that, perhaps a light went on figuratively, but literally?
Do you really have little electronic filaments in your head? :-)

	-Barry Shein*, ||Encore||

* Chairman, Committee for Eradication of the Use of the Word
"Literally" as an Intensifier.
--