setting SUID for scripts
Guy Harris
guy at auspex.auspex.com
Sun Aug 5 10:02:00 AEST 1990
>I'm referring to the hole caused by the shell reopening the file rather
>than use the same FD that was validated by exec.c while it was parsing
>#! line.
>
>What is the "standard fix?" Does it require /dev/{stdin,fd,etc}?
The answer to the second question is "yes". The answer to the first
question - as, given your second question, I'll bet you already
suspected - is "for set-UID scripts, at least, open the file giving it
an FD, and pass the pathname of the appropriate '/dev/fdN' entry instead
of the pathname of the script to the interpreter."
>How do you close the main hole without changing the shells themselves?
>Given 3rd party shells such as bash and ksh, how do you close the hole?
>What about "shells scripts" with an initial line like "#!/bin/make -f"?
>(Yes, MAKEDEV is not suid.)
If this isn't sufficient to close that particular hole, you might want
to let AT&T know, *and* probably Berkeley as well if they're planning on
putting it into 4.4BSD. (You might also let Dave Korn know, as he is at
least one of the originators of this idea, as I remember.)
(BTW, "ksh" isn't a third-party shell, at least not in S5R4....)
Whether this leaves any *other* security holes, for any particular
interpreter (shell-of-the-day, "make", "awk", "sed", "vi", etc.), is
another question; the answer to that question is probably "yes", for
many of the potential interpreters....
More information about the Comp.sys.sgi
mailing list