10.3.1 Restricted Shell

The restricted shell is designed to put the user into an environment where his or 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 rksh or ksh -r in the user's /etc/passwd entry.

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 "ksh: cd: restricted".

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

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

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

These restrictions go into effect after the user's .profile and environment files are run.

This means that the restricted shell user's entire environment is set up in .profile. Since the user can't overwrite that file, this lets the system administrator configure the environment as he or she 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 above): 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. [5] This has been especially true under the C shell, because its .cshrc environment file introduces numerous opportunities for break-ins. The Korn shell's environment file feature creates similar security holes, although the security features we'll see shortly make this problem less severe.

[5] In fact, some 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 combines with suid shell scripts to form a security hole: a variation of the infamous "Trojan horse" scheme.

For this particular technique to work, 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 his or 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 or she does the following:

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

• Creates the Trojan horse: a shell script called grep in the user's personal bin directory that looks like this:

  cp /bin/ksh 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 Tracked Aliases

The Korn shell protects against this type of scheme in two ways. First, it defines tracked aliases (see Chapter 3) for just about all commonly-used utilities: ls, mv, cp, who, grep, and many others. Since aliases take priority over executable files, the alias will always run instead of the Trojan horse.

Furthermore, the shell won't let you know about these if you type alias -t to see all tracked aliases. [6] You'll have trouble finding a command to use as your Trojan horse if you want to break in. This is a very clever-and undocumented-security feature.

[6] Unless you type whence -v command or type command. If command has a tracked alias, this will say so, and it will cause alias -t to report it next time.

10.3.4 Privileged Mode

The second type of protection against Trojan horses is privileged mode. This is a set -o option (set -o privileged or set -p), but the shell enters it automatically whenever it executes a script whose suid bit is set.

In privileged mode, when an suid Korn shell script is invoked, the shell does not run the user's environment file-i.e., it doesn't expand the user's ENV environment variable. Instead, it runs the file /etc/suid_profile.

/etc/suid_profile should be written so as to restrict suid shell scripts in much the same way as the restricted shell does. At a minimum, it should make PATH read-only (typeset -r PATH or readonly PATH) and set it to one or more "safe" directories. Once again, this prevents any decoys from being invoked.

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. Tracked aliases make protection against Trojan horses even stronger.

Furthermore, both features are strong arguments for installing the Korn shell as /bin/sh. Your system will be all the more impervious to break-ins if your standard shell has these security features.

Nevertheless, we still recommend against creating suid shell scripts. We have shown how the Korn shell protects against break-ins in one particular situation, but that certainly does not imply that the Korn shell 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 the O'Reilly & Associates Nutshell Handbook, Practical UNIX Security, by Gene Spafford and Simson Garfinkel.