Path: utzoo!utgpu!attcan!uunet!steinmetz!vdsvax!barnett
From: barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett)
Newsgroups: comp.unix.wizards
Subject: Re: show me
Summary: Guy is right
Message-ID: <5030@vdsvax.steinmetz.ge.com>
Date: 5 Aug 88 03:26:56 GMT
References: <43200021@uicsrd.csrd.uiuc.edu> <1570005@hpcvlx.HP.COM>
Reply-To: barnett@steinmetz.ge.com (Bruce G. Barnett)
Organization: General Electric CRD, Schenectady, NY
Lines: 34

In article <1570005@hpcvlx.HP.COM> squires@hpcvlx.HP.COM (Matt Squires) writes:
|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.  

With a setuid shell script, a hacker could get a root shell in 10
seconds. It doesn't matter WHAT is in the shell script. Setuid scripts are 
basically insecure. There is NO work-around, unless the vendor's
software has closed ALL of the holes. 

You MIGHT consider having a setuid script in a directory where
only one group or user can execute it. This only limits the access to
the hole. That is, it makes the number of tasks to break in longer.
Then you have to make two user ID's are secure instead of one. Not Good.

Just to give you a taste of the types of problems with setuid shell scripts,
have you considered:

	1. People can alias '/bin/cat' in their .cshrc
	2. shell scripts import environment variables like PATH
	3. Shell scripts, and several programs output to various file
	   descriptors. These can be redirected to other files
	4. Temporary files can be modified in the middle of a routine,
	   if access is wrong

But these are *Nothing* compared to the real hole.
The hole is small, but tough to close. See the summary line.

		Avoid setuid shell scripts. 
-- 
	Bruce G. Barnett 	<barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>
				uunet!steinmetz!barnett