Classic Shell Scripting - Arnold Robbins [220]
Turning off restricted mode with set +r or set +o restricted
For both shells, 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. This lets the system administrator configure the environment as she sees fit.
To keep the user from overwriting ~/.profile, it is not enough to make the file read-only by the user. Either the home directory should not be writable by the user, or the commands in ~/.profile should cd to a different directory.
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. In any case, make sure that there is no other shell in any directory listed in $PATH; otherwise, the user can just run that shell and avoid the restrictions listed earlier. Also make sure that there isn't any program in $PATH that allows the user to start a shell, such as a "shell escape" from the ed, ex, or vi text editors.
* * *
Warning
Although the ability to restrict the shell has been available (if not necessarily compiled in or documented) since the original Version 7 Bourne shell, it is rarely used. Setting up a usable yet correctly restricted environment is difficult in practice. So, caveat emptor.
* * *
Trojan Horses
A Trojan horse is something that looks harmless, or even useful, but that contains a hidden danger.
Consider the following scenario. User John Q. Programmer (login name jprog) is an excellent programmer, and he 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 by other users. 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 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.[2] 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. More importantly, 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.
Writable bin directories open one door for Trojan horses, as does having dot in PATH. (Consider what happens if root does a cd to a directory containing a Trojan script, and dot is in root's PATH before the system directories!) 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!
* * *
[2] Get in the habit of using su - user to switch to user as if the user were doing a real login. This prevents import of the existing PATH.
Setuid Shell Scripts: A Bad Idea
Many problems with Unix security hinge on a Unix file attribute called the setuid (set user ID) bit. This is a special permission bit: when an executable file has it turned on, the file runs with an effective user ID equal to the owner of the file. The effective user ID is distinct