loki@physicsa.mcgill.ca (Loki Jorgenson Rm421) (01/24/89)
On and off I have tried to get the suid bit of the file mode to function properly. Typically, this has meant that I have set a root owned sh or csh script file with the mode 4755 and tried to execute it as user. I am aware of the limitations of using such a file from a NFS mounted partition but this doesn't work even on the server. Before anyone suggests it, I have specified the suid mount option on the partition and remounted it. (By the by, it's a 3/180 running OS 3.5). Am I missing something critical here? Loki Jorgenson node: loki@physicsa.mcgill.ca Physics, McGill University fax: (514) 398-3733 Montreal Quebec CANADA phone: (514) 398-6531 [[ From your message I gather that you are trying to make a shell script run as a set-uid program. There are two ways in which a script gets "executed". First, the shell checks to see if the system call "exec" can successfully execute it. If it cannot, then the shell starts up a sub-shell with the file as standard input. With this method, it is impossible to have a script set-uid. However, there is the second method. If the text file starts with the two characters "#!", then the *kernel* takes the remainder of the line to be the name of an interpretive program (it also allows one argument to be passed---see the manual page for "execve(2)"). So if the first line in a shell file is "#!/bin/sh" or "#!/bin/csh", then the file can actually be executed like it was a binary executable (it will run when invoked with a call to "exec"). Only this second form can be successfully set-uid. --wnl ]]
matt@uhura.cc.rochester.edu (02/01/89)
In v7n117, our moderator answers: >If the text file starts with the two characters "#!", then the *kernel* >takes the remainder of the line to be the name of an interpretive program >(it also allows one argument to be passed---see the manual page for >"execve(2)"). Although the "one argument" limitation may be true on every other 4.3 based OS (I don't really know since I've only dealt with Suns), it just isn't so for SunOS (up to 3.2 at least). For example, take the following shellscript: #!/bin/csh -f -x #!/bin/csh -f -e -x #!/bin/csh -f -e echo hello cat XXXX echo hello Assuming "XXXX" is NOT present, the output is: echo hello hello cat XXXX XXXX: No such file or directory echo hello hello Now, delete the first line of the script, leaving the "#!/bin/csh -f -e -x" as the new first line, this gives: echo hello hello cat XXXX XXXX: No such file or directory Finally, remove the first line again, leaving "#!/bin/csh -f -e", this gives: hello XXXX: No such file or directory I've tried this with other programs (like "#!/usr/ucb/more -c -d") with the same result. ----- Matt Goheen uucp: {rutgers,ames}!rochester!srs!matt, matt@srs.uucp internet: srs!matt@cs.rochester.edu, matt%srs.uucp@harvard.harvard.edu [[ Sorry, but it doesn't prove your assumption. And I *know* I'm right this time. :-) Try two things. First, store your example in a file called "hi". Then type the command "/bin/csh '-f -x' <hi". Guess what? Both the "f" and the "x" flag get turned on. To really drive the point home, write a simple program that prints each argument out on a separate line. Then name the executable in a "#!" line, giving more than one argument (such as "#!/home/you/a.out -a -b"). When I do this, no matter what appears on the remainder of the line it all shows up in the first argument. The second argument is always the name of the executed file. This is true under 3.2 and 4.0.1. You just happened to choose a program (/bin/csh) that is very forgiving when it scans its arguments. If you want to see an example closer to yours that really does fail, try using the "-t" option to sort as the first argument and some other option as the second (such as "#!/usr/bin/sort -t: -n"). --wnl ]]
maart@uunet.uu.net (Maarten Litmaath) (02/01/89)
phil@Rice.edu (William LeFebvre) writes: > ... So if the first line in a shell file is "#!/bin/sh" or > "#!/bin/csh", then the file can actually be executed like it was a binary > executable (it will run when invoked with a call to "exec"). Only this > second form can be successfully set-uid. And it's a security risk, discussed in comp.unix.wizards not too long ago. For safe setuid scripts use David Goodenough's (dg@lakart.uucp) `secure' program or my `setuid' program, both of which appeared in comp.sources.misc. These programs are to be specified as the interpreter of the script: #! /bin/secure or #! /bin/setuid They in turn execute the real interpreter of the script, e.g. /bin/sh. Using David's program there must be a database containing the names, uids and interpreters of setuid scripts, and the scripts themselves needn't be setuid because /bin/secure is setuid root; my program expects below the `#!' line a line of the form: #? absolute-path-of-interpreter [args] absolute-path-of-file [args] If you want to use my program, make sure you have version 1.1 or higher (1.0 contained a race condition bug); I expect to see it in comp.sources.misc any day from now. Maarten Litmaath @ VU Amsterdam: maart@cs.vu.nl, mcvax!botter!maart
prl@eiger.uucp (02/01/89)
But DON'T actually do this [[ setuid shells ]] if you want to keep your system in any way secure. There is a kernel bug (in all Unixes with the #! feature, not just SunOS) which allows set-uid shell scripts to be tricked into allowing *any* commands to be executed setuid in place of the shell script!! DON'T DO IT!! See Maarten Litmaath's posting in comp.sources.misc v05i097 for a probably secure way of doing what you want. I am surprised that wnl didn't warn about this problem. [[ Wnl didn't warn about this problem because wnl wasn't aware of it. Unfortunately, I don't have the time to ingest all the information (and weed out the noise) that the net produces. Thank you for bringing it to everyone's attention. --wnl ]] -- Peter Lamb uucp: uunet!mcvax!ethz!prl eunet: prl@ethz.uucp Tel: +411 256 5241 Integrated Systems Laboratory ETH-Zentrum, 8092 Zurich