setuid shell scripts

[Chris Torek]

In article <855 at cantuar.UUCP> greg at cantuar.UUCP (G. Ewing) writes:
>and Chris Torek indicated in an earlier posting that there was a
>problem that was *completely independent* of shell semantics.

I hope that this is a paraphrase, for I did not mean that.  If the
interpreter does nothing with the script, there are no setid problems.

>Presumably this means that it doesn't matter if the shell isn't
>a shell.

It must pay some attention to its arguments.  Moreover, it must interpret
argv[1] or argv[2] as a file name.

>Maarten Litmaath again:
>>\removing the setuid-#! facility is wrong.
>>Questionable; every interpreter would have to take care of things, while
>>it should be the kernel who's getting them straight.

>I'd be quite happy for the kernel to do it right. I was just saying that
>disabling the facility altogether might be overkill.

It might; but there are no known uses for the (now disallowed) kernel
invocation of set-id #! scripts that are also secure.  ksh can be made
to interpret set-id scripts, but it works without #! doing the ID setting;
one installs ksh itself setuid root instead.  Similar changes could be
made to sh and csh.

Again: if your kernel implements `#!', but ignores set-id bits, or
if you have no set-id scripts, or if you do not have `#!' at all,
you are safe.  A safe way to run some script set-ID is to write a
C program that is set-id that runs `execl("/path/to/interpreter",
"interpreter", "-options", "/path/to/script", (char *)0)', and then
exits if that fails.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris