setuid shell scripts

David Canzi dmcanzi at watdcsu.waterloo.edu
Mon Nov 21 18:36:47 AEST 1988


In article <3545 at jpl-devvax.JPL.NASA.GOV> lwall at jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
>In article <862 at cantuar.UUCP> greg at cantuar.UUCP (G. Ewing) writes:
>: An interpreter for some programming language could be written
>: that was careful to check the mode and owner of any file that it
>: was about to execute, and if it was setu(g)id, refuse to continue
>: if its owner(group) didn't match the process's effective u(g)id.
>: 
>: Correct me if I'm wrong, but as things stand, this ought to be
>: safe, oughtn't it?
>
>Nope, sorry.  Still definitely unsafe.

Okay, how about this?

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.)
(2) checks that all directories in the path are searchable by
    the invoker, owned only by root or bin, and modifiable only
    by owner.
(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.)
(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.
(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.
(6) If any of the above steps fail, print "I feel insecure" and exit.
(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.

Is there anything I've left out?  Is there any hole in this through
which a clever user can extract some illicit advantage?  Should I give
up on computers (especially trying to understand security well enough
to implement some) and go into organic farming?

-- 
David Canzi



More information about the Comp.unix.wizards mailing list