|< Day Day Up >|
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. You can make a user's login shell restricted by putting rbash in the user's /etc/passwd entry.
The specific constraints imposed by the restricted shell disallow the user from doing the following:
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. 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.
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:
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 ).
|< Day Day Up >|