Secure setuid shell scripts

[Steve Hayman]

What if we had a C program, let's call it "securesh", that you
would use instead of "#!/bin/sh" when you wanted to create
a secure setuid shell script.  "securesh" would try to set
up a reasonable environment, PATH, IFS, etc etc, and then
exec sh to handle shell script.  Sort of the solution that
people have been proposing ("write a C wrapper around your script")
but bundled up nicely.

For instance, suppose we have a setuid root shell script,
/usr/local/bin/myscript.  Instead of starting it with
"#!/bin/sh", we start it with "#!/bin/securesh". 

So securesh starts up with an argument list like this

	/bin/securesh
	/usr/local/bin/myscript
	other options

And securesh (a C program) does ...
	- check the permissions on "myscript" to make
		sure it's setuid (and then setuid() to whatever is appropriate)

	- set PATH to a reasonable value  (of course it may be
		reset later by the script)

	- unset IFS, maybe unset every other environment variable.

	- stat() the script file - if it's a symlink, exit with
		a warning message.  If it's a relative pathname,
		exit with a warning message.  Maybe we open()
		the file as the first thing we do and fstat() it
		in case someone tries to swap it on us.
	
	- perhaps some other checks would be appropriate here

	- once we are convinced that we have a secure environment,
		(ok, a "secure enough" environment), we
		exec /bin/sh /usr/local/bin/myscript


The key here is that we set up a reasonable environment, and then
refuse to execute the script if anything looks fishy (the
file name is a symlink, etc).  Perhaps this would be a reasonable
compromise between wanting the occasional setuid shell script - they
are convenient sometimes - and wanting to be secure.

I think this would provide a "safe enough" way to execute setuid
shell scripts.  I'm familiar with the problems with setuid scripts
now, and think that if you enforced the convention that setuid scripts
*MUST* begin with /bin/securesh instead of /bin/sh, you'd have
enough security.  (I could see maybe running a program from the crontab to 
track down setuid-/bin/sh scripts and turn off their setuid bit.)

If anyone can foresee problems with this approach, I'd like to hear about
them before I try to implement this.


..Steve

--
Steve Hayman    Workstation Manager    Computer Science Department   Indiana U.
sahayman at iuvax.cs.indiana.edu