• Choose a category
• All
• Classic-Fiction

For example, suppose that you've written a really nifty game program that keeps a private score file showing the top 15 players on your system. You don't want to make the score file world-writable because anyone could just come along and edit the file to make themselves the high scorer. By making your game setuid to your user ID, the game program can update the file, which you own, but no one else can update it. (The game program can determine who ran it by looking at its real user ID, and using that to determine the login name.)

The setuid facility is a nice feature for games and score files, but it becomes much more dangerous when used for root. Making programs setuid root lets administrators write programs that do certain things that require root privilege (e.g., configure printers) in a controlled way. To set a file's setuid bit, type chmod u+s filename. Setuid is dangerous when root owns the file; thus chown root file followed by chmod u+s file is the problem.

A similar facility exists at the group level, known (not surprisingly) as setgid (set group ID). Use chmod g+s filename to turn on setgid permissions. When you do an ls -l on a setuid or setgid file, the x in the permission mode is replaced with an s; for example, -rws--s--x for a file that is readable and writable by the owner, executable by everyone, and has both the setuid and setgid bits set (octal mode 6711).

Modern system administration wisdom says that creating setuid and setgid shell scripts is a terrible idea. This has been especially true under the C shell because its .cshrc environment file introduces numerous opportunities for break-ins. In particular, there are multiple ways of tricking a setuid shell script into becoming an interactive shell with an effective user ID of root. This is about the best thing a cracker could hope for: the ability to run any command as root. Here is one example, borrowed from the discussion in http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html:

... Well, suppose that the script is called /etc/setuid_script, starting with:

#!/bin/sh

Now let us see what happens if we issue the following commands:

$ cd /tmp

$ ln /etc/setuid_script -i

$ PATH=.

$ -i

We know the last command will be rearranged to:

/bin/sh -i

However, this command will give us an interactive shell, setuid to the owner of the script! Fortunately, this security hole can easily be closed by making the first line:

#!/bin/sh -

The - signals the end of the option list: the next argument -i will be taken as the name of the file to read commands from, just like it should!

Because of this, POSIX explicitly permits the single - character to end the options for /bin/sh.

* * *

Tip

There is an important difference between a setuid shell script, and a setuid shell. The latter is a copy of the shell executable, which has been made to belong to root and had the setuid bit applied. In the previous section on Trojan horses, suppose that the nasty stuff here was this code:

cp /bin/sh ~badguy/bin/myls

chown root ~badguy/bin/myls

chmod u+s ~badguy/bin/myls

Remember, this code executes as root, so it will work. When badguy executes myls, it's a machine-code executable file, and the setuid bit is honored. Hello shell that runs as root. Goodbye security!

* * *

In fact, the dangers of setuid and setgid shell scripts are so great that modern Unix systems, meaning both commercial Unix systems and freeware clones (4.4 BSD-derived and GNU/Linux), disable the setuid and setgid bits on shell scripts. Even if you apply the bits to the file, the operating system does not honor them.[3]

We also note that many modern systems have options to the mount command that disable the setuid/setgid bit for entire filesystems. This can be a good idea for network-mounted filesystems, as well as for removable media such as floppy disks and CD-ROMs.

* * *

[3] Mac OS X and at least one version of OpenBSD that we