Chapter 5: User Accounts
Sometimes it is desirable to limit what users can do on the system. For example, when users spend all of their time running a single application program, you can make sure they stay there by making that program their login shell (as defined in the password file). Once the login process is complete, that program begins executing, and when they exit from it, they will be automatically logged out.
Not all programs can be used in this way, however. If variable input is required, for example, and there is no single correct way to invoke it, then simply using it as a login shell won't work. UNIX provides a restricted shell to address such problems.
A restricted shell is a modified version of the Bourne or Korn shell. The location of the restricted Bourne shell within the filesystem varies quite a bit:
HP-UX, SCO UNIX: /bin/rsh
AIX, Digital UNIX: /bin/Rsh
IRIX, Solaris: /usr/lib/rsh
The restricted Korn shell is usually /bin/rksh. These files are hard links to the same disk file as the regular shell, but they operate differently when invoked under the alternate names. They are both suitable for creating captive accounts: user accounts that run only an administrator-specified set of actions and log off automatically when they are finished. For example, a captive account might be used for an operator who runs backups via a menu set up by the administrator. Or, a captive account might be used to place users directly into an application program at login. A captive account is set up by specifying the restricted shell as the user's login shell and creating a .profile file to perform the desired actions.
The restricted shell takes away some of the functionality of the normal shell. Specifically, users of a restricted shell may not:
- Use the cd command.
- Set or change the value of the PATH variable.
- Specify a command or filename containing a slash (/). In other words, only files in the current directory can be used.
- Use output redirection (> or >>).
Given these restrictions, a user running from a captive account will have to stay in whatever directory the .profile file places him. This directory should not be his home directory, to which he probably has write access; if he ended up there, he could replace the .profile file that controls his actions. The PATH variable should be set as minimally as possible.
A captive account must not be able to write to any of the directories in the defined path. Otherwise, a clever user could substitute his own version for one of the commands he is allowed to run, allowing him to break free from captivity. What this means in practice is that the user should not be placed in any directory in the path as his final destination, and that the current directory should not be in the search path if it is writable.
Taking this idea to its logical conclusion, some administrators set up a separate rbin directory--often located as a subdirectory of the captive account's home directory - containing hard links to the set of the commands the captive user is allowed to run, and then set the user's search path to point only there. If you use this approach, however, you need to be careful in choosing the set of commands you give to the user. Many UNIX commands have shell escape features: ways of running another UNIX command from within them. For example, in vi you can run a shell command by preceding it with an exclamation point and entering it at the colon prompt. If a command supports shell escapes, the user can generally run any command, including a nonrestricted shell. While the path you set will still be in effect for commands run in this way, the user is not prevented from specifying a full pathname in a shell escape command. Thus, even a command as seemingly innocuous as more can allow a user to break free from a captive account since a shell command may be run from more (and man) by preceding it with an exclamation point.
Be sure to check the manual pages carefully before deciding to include a command among the restricted set. Unfortunately, shell escapes are occasionally undocumented, although this is most true of game programs. In many cases, shell escapes are performed via an initial exclamation point or tilde-exclamation point (~!)
In general, you should be wary of commands that allow any other programs to be run within them, even if they do not include explicit shell escapes. For example, a mail program might let a user invoke an editor, and most editors allow shell escapes.
Disabling and Removing User Accounts
Users come and users go, but it isn't always completely clear what to do with their accounts in the latter case. For one thing, they sometimes come back. Even when they don't, someone else will probably take their place and may need some of the things that were in progress when they left.
When someone leaves--either a computer system or an entire site-it is a good idea to at least disable their account(s) as soon as you are notified. If the person was dismissed or otherwise left under less-than-ideal circumstances, it is imperative that you do so. Disabling an account is one task that you can do very quickly: simply add an asterisk to the beginning of the encoded password in /etc/passwd or the shadow password file, and they will no longer be able to log in. You can then do whatever else needs to be done to retire or remove their account in whatever haste or leisure is appropriate.
Some systems also allow you to lock an account via the account management tools and in some cases from the command line:
# pasawd -1 chavez IRIX, SCO UNIX, Linux
# chuser login=no chavez AIX
Under Digital UNIX and HP-UX 10, an account may be locked by including the u_lock field in the user's protected password database file (without a trailing @ sign).
Disabling or locking an account rather than immediately removing its password file entry prevents file ownership problems that can crop up when a username is deleted.
When it is clear that the user account is no longer needed, the account can be retired or completely removed from the system. A retired account continues to exist as a UID within the user account databases, but no access is allowed through it. C2 and higher security levels require that accounts be retired rather than removed so that UIDs don't get reused and system audit, accounting, and other records remain unambiguous. Systems providing these security levels include account retiring capabilities within their user account management tools.
In the next subsection, we'll look at the process of removing a user account. Many of the activities discussed there will still need to be done when an account is retired rather than removed.
Removing a user account
UNIX implementations offering built-in commands or administrative tools for adding users also usually offer similar commands/facilities for removing them. For example, the following commands may be used to remove user chavez from the password file(s) of the various systems:
# userdel chavez Solaris and the shadow package (Linux)
# rmuser -p chavez AIX
# /tcb/bin/rmuser chavez SCO UNIX
# removeuser Digital UNIX
The SCO UNIX command requires UIDREUSE be set to YES in /etc/default/login, or it won't remove the user....