setuid shell scripts

[Larry Wall]

David Canzi writes:
: The interpreter takes the command name it was called by and:
: (1) derives a full pathname for it, that starts at root and
:     contains no symlinks.  (I've thought over somewhat what's
:     involved in this... one important thing is to be prepared
:     to handle *anything* the user can put into $PATH.)

This would be quite a feat.  In fact, I believe it's impossible without a
kernel mod.

But even if you could do this in user mode, it's not good enough to prevent
the break.

: (2) checks that all directories in the path are searchable by
:     the invoker, owned only by root or bin, and modifiable only
:     by owner.

You've just outlawed . in anyone's PATH.

: (3) checks that the file itself is executable by the invoker,
:     and modifiable only by owner.  (Identity of invoker is to be
:     determined from real uid of process, *not* controlling tty
:     or environment variables.)

No quarrel here.  Perl does these things during set-id emulation.

: (4) If the interpreter's real and effective uids differ, the file
:     is checked to make sure that it is indeed setuid to the effective
:     uid of the process.  A similar check is make for gids.

You've just prevented any set-id program from running a script as a
subprocess.  All the scripts that people put setuid C wrappers around
because they didn't want their scripts setuid now blow up.

: (5) Open the input file, using the carefully checked full pathname
:     and check its first line, to be sure that it contains
:     "#!/usr/local/para-sh" or whatever it should contain.

Fine.  Suidperl does similarly.

: (6) If any of the above steps fail, print "I feel insecure" and exit.

If you wanna save a gob of CPU time just print "I feel insecure" to begin
with.  :-)

: (7) Proceed to interpret the file's contents.  (This may mean calling
:     a shell with the checked pathname.)
: 
: I may write a program to do this.  In addition, before invoking any
: shell, I may build an all-new environment containing only a PATH
: variable listing only trusted directories and a USER variable
: containing the user's name, as determined from the real uid of the
: process.

You give me a program just like that and I'll bust security with it.

[Boy, that sounds hubriscious.  Hubrisly.  Hubritical.  Whatever the
blamed adjective is.  Anyway, I'm not trying to be that way.  I think.
I'll be glad to discuss this more openly by mail.]

Larry Wall
lwall at jpl-devvax.jpl.nasa.gov