UNIX Computing Security/Access authorization

Treat your password like your toothbrush. Don't let anybody else use it, and get a new one every six months. —Clifford Stoll

In order to connect to a UNIX-based system and perform activities, a user must have an account. This account must have a unique numerical identifier, which is associated with the account name, or username. The account also has a password, which is string known to the user by which the account access is authenticated when accessing the system. The username and password are normally sufficient to connect a user to the system.

Users can have multiple accounts on the same system, or accounts on different systems. Each account can use a different name, if they are on the same system, or share a common name across multiple systems. Depending on the person or institution operating the systems, the individual users may be able to choose their account names, or they may be assigned a name. Typically an assigned name will be based on the person's actual name, and will be a unique identifier on the system.

Login

The username is also the login name, which means that it is the name that the user types on the keyboard when prompted for a login. On UNIX systems it is a requirement that the first character of the username be an alphabetical character. The case of the character matters: "Joe1234" is a different login name than "joe1234". In most cases the account begins with a lower case character by convention. The remainder of the login name can consist of numbers, alphabetical characters, or an underscore. Thus an asterisk or colon character is invalid for a login name. Accounts with these special characters can cause problems with certain system functions, such as delivering electronic mail. So these characters are usually prohibited on many UNIX systems.

UNIX systems are typically delivered with a set of system accounts for performing special operations. These may include such accounts as root, bin, sys, lp, or uucp. The root account has special capabilities that grant the user enhanced privileges, and so precautions are usually enforced to prevent its acquisition by unauthorized individuals. More on this later.

/etc/passwd

The information for UNIX accounts is stored in a text file located at /etc/passwd. This file contains information for one account per line, and each line is subdivided into fields that are separated by colons. The meaning of the fields is as follows:

login name	Text name of the account
password	The one-way hash encrypted password
user ID	A unique numerical identifier for the account
group ID	The default group identifier for the account
GECOS ID	A comma-separated list of user information
home directory	The users' initial working directory
shell	The program to use for a shell interface

When a user gains an account, they are provided with a default password so that they can login. When they connect to the system they will be prompted for the login name, followed by a prompt for the password. If the system is configured correctly, the user can then enter their provided password and it will not appear on the display when it is typed. (Some systems will print an asterisk for each password character, while others will not show anything.) If the password is valid, the user will be allowed access to the system. (They may be prompted to immediately change their password to something only they know.)

The system stores the password in the /etc/passwd file in an encrypted form. UNIX uses an encryption technique called a one-way hash. This means that the password is encrypted using a technique that that does not have a known decryption method. That is, there is no efficient means to determine the password based on the encryption string.

Each time the user logs on, their input password is encrypted and compared to the encryption in the /etc/passwd file. If the two match then the user is allowed access. If the two do not match then access is refused and the user is prompted again to login. (Each connection allows multiple attempts in case the user accidently types the login name or password incorrectly.) Note that the password is also case sensitive, so accidently forgetting to turn off the caps-lock key may result in access denial.

If there is a format error in the /etc/passwd file, the system commands are unable to read entries further down in the file. If a user is unable to log on to a system, this could be the reason why. (This is why it is important for the root account to always be the first entry, so that the System Administrator can log in and correct issues with the passwd file.) UNIX systems can include a command called pwck that can be run to check for format problems with the passwd file. It is a good idea to run this from time to time to make sure potential problems haven't been introduced.

When editing the /etc/passwd file, the vipw command uses a locking mechanism to prevent another administrator from editing the same file at the same time. (Simultaneous edits can result in changes from one operator overwriting changes from another operator, an unfortunate situation where file locking is not available on multi-user systems.) It is a good habit for all System Administrators to use the vipw command, assuming they are versed in the use of vi.

Selecting a password

Once a user is logged on to a system, they can change their password by means of the passwd command. The user will then be prompted for their current password, then they will be prompted twice for the new password selection. (The redundant prompt is to make sure that the user didn't accidently mistype the new password the first time.) After the new password is accepted, the encrypted password field will be updated in the user's account entry in the /etc/passwd file.

The password is a key element of the system's security that is used to verify a user's identity. For this reason it is vital that the password be selected so that it is difficult to guess. Simple, easily-guessable passwords have frequently been the cause of unauthorized access, and there exist programs that can attempt to gain access to a system through trial and error of commonly selected passwords.

Here are some examples of typical passwords that can make it relatively easy to guess:

• The person's name
• The name of their child
• A birthday
• Simple words such as "guess" or "password"
• A place name
• The person's phone number
• Common keyboard patterns such as "qwerty"
• The name of the computer
• A word spelled backwards
• The same as one of the above followed by a single digit

Modern UNIX systems have security configurations that provide some measure of strength checking when a password is set or changed. For example, a password may be required to be at least eight characters in length, and include one or more upper-case and lower-case letters, a number, and a special character (such as *, $, #, %, &c.) These measures can make a password much more difficult to determine. Wherever possible it is advisable to implement such features to ensure the selection of strong passwords.

When a user has an account on multiple systems, they may choose to use the same password on each of the systems in order to make it easier to remember. Unfortunately this means that if the password on one system is determined by another person, they may be able to gain unauthorized access to the other systems as well. This possibility is difficult for the System Administrator to guard against, except by educating the user and discouraging the use of passwords on multiple systems.

Unauthorized login attempts

Unfortunately there are individuals who may attempt to gain unauthorized access to a system by trying to use another individual's account. They may resort to surreptitious means to obtain the proper login from a user, such as observing them at the keyboard during login, using social engineering to trick an operator or user into giving them access, or by setting up a spoofing program that mimics normal login.

Another method used to obtain unauthorized access is to attempt to guess the login and password. Normally the login is printed on the screen during access, so the individual may already know the account name. However the password should be kept concealed on the screen. If a weak password has been selected by the user, however, it may still be possible to guess the password.

To make the task of guessing a password difficult, most UNIX systems have limits built into the login system. The first limit puts a time delay in between each failed login attempt, so that it takes much longer to attempt each guess. Another limit is to restrict the number of login attempts before disconnecting the session. In addition, the failed login attempts can be recorded in log files, such as btmp. The log files can be periodically checked by the System Administrator to check for unusual failed login activities (such as hundreds of attempts in a day).

Groups

In addition to the account identifiers, UNIX can qualify access to system resources on the basis of group membership. Each group can contain multiple accounts, and an account can belong to one or more groups. An account will have a default group to which they belong, such as users, and this information is stored in the /etc/passwd file.

The newgrp command is used to switch your group without changing your account. As long as the group exists and your account belongs to the group, you will be changed to the selected group name. You would now have access privileges appropriate for that group.

The group is used to manage information or resources that are shared by multiple people. It is normally used to obviate the need for shared accounts, which is considered bad security practice. Wherever possible the System Administrator should require the use of a group for providing access to shared resources, and avoid the use of a shared account. There are two reasons for this. The first is that it is nearly impossible to track or audit the activities of an individual who is a member of a shared account. The second is that it is much more difficult to terminate access by a specific individual to a shared account.

/etc/group

The information for UNIX groups is stored in a text file located at /etc/group. This file contains information for one group per line, and each line is subdivided into fields that are separated by colons. The meaning of the fields is as follows:

group name	Text name of the group
password	The one-way hash encrypted password
group ID	The default group identifier for the account
members	A comma-separated list of group names

To belong to additional groups beyond the default, an account must be added to the appropriate members list. Here is a brief example of an /etc/group file:

 root::0:root
 other::1:root
 bin::2:bin
 users::20:
 secrets::30:billy_bob,sally_sue,frederick

Each line in the file describes a group. In this example, the accounts billy_bob, sally_sue, and frederick are all members of the group secrets, even though their default group is users. Note that if a group has a password, a user can use the password to change to that group even if he or she is not a member.

As with the pwck command for the /etc/passwd file, there is usually a grpck command available that can be used to check the format of the /etc/group file. It is good practice to use this command to check that format errors have not been introduced.

Identifiers

UNIX uses integer values to track and store access information. The user identifier, or uid, is an identifier that corresponds to a user's account on a UNIX system. This identifier is used internally by the system to determine ownership of potentially sensitive data and processes. When the system needs to list the owner of a data file or process, it normally maps the identifier back to the account name in the /etc/passwd file before presenting the information.

The value of the uid can typically range from 0 up to one less than the maximum integer supported on the system. (Negative identifiers, particularly -2, are for special purpose use only.)

User identifiers are usually assigned beginning with 100, and each new account is added by assigning a previously unused identifier. When an account is deleted for some reason, the account entry is removed from the /etc/passwd file. However this may result in files created by that account having an unassigned uid. A new account created subsequently may be assigned the previous uid, making that new user the owner of the files created by the previous account. In order to prevent this eventuality, the System Administrator needs to perform periodic maintenance to locate files that lack a valid account.

Default accounts

During the initial installation of a system, the vendor media can load selected default accounts. These accounts are generally used for system administration and maintenance. By convention the user identifiers 0 through 99 are nearly always reserved for these accounts, such as root, daemon, bin, sys, and so forth. In many instances, most of these accounts have their passwords disabled, and the uid is used for system files or processes.

The root account in particular, which has a uid of zero (0), is a special account that has higher privileges than any user. It is often referred to as the superuser account. Special precautions need to be taken to prevent inappropriate individuals from gaining access to this account, and much of the security-related configuration of a UNIX system is intended to prevent this eventuality.

In certain environments it may be necessary for certain administrative capabilities to be shared among more than one operator. The drawback to this, of course, is that becomes more difficult to maintain a secure system when multiple people have superuser access. It can also make it more difficult to perform a root-cause analysis when something on a system breaks.

There are several methods to help reduce the risk of a shared superuser access, although it can never be reduced to zero. The first is to configure a system so that the root account can not be accessed directly. Instead the operator must log on using their user account, then su (switch-user) to the superuser account. This can provide an audit trail of when the superuser account was accessed and by whom. It also helps to insulate the system from attempts to break into the superuser account directly. Instead a user account must first be compromised, and then the superuser account.

A more sophisticated approach to limiting the superuser account access requirement is through the use of role-based access control. This allows designated user accounts to perform a limited set of actions that are normally restricted to the root account. (An example of this would be a trusted user account that is allowed to make revisions to a server's printer configuration.) There are a number of tools available, both in open source and from vendors, that can be used to provide role-based access control capabilities. This topic will be covered in more detail in later chapters.

Shadow password file

While a user's password is stored as an encrypted string on UNIX systems, anybody who can read the encrypted value may be able to use a program to test various commonly-used passwords and see if they match. That is, the program can try a series of guesses and encrypt them to see if they match the value in the user's password field. The program can also use a dictionary of words and encrypt each one and compare them in turn to each encrypted password on a system.

To make this task somewhat more difficult for a password guessing program, the encrypted password includes a random, two-character "salt". This random salt value will most likely result in a different encryption string value even when the passwords for two accounts match. As a result the program must recompute the encryption string for each guess and for every account. Nonetheless a modern UNIX system can still crunch through a large number of guesses in a relatively short amount of time, making a brute-force attack quite feasible on a system where a password consists of a simple word.

When the password is formed using a rule, such as two words separated by a number, the task becomes slightly more difficult. However a wily individual may have considerable computing resources at his or her disposal, so guessing a weak password may just be a matter of time. (An example of such a program is called crack, which can be used by the System Administrator to periodically check their user's passwords for guessable values.)

In order to forestall this technique, the encrypted passwords can be stored in a separate file, commonly known as the shadow password file. The contents of the shadow password file can only be read by the root account, and the password field of the /etc/passwd file is replaced by an asterisk. The implementation of this feature will vary depending on the UNIX vendor. The shadow password is located at /etc/shadow on Sun systems and under /tcb on HP-UX systems. With the encrypted password "shadowed" in this manner, the task of guessing a password is rendered much more difficult.

Account management

Under construction...

• Paperwork & records
• Modifying passwords
• Password aging
• Disabling accounts