Host management
4.7 Software installation
4.7.6 Configuration security
In the preceding sections we have looked at some examples and suggestions for dealing with software installation. Let us now take a step back from the details to analyze the principles underlying these.
The first is a principle which we shall return to many times in this book. It is one of the key principles in computer science, and we shall be repeating it with slightly different words again and again.
Principle 15 (Separation III). Independent systems should not interfere with one another, or be confused with one another. Keep them in separate storage areas.
The reason is clear: if we mix up files which do not belong together, we lose track of them. They become obscured by a lack of structure. They vanish into anonymity.
The reason why all modern computer systems have directories for grouping files, is precisely so that we do not have to mix up all files in one place. This was
discussed in section 4.4.5. The application to software installation is clear: we should not ever consider installing software in /usr/bin or /bin or /lib or /etc or any directory which is controlled by the system designers. To do so is like lying down in the middle of a freeway and waiting for a new operating system or upgrade to roll over us. If we mix local modifications with operating system files, we lose track of the differences in the system, others will not be able to see what we have done. All our hard work will be for nothing when a new system is installed.
Suggestion 1 (Vigilance). Be on the lookout for software which is configured, by default, to install itself on top of the operating system. Always check the destination using make -n install before actually committing to an installation.
Programs which are replacements for standard operating system components often break the principle of separation.a
aSoftware originating in BSD Unix is often an offender, since it is designed to be a part of BSD Unix, rather than an add-on, e.g. sendmail and BIND.
The second important point above is that we should never work with root priv-ileges unless we have to. Even when we are compiling software from source, we should not start the compilation with superuser privileges. The reason is clear: why should we trust the source of the program? What if someone has placed a command in the build instructions to destroy the system, plant a virus or open a back-door to intrusion? As long as we work with low priv-ilege then we are protected, to a degree, from problems like this. Programs will not be able to do direct and pervasive damage, but they might still be able to plant Trojan horses that will come into effect when privileged access is acquired.
Principle 16 (Limited privilege). No process or file should be given more privileges than it needs to do its job. To do so is a security hazard.
Another use for this principle arises when we come to configure certain types of software. When a user executes a software package, it normally gets executed with the user privileges of that user. There are two exceptions to this:
• Services which are run by the system: Daemons which carry out essential services for users or for the system itself, run with a user ID which is independent of who is logged on to the system. Often, such daemons are started as root or the Administrator when the system boots. In many cases, the daemons do not need these privileges and will function quite happily with ordinary user privileges after changing the permissions of a few files. This is a much safer strategy than allowing them to run with full access. For example, the httpd daemon for the WWW service uses this approach. In recent years, bugs in many programs which run with root privileges have been exploited to give intruders access to the system. If software is run with a non-privileged user ID, this is not possible.
• Unix setuid programs: Unix has a mechanism by which special privilege can be given to a user for a short time, while a program is being executed. Software
which is installed with the Unix setuid bit set, and which is owned by root, runs with root’s special privileges. Some software producers install software with this bit set with no respect for the privilege it affords. Most programs which are setuid root do not need to be. A good example of this is the Common Desktop Environment (a multi-vendor desktop environment used on Unix systems). In a recent release, almost every program was installed setuid root. Within only a short time, a list of reports about users exploiting bugs to gain control of these systems appeared. In the next release, none of the programs were setuid root.
All software servers which are started by the system at boot time are started with root/Administrator privileges, but daemons which do not require these privileges can relinquish them by giving up their special privileges and run-ning as a special user. This approach is used by the Apache WWW server and by MySQL for instance. These are examples of software which encourage us to create special user IDs for server processes. To do this, we create a spe-cial user in the password database, with no login rights (this just reserves a UID). In the above cases, these are usually called www and mysql. The software allows us to specify these user IDs so that the process owner is switched right after starting the program. If the software itself does not per-mit this, we can always force a daemon to be started with lower privilege using:
su -c ’command’ user
The management tool cfengine can also be used to do this. Note however that Unix server processes which run on reserved (privileged) ports 1–1023 have to be started with root privileges in order to bind to their sockets.
On the topic of root privilege, a related security issue has to do with programs which write to temporary files.
Principle 17 (Temporary files). Temporary files or sockets which are opened by any program, should not be placed in any publicly writable directory like /tmp.
This opens the possibility of race conditions and symbolic link attacks. If possible, configure them to write to a private directory.
Users are always more devious than software writers. A common mistake in pro-gramming is to write to a file which ordinary users can create, using a privileged process. If a user is allowed to create a file object with the same name, then he or she can direct a privileged program to write to a different file instead, simply by creating a symbolic or hard link to the other file. This could be used to overwrite the password file or the kernel, or the files of another user. Soft-ware writers can avoid this problem by simply unlinking the file they wish to write to first, but that still leaves a window of opportunity after unlinking the file and before opening the new file for writing, during which a malicious user could replace the link (remember that the system time-shares). The lesson is to avoid making privileged programs write to directories which are not private, if possible.
Before closing this section, a comment is in order. Throughout this chapter, and others, we have been advocating a policy of building the best possible, most logical system by tailoring software to our own environment. Altering absurd software defaults, customizing names and locations of files and changing user identities is no problem as long as everyone who uses and maintains the system is aware of this. If a new administrator started work and, unwittingly, reverted to those software defaults, then the system would break.
Principle 18 (Flagging customization). Customizations and deviations from standards should be made conspicuous to users and administrators. This makes the system easier to understand both for ourselves and our successors.