Classic Shell Scripting - Arnold Robbins [222]
ksh93 and Privileged Mode
The Korn shell's privileged mode was designed to protect against setuid shell scripts. This is a set -o option (set -o privileged or set -p), but the shell enters it automatically whenever it executes a script whose setuid bit is set; i.e., when the effective user ID is different from the real user ID.
In privileged mode, when a setuid Korn shell script is invoked, the shell runs the file /etc/suid_profile. This file should be written to restrict setuid 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). However, 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 setuid.
In addition to privileged mode, ksh provides a special "agent" program, /etc/suid_exec, that runs setuid shell scripts (or shell scripts that are executable but not readable).
For this to work, the script should not start with #! /bin/ksh. When the program is invoked, ksh attempts to run the program as a regular binary executable. When the operating system fails to run the script (because it isn't binary, and because it doesn't have the name of an interpreter specified with #!), ksh realizes that it's a script, and invokes /etc/suid_exec with the name of the script and its arguments. It also arranges to pass an authentication "token" to /etc/suid_exec, indicating the real and effective user and group IDs of the script. /etc/suid_exec verifies that it is safe to run the script and then arranges to invoke ksh with the proper real and effective user and group IDs on the script.
Although the combination of privileged mode and /etc/suid_exec allows you to avoid many of the attacks on setuid scripts, writing scripts that safely can be run setuid is a difficult art, requiring a fair amount of knowledge and experience. It should be done carefully.
Although setuid shell scripts don't work on modern systems, there are occasions when privileged mode is still useful. In particular, there is a widely used third-party program named sudo, which, to quote the web page, allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while logging the commands and arguments. The home page for sudo is http://www.courtesan.com/sudo. A system administrator could easily execute sudo /bin/ksh -p in order to get a known environment for performing administrative tasks.
Summary
Writing secure shell scripts is just one part of keeping a Unix system secure. This chapter merely scratches the surface of the issues involved, and we recommend reading up on Unix system security. As a beginning, we presented a list of tips for writing secure shell scripts provided by a recognized expert in the field of Unix security.
We then described restricted shells, which disable a number of potentially dangerous operations. The environment for a restricted shell should be built within the user's .profile file, which is executed when a restricted user logs in. In practice, restricted shells are difficult to set up correctly and use, and we recommend finding a different way to set up restricted environments.
Trojan horses are programs that look harmless but that actually perform an attack on your system. We looked at some of the ways that Trojan horses can be created, but there are others.
Setuid shell scripts are a bad idea, and just about all modern Unix systems disallow them, since it's very difficult to close the security holes they open up. It is worth