Safely Running Programs as root

This article is more about ending a bad habit than serious programming. How many of you regularly become root to do some routine task? I thought so. And, worse yet, how many of you just stay logged on as root because you know you can do what you want? That's too many.

One very common reason to become root is to run a shell script needing root privileges. For example, starting PPP is usually done by a script that must be run as root. For this article, I use that example as the basis for the code shown in Listing 1. There is nothing special about it—it just happens to be a common example. This same program can be modified to run other scripts requiring root privileges or to do other root-like tasks.

The first thing you need to understand is the meaning of the phrase “set UID on execution”. This concept is the only patented feature in Unix. It is the ability to “look like another user” while executing a program. The most common example is running the passwd program to change your password. If you look at the permissions on the password file you will probably see something like this:

-rw-r--r-- 1 root  1260
Nov  3 10:05 /etc/passwd

Notice that only root has permission to write to the file. Now look at the permissions on the password program:

-rwsr-xr-x 1 root 10636 Jun 6 1996
/usr/bin/passwd

Notice there is an s where you would expect an x to indicate execute permission for the owner. The s indicates the “set UID” bit is set.

Having the UID bit set means when you, as an ordinary user, execute the passwd program, the program is executed as if you were root. This enables you to change your password entry in /etc/passwd, but you won't be able to do anything else. The program itself (/usr/bin/passwd) is responsible for making sure you do only reasonable tasks; since you don't have write permission to the program, you can't change it.

If you understand set UID, you can now see how important it is in guaranteeing program security. For example, if your program has a way to get into the shell, it has a security hole.

While we are talking about security holes, one other approach is allowing shell scripts to run set UID. This ability actually exists in some Unix systems, and it opens huge security holes. Ideally, you must be able to read the script and trust it.

The program I wrote to start and stop PPP is in Listing 1. Its purpose is execution of the appropriate shell script to start or stop PPP, depending on whether it is called with an argument of on or off.

Most of the code is explained in the comments, but let me further explain a couple of items. First, I chose to set the PATH environment variable to a reasonable set of directories. It is important to do this to guarantee it's impossible to sneak an unauthorized executable into the program. Second, I used the execle system call to execute the appropriate script. execle passes the new environment to the called program, so it inherits the search path I set instead of the path of the calling user.

I also specified the full path name of the programs to run (see the #define lines)—another security consideration. It should be unnecessary after PATH has been set, but it's an inexpensive safety precaution.

Finally, the program must be installed properly. Once you have built the executable (make ppp), you should become root, move it to an appropriate directory (e.g., /usr/local/bin) and correctly set the permissions.

If you want anyone to be able to run the program, make sure it is owned by root and set the permissions to 4711. The leading 4 specifies setting the set UID bit. If you have a particular group of people you want to allow to run the program, change the group owner of the program to the appropriate group with permissions set to 4710.

That's it. If all goes well, you now have one less excuse to work logged in as root.

If you need a system for allocating various root tasks to ordinary users, solutions are readily available. Check out the sudo and super programs, which are included in most Linux distributions.