System Security Features (Learning the Korn Shell, 2nd Edition)

10.4. System Security Features

NOTE: This is not a textbook on Unix system security. Be aware that this section merely touches the tip of the iceberg and that there are myriad other aspects to Unix system security besides how the shell is set up. See the end of the chapter for one book that we recommend.

We first present a list of "tips" for writing shell scripts that have a better chance of avoiding security problems. Next we cover the restricted shell, which attempts to put a straitjacket around the user's environment. Then we present the idea of a "trojan horse," and why such things should be avoided. Finally we discuss the Korn shell's privileged mode, which is used with shell scripts that run as if the user were root.

10.4.1. Tips for Secure Shell Scripts

Here are some tips for writing more secure shell scripts, courtesy of Professor Eugene (Gene) Spafford, the director of Purdue University's Center for Education and Research in Information Assurance and Security:[142]

[142] See http://www.cerias.purdue.edu.

Don't put dot in PATH

This issue was described in Chapter 3. This opens the door wide for "trojan horses," described in the next section.

Protect bin directories

Make sure that every directory in $PATH is writable only by its owner and by no one else. The same applies to all the programs in the bin directories.

Design before you code

Spend some time thinking about what you want to do and how to do it; don't just type stuff in with a text editor and keep hacking until it seems to work. Include code to handle errors and failures gracefully.

Check all input arguments for validity

If you expect a number, verify that you got a number. Check that the number is in the correct range. Do the same thing for other kinds of data; the shell's regular expression facilities are particularly useful for this.

Check error codes from all commands that can return errors

Things you may not expect to fail might be mischievously forced to fail to cause the script to misbehave. For instance, it is possible to cause some commands to fail even as root if the argument is a NFS-mounted disk or a character-oriented device file.

Don't trust passed-in environment variables

Check and reset them to known values if they are used by subsequent commands (e.g., TZ, FPATH, PATH, IFS, etc.). The Korn shell automatically resets IFS to its default upon startup, ignoring whatever was in the environment, but many other shells don't. In all cases it's an excellent idea to explicitly set PATH to contain just the system bin directories.

Start in a known place

Explicitly cd to a known directory when the script starts so that any subsequent relative pathnames are to a known location. Be sure the that cd succeeds:

cd app-dir || exit 1

Use full pathnames for commands

Do this so you know which version you are getting, regardless of $PATH.

Use syslog(8) to keep an audit trail

Log the date and time of invocation, username, etc.; see logger(1). If you don't have syslog, create a function to keep a log file:

function logsys {
   print -r -- "$@"  >>  /var/adm/logsysfile
}
logsys "Run by user "  $(/bin/whoami)  "($USER) at "  $(/bin/date)

(whoami(1) prints the login name of the effective user ID, a concept described later in this chapter.)

Always quote user input when using that input

E.g., "$1" and "$*". This prevents malicious user input from being further evaluated and executed.

Don't use eval on user input

Beside quoting user input, don't hand it to the shell to reprocess with eval. If the user reads your script and sees that it uses eval, it's easy to subvert the script into doing almost anything.

Quote the results of wildcard expansion

There are several nasty things you can do to a system administrator by creating files with spaces, semicolons, back-quotes, and so on in the filenames. If administrative scripts don't quote the filename arguments, the scripts can trash -- or give away -- the system.

Check user input for metacharacters

Look for metacharacters such as $ or ` (old-style command substitution) if using the input in an eval or $(...).

Test your code and read it critically

Look for assumptions and mistakes that can be exploited. Put yourself into a nasty mood, and read your code with the intent of trying to figure out how to subvert it. Then fix whatever problems you find.

Be aware of race conditions

If an attacker can execute arbitrary commands between any two commands in your script, will it compromise security? If so, find another way to do it.

Suspect symbolic links

When chmoding or editing a file, check it to be sure it is a file and not a symbolic link to a critical system file. (Use [[ -L file ]] or [[ -h file ]] to test if file is a symbolic link.)

Have someone else review your code for mistakes

Often a fresh pair of eyes can spot things that the original author of a program misses.

Use setgid instead of setuid, if possible

These terms are discussed later in this chapter. In brief, by using setgid, you restrict the amount of damage that can be done to the group that is compromised.

Use a new user instead of root

If you must use setuid to access a group of files, consider making a new, non-root user for that purpose, and setuid to it.

Limit setuid code as much as possible

Make the amount of setuid code as small as you can. Move it into a separate program, and invoke that from within a larger script when necessary. However, be sure to code defensively as if the script can be invoked by anyone from anywhere else!

Chet Ramey, the maintainer of bash, offers the following prologue for use in shell scripts that need to be more secure:

# reset IFS, even though ksh doesn't import IFS from the environment,
# $ENV could set it
IFS=$' \t\n'

# make sure unalias is not a function, since it's a regular builtin
# unset is a special builtin, so it will be found before functions
unset -f unalias

# unset all aliases
# quote unalias so it's not alias-expanded
\unalias -a

# make sure command is not a function, since it's a regular builtin
# unset is a special builtin, so it will be found before functions
unset -f command

# get a reliable path prefix, handling case where getconf is not
# available (not too necessary, since getconf is a ksh93 built-in)
SYSPATH="$(command -p getconf PATH 2>/dev/null)" 
if [[ -z "$SYSPATH" ]]; then
        SYSPATH="/usr/bin:/bin"         # pick your poison
fi
PATH="$SYSPATH:$PATH"

10.4.3. Trojan Horses

The concept of a trojan horse was introduced briefly in Chapter 3. A trojan horse is something that looks harmless, or even useful, but which contains a hidden danger.

Consider the following scenario. User John Q. Programmer (login name jprog) is an excellent programmer and has quite a collection of personal programs in ~jprog/bin. This directory occurs first in the PATH variable in ~jprog/.profile. Since he is such a good programmer, management recently promoted him to system administrator.

This is a whole new field of endeavor, and John -- not knowing any better -- has unfortunately left his bin directory writable. Along comes W. M. Badguy, who creates the following shell script, named grep, in John's bin directory:

/bin/grep "$@"
case $(whoami) in                  Check effective user ID name
root)    nasty stuff here          Danger Will Robinson, danger!
         rm ~/jprog/bin/grep       Hide the evidence
         ;;
esac

In and of itself, this script can do no damage when jprog is working as himself. The problem comes when jprog uses the su(1) command. This command allows a regular user to "switch user" to a different user. By default, it allows a regular user to become root (as long as that user knows the password, of course). The problem is that normally, su uses whatever PATH it inherits.[143] In this case, $PATH includes ~jprog/bin. Now, when jprog, working as root, runs grep, he actually executes the trojan horse version in his bin. This version runs the real grep, so jprog gets the results he expects. But it also silently executes the nasty stuff here part, as root. This means that Unix will let the script do anything it wants to. Anything. And to make things worse, by removing the trojan horse when it's done, there's no longer any evidence.

[143] Get in the habit of using su - user to switch to user as if the user were doing a real login. This prevents the importing of the existing PATH.

Writable bin directories open one door for trojan horses, as does having dot in PATH. Having writable shell scripts in any bin directory is another door. Just as you close and lock the doors of your house at night, you should make sure that you close any doors on your system!

10.4. System Security Features

10.4.1. Tips for Secure Shell Scripts

10.4.2. Restricted Shell

10.4.3. Trojan Horses

10.4.4. Setuid and Privileged Mode