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/passwdNotice 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.
Phil Hughes is publisher of Linux Journal. In a past life he was a Unix systems programmer.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- RSS Feeds
- Tech Tip: Really Simple HTTP Server with Python
1 hour 16 min ago
- Automatically updating Guest Additions
2 hours 25 min ago
- I like your topic on android
3 hours 11 min ago
- Reply to comment | Linux Journal
3 hours 32 min ago
- This is the easiest tutorial
9 hours 47 min ago
- Ahh, the Koolaid.
15 hours 25 min ago
- git-annex assistant
21 hours 25 min ago
- direct cable connection
21 hours 47 min ago
- Agreed on AirDroid. With my
21 hours 58 min ago
- I just learned this
22 hours 2 min ago
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.