Path: utzoo!utgpu!watmath!watdcsu!dmcanzi
From: dmcanzi@watdcsu.waterloo.edu (David Canzi)
Newsgroups: comp.unix.wizards
Subject: Re: setuid shell scripts
Message-ID: <5300@watdcsu.waterloo.edu>
Date: 21 Nov 88 08:36:47 GMT
References: <850@cantuar.UUCP> <1627@solo8.cs.vu.nl> <855@cantuar.UUCP> <14552@mimsy.UUCP> <862@cantuar.UUCP> <3545@jpl-devvax.JPL.NASA.GOV>
Reply-To: dmcanzi@watdcsu.waterloo.edu (David Canzi)
Organization: U. of Waterloo, Ontario
Lines: 49

In article <3545@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
>In article <862@cantuar.UUCP> greg@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