Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!husc6!encore!bzs@encore.com From: bzs@encore.com (Barry Shein) Newsgroups: comp.unix.wizards Subject: Re: Secure setuid shell scripts Message-ID: <3969@encore.UUCP> Date: 24 Oct 88 00:36:34 GMT Article-I.D.: encore.3969 References: <14066@iuvax.cs.indiana.edu> <4409@bsu-cs.UUCP> <3194@tekcrl.CRL.TEK.COM> Sender: news@husc6.harvard.edu Reply-To: bzs@encore.com (Barry Shein) Organization: Encore Computer Corp Lines: 75 In-reply-to: terryl@tekcrl.CRL.TEK.COM From: terryl@tekcrl.CRL.TEK.COM >In article <4409@bsu-cs.UUCP> dhesi@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. --