Privileged programs have access to features and resources (files, devices, and so on) that are not available to ordinary users. A program can run with privileges by two general means:
The program was started under a privileged user ID. Many daemons and network servers, which are typically run as root, fall into this category.
The program has its set-user-ID or set-group-ID permission bit set. When a set-user-ID (set-group-ID) program is execed, it changes the effective user (group) ID of the process to be the same as the owner (group) of the program file. (We first described set-user-ID and set-group-ID programs in Section 9.3.) In this chapter, we’ll sometimes use the term set-user-ID-root to distinguish a set-user-ID program that gives superuser privileges to a process from one that gives a process another effective identity.
If a privileged program contains bugs, or can be subverted by a malicious user, then the security of the system or an application can be compromised. From a security viewpoint, we should write programs so as to minimize both the chance of a compromise and the damage that can be done if a compromise does occur. These topics form the subject of this chapter, which provides a set of recommended practices for secure programming, and describes various pitfalls that should be avoided when writing privileged programs.
One of the best pieces of advice concerning set-user-ID and set-group-ID programs is to avoid writing them whenever possible. If there is an alternative way of performing a task that doesn’t involve giving a program privilege, we should generally employ that alternative, since it eliminates the possibility of a security compromise.
Sometimes, we can isolate the functionality that needs privilege into a separate program that performs a single task, and exec that program in a child process as required. This technique can be especially useful for libraries. One example of such a use is provided by the pt_chown program described in Changing Slave Ownership and Permissions: grantpt().
Even in cases where a set-user-ID or set-group-ID is needed, it isn’t always necessary for a set-user-ID program to give a process root credentials. If giving a process some other credentials suffices, then this option should be preferred, since running with root privileges opens the gates to possible security compromises.
Consider a set-user-ID program that needs to allow users to update a file on which they do not have write permission. A safer way to do this is to create a dedicated group account (group ID) for this program, change the group ownership of the file to that group (and make the file writable by that group), and write a set-group-ID program that sets the process’s effective group ID to the dedicated group ID. Since the dedicated group ID is not otherwise privileged, this greatly limits the damage that can be done if the program contains bugs or can otherwise be subverted.