UNIX Computing Security/Securing accounts

Suggested topics: shell environment, password aging, password strength, dot files, restricted shells, dormant accounts, secure terminals and root access.

---

"Just because you're paranoid, doesn't mean they're not out to get you." —Anon.

The users of a Unix system are most likely not nearly as knowledgeable about the security aspects of their system as are the System Administrators. So it is important to use the configuration capabilities of the system to configure these accounts so that they are reasonably secure. Such configuration can be applied to the default user security settings, the environments in which programs will be run, and so forth. There may also be special restrictions needed for certain accounts depending on access and data security requirements on the server.

Once an account is in use, the System Administrator will still need to employ a certain level of vigilance to make certain the access is not abused, or even coopted by an inappropriate person. Passwords need to be checked for strength and periodically updated. Unused or unneeded accounts need to be disabled so that they are not employed for inappropriate purposes.

Home directory

When an account is first created, it is normally given a separate home directory. This is a directory, usually under the /home or possibly the /user directory tree where the user can store their data files and where custom startup and configuration files are located. (These can include .profile, .login, .cshrc, and so forth.)

The home directory should be protected in such a manner that the user owns it and the group identifier of the directory matches the account's default group. In addition the home directory is normally given permissions that restrict access by other users. Permission modes of 750 or 700 are common.

Many System Administrators provide a default set of startup, or "dot" files that are copied into the new home directory. These can provide, for example, useful aliases and site-specific operations. However these default files need to be properly secured or else they may be tampered with and any new accounts quickly compromised.

Missing home directories

In cases where the home directory does not exist for a particular user account, the default action on many Unix systems is to start the login session at the top-level, or slash (/) directory. This is also the default directory for the root (super-user) account. So this can potentially lead to permissions problems with the startup configuration files, and other unexpected behavior.

As a remedy for this case, the home directory for the root account can be located under its own directory tree. (For example, /root). Normally this directory should be placed on the same file system as slash so that the directory is always present when the system is booted. Having a private directory for root also provides a somewhat more secure location for any tools and scripts the System Administrator might want to run.

Once a private root home directory is implemented, the System Administrator can then modify the "dot" files under the slash directory and use them to provide a default set of startup files for their users.

Note that having a user log in using a home directory of slash is generally not a good idea, and it is often indicative of a problem with the system. Some versions of Unix provide a means of disabling user logins whenever their home directory is not found.

Shell environment

Many of the shells available for use on Unix systems allow environmental variables to be configured. Some of these variables can have security implications, and a few can be configured to enhance the system security.

Session timeout

When a Unix session is left unattended for a period of time, it only takes a few moments for an unscrupulous individual to take advantage of the situation to increase their own access privileges. For example, suppose that a System Administrator has walked away from their desk for a minute and a person types in a few commands at the shell prompt:

root$ touch /tmp/rubbish
root$ chmod 4777 /tmp/rubbish
root$ exit

This creates a world-editable file that can be modified to run commands that can grant root privileges to anybody executing it. That individual now owns the system. It is for situations like this that it is important for unattended sessions to either be locked down or disconnected.

Certain shell types, including the Korn Shell, Bash, and some vendor versions of the Bourne Shell, will support a time out variable, either TMOUT or TIMEOUT. When this variable is set it gives the number of seconds of no activity before the shell expires. (A value of zero means no timeout.) This variable can be used to expire shells when a user or system administrator is drawn away from active login session for a period of time. Typically this variable would be set to some value, such as 300 (or 5 minutes), that will limit the period of vulnerability. It is normally set in a global shell startup file such as /etc/profile or /etc/csh.login.

PATH

Unix shell sessions use an environment variable called PATH to determine the location of commands and other programs that can be executed from the shell command line. This variable is set to a colon-separated list of valid directories on the system. When a command is typed at the shell prompt, the system searches through each of the directories in the PATH looking for a program with a matching name. When a match is found the search ceases and the program is executed. (For reasons of efficiency, the directory path to recently executed commands can get stored in a cache.)

$ echo $PATH
/usr/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:.

In Unix a single period within the path name (.) or an empty entry (::) is used to represent the current working directory. Suppose an account contains just such a period in its PATH variable, and the user decides to execute a command. If the command was not located in one of the directories listed prior to the period, the system will then check the user's current working directory for a matching file. If it is found, the system will then attempt to execute the file. As the user's current working directory may be anywhere on the system where the account has access permissions, it is easy to see why this may pose a security problem.

This potential vulnerability is particularly true for the root account. Suppose root has a period at the start of their PATH variable, then a user calls up to report a problem in their home directory. It would be normal for the System Administrator to change directory to the user's home location and perform a directory listing using the ls command. However if the user has placed a file called ls in their home directory, the system will then try to execute it. This file could easily be a shell script that exploits the permissions of the root account to grant the user enhanced permissions, then simply replicates the actions of the ls call. The System Administrator might never even be aware of the inappropriate activity.

For this reason it is important that the root account in particular never have a period in its PATH variable. Note that if the value of the PATH variable begins or ends with a period, the system will treat this just like a period. So, in addition, the root PATH variable should never begin or end with a colon, or have two colons next to each other with no directory in between. In any event it is often preferable for the System Administrator to type in the full command path rather than relying on the system.

If it is necessary for a user's PATH variable to include a period, it should be placed at the very end of the PATH. This will cause the system to check all of the standard directories containing executables before trying the current working directory. Setting the PATH in the shell startup script, such as /etc/profile, or in the /etc/PATH file on some vendor releases, can help the System Administrator manage the use of the PATH variable for most user accounts.

Another concern with the PATH variable is whether any of the directories in the PATH allow user's to modify the contents. The permissions on the directories in the PATH should all restrict write permissions, and all files within those directories should not allow write permissions. Otherwise an unscrupulous user can modify one or more of the commands, and expect other users and even root to execute their modified file. Periodic checks of the permissions on these directories and files is necessary to help maintain a secure system.

Dot files

These files are normally located in the home directory of an account and contain various startup and configuration settings and procedures. These are of interest to the System Administrator because in certain cases they can introduce weaknesses into the security of a Unix system.

An alert System Administrator will regularly search their system for the presence of these files, then check the permissions and contents for potential security issues. In addition to improper settings added by users, the files may be modified by an intruder so that they can regain access at some future date.

.forward

The sendmail program includes support for this file that is intended to forward e-mail messages to a new address (after a user has relocated their account, for example). The contents of this file can contain a comma-separated list of addresses. The problem with regard to security, however, is that an address can also be a system command. For example:

sample_address@no.such.com, "|/var/tmp/give_me_access"

When an e-mail message arrives, it is forwarded to the addresses in the .forward file. It is also passed as standard input to the program listed in strings. This could, for example, be a script written by the user to execute commands contained within the mail message.

It may be common practice to initially disable a user account by disabling the password. However if the user has configured their .forward file to execute a command, they can still perform actions on the system. An unscrupulous individual may exploit this access for inappropriate activities.

ForwardPath

Beginning with version 8 of the sendmail program, the ForwardPath option can be used to define alternate locations for the .forward file. The ForwardPath option is set in the sendmail configuration by means of the OJ line (or "O ForwardPath="). For example:

OJ/var/forward/$u.forward:$z/.forward

This will cause sendmail to first check for a file under a /var/forward directory with the name of the user's account followed by a .forward. (Thus bob.forward would be interpreted as the .forward file for the user account named bob.) If the file is not found, then sendmail will check for a .forward file in the user's home directory.

Whenever a new user account is created, the System Administrator can then create a account.forward file in the controlled directory. (This can be automated as part of the account creation tools.) After the user has established that they are sufficiently well-trained with UNIX to properly configure their own .forward file, the account.forward file can be removed.

.netrc

Users may want to use the ftp command for, say, batch downloads of files from a remote site. In order to automate this process, they can configure a .netrc file to provide access without the need to input a password. Once this is done, a script can be run to transfer files using, say, a scheduled batch task. Unfortunately the format of the .netrc file stores the password in plain text. Anybody who has read access to the .netrc file can also obtain the user's login password.

The ftp process has a built-in restriction that partially alleviates this problem. If the user's .netrc file can be read by anybody except the owner, the automatic login process will fail. This serves to force the owner to restrict the permissions on this file. However this is only a partial solution. A preferable approach for most purposes would be to use the host authentication method of the sftp command instead.

More recently, the cURL library has allowed to use the .netrc file with all protocols.

.rhosts

The .rhosts file can provide an autologin capability for a user when running the remote login command (usually rlogin.) This bypasses the normal login process and immediately connects the user with the system. As you'd expect, this capability can introduce a number of potential vulnerabilities to a system.

Suppose that three systems are set up so that A has a trust relationship with B, but A does not necessarily trust C. The establishment of .rhosts for an account to connect between A—B and B—C, can provide a back door for an individual to get from C to A. That is, somebody who manages to obtain inappropriate access to C can use the .rhosts file to obtain access to A, even though C is not trusted by A (and may even have network access blocked).

Another issue with the .rhosts file is the method used to enter the allowed account access. The file can be set up to allow access from any host. For example:

+ joebob

will allow the account joebob to connect from any host without entering a password. Unfortunately, the account may belong to an entirely different person on another system, or it could be deliberately established on a compromised system to allow inappropriate access.

Due to the security dangers inherent in its use, it is usually better to disable the .rhosts capability where possible.