Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!terryl From: terryl@tekcrl.LABS.TEK.COM Newsgroups: comp.unix.questions Subject: Re: setuid shell scripts (was: Re: Running processes as root) Message-ID: <4917@tekcrl.LABS.TEK.COM> Date: 25 Oct 89 04:12:10 GMT References: <21240@adm.BRL.MIL> <20329@mimsy.umd.edu> <3789@solo6.cs.vu.nl> <20367@mimsy.umd.edu> <3803@solo7.cs.vu.nl> Reply-To: terryl@tekcrl.LABS.TEK.COM Organization: Tektronix, Inc., Beaverton, OR. Lines: 33 In article <3803@solo7.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: +chris@mimsy.umd.edu (Chris Torek) writes: +\In article <20329@mimsy.umd.edu> (look, domain names now!) I wrote: +\>\On all of the BSD derivatives on which setuid scripts run setuid, +\>\all such setuid scripts are not secure. +\ +\In article <3789@solo6.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: +\>It almost never happens, but this time you seem to be wrong, Chris! +\ +\Not really, because I meant `if you write /etc/foo, make it setuid, start +\it with ``#! /bin/csh -bf'', and run it, and it runs setuid, then it is +\not secure.' + +I'm sure this was what you meant, but it wasn't what you said! (Check again.) +Allright, you have already posted an article explaining the race condition, +but here's another story anyway, which explains how indir(1) can get things +right. Enjoy. Not to pick nits, but Chris was *right* *both* times. As you have quoted him above, he said "On all of the BSD derivatives on which setuid scripts run setuid, all such setuid scripts are not secure."; implicit in this sentence is the fact that the only way to get a setuid script to run setuid, one must use the #! mechanism. So while Chris did not spell this out explicitly in his first posting, he did in his second. But he was still right the first time... Terry Laskodi of Tektronix PS: Is it time to post another way to breach security with a setuid shell script that does NOT depend on the race condition with "unlink"????