10.3. System Security Features

UNIX security is a problem of legendary notoriety. Just about every aspect of a UNIX system has some security issue associated with it, and it's usually the system administrator's job to worry about this issue.

bash has two features that help solve this problem: the restricted shell, which is intentionally "brain damaged," and privileged mode, which is used with shell scripts that run as if the user were root.

10.3.1. Restricted Shell

The restricted shell is designed to put the user into an environment where her ability to move around and write files is severely limited. It's usually used for "guest" accounts.^[11] You can make a user's login shell restricted by putting rbash in the user's /etc/passwd entry.^[12]

^[11] This feature is not documented in the manual pages for old versions of bash.

^[12] If this option has been included when the shell was compiled. See Chapter 11 for details on configuring bash.

The specific constraints imposed by the restricted shell disallow the user from doing the following:

• Changing working directories: cd is inoperative. If you try to use it, you will get the error message bash: cd: restricted.

• Redirecting output to a file: the redirectors >, >|, <>, and >> are not allowed.

• Assigning a new value to the environment variables ENV, BASH_ENV, SHELL, or PATH.

• Specifying any commands with slashes (/) in them. The shell will treat files outside of the current directory as "not found."

• Using the exec built-in.

• Specifying a filename containing a / as an argument to the . built-in command.

• Importing function definitions from the shell environment at startup.

• Adding or deleting built-in commands with the -f and -d options to the enable built-in command.

• Specifying the -p option to the builtin command.

• Turning off restricted mode with set +r.

These restrictions go into effect after the user's .bash_profile and environment files are run. In addition, it is wise to change the owner of the users' .bash_profile and .bashrc to root, and make these files read-only. The users' home directory should also be made read-only.

This means that the restricted shell user's entire environment is set up in /etc/profile and .bash_profile. Since the user can't access /etc/profile and can't overwrite .bash_profile, this lets the system administrator configure the environment as he sees fit.

Two common ways of setting up such environments are to set up a directory of "safe" commands and have that directory be the only one in PATH, and to set up a command menu from which the user can't escape without exiting the shell.

10.3.2. A System Break-In Scenario

Before we explain the other security features, here is some background information on system security that should help you understand why they are necessary.

Many problems with UNIX security hinge on a UNIX file attribute called the suid (set user ID) bit. This is like a permission bit (see umask earlier in this chapter): when an executable file has it turned on, the file runs with an effective user ID equal to the owner of the file, which is usually root. The effective user ID is distinct from the real user ID of the process.

This feature lets administrators write scripts that do certain things that require root privilege (e.g., configure printers) in a controlled way. To set a file's suid bit, the superuser can type chmod 4755 filename; the 4 is the suid bit.

Modern system administration wisdom says that creating suid shell scripts is a very, very bad idea.^[13] This has been especially true under the C shell, because its .cshrc environment file introduces numerous opportunities for break-ins. bash's environment file feature creates similar security holes, although the security feature we'll see shortly make this problem less severe.

^[13] In fact, most versions of UNIX intentionally disable the suid feature for shell scripts.

We'll show why it's dangerous to set a script's suid bit. Recall that in Chapter 3, we mentioned that it's not a good idea to put your personal bin directory at the front of your PATH. Here is a scenario that shows how this placement combines with suid shell scripts to form a security hole: a variation of the infamous "Trojan horse" scheme. First, the computer cracker has to find a user on the system with an suid shell script. In addition, the user must have a PATH with her personal bin directory listed before the public bin directories, and the cracker must have write permission on the user's personal bin directory.

Once the cracker finds a user with these requirements, he follows these steps:

• Looks at the suid script and finds a common utility that it calls. Let's say it's grep.

• Creates the Trojan horse, which is this case is a shell script called grep in the user's personal bin directory. The script looks like this:

  cp /bin/bash filename chown root  filename chmod 4755  filename /bin/grep "$@ 
  
  rm ~/bin/grep

  
  

  filename should be some unremarkable filename in a directory with public read and execute permission, such as /bin or /usr/bin. The file, when created, will be that most heinous of security holes: an suid interactive shell.

• Sits back and waits for the user to run the suid shell script—which calls the Trojan horse, which in turn creates the suid shell and then self-destructs.

• Runs the suid shell and creates havoc.

10.3.3. Privileged Mode

The one way to protect against Trojan horses is privileged mode. This is a set -o option (set -o privileged or set -p).

In privileged mode, when an suid bash shell script is invoked, the shell does not run the user's environment file—i.e., it doesn't expand the user's BASH_ENV environment variable.

Since privileged mode is an option, it is possible to turn it off with the command set +o privileged (or set +p). But this doesn't help the potential system cracker: the shell automatically changes its effective user ID to be the same as the real user ID—i.e., if you turn off privileged mode, you also turn off suid.

Privileged mode is an excellent security feature; it solves a problem that originated when the environment file idea first appeared in the C shell.

Nevertheless, we still strongly recommend against creating suid shell scripts. We have shown how bash protects against break-ins in one particular situation, but that certainly does not imply that bash is "safe" in any absolute sense. If you really must have suid scripts, you should carefully consider all relevant security issues.

Finally, if you would like to learn more about UNIX security, we recommend Practical UNIX and Internet Security, by Gene Spafford and Simson Garfinkel (O'Reilly ).