Chapter 7. Administering Identification and Authentication
Prev |  | Next

## Chapter 7. Administering Identification and Authentication

In order to ensure that the users on your system are the same people who have been entrusted to use it properly, Identification and Authentication (I&A) requirements have been implemented. Further, in the unlikely event that an individual user breaks a security policy, that user must be held strictly accountable for his or her actions. Holding the owner of a user account responsible for the actions taken with that account is reasonable only if steps have been taken to ensure that the individual using that account is in fact the individual assigned to the account. B1-level systems are required to implement certain facilities to ensure that users are adequately identified and that they authenticate themselves to the system with a password. To log in, the user must know:

- A valid login name for the system

- The password associated with that login name

Because these items are all that is needed to gain access to a trusted system, these pieces of information are closely guarded, and created and maintained according to strict procedures outlined in this chapter. Of the two items of information, the most crucial is the account password. The login names are known to many people, or can easily be determined. It is possible to log in without specifying a label if the default label has been set, but the password is absolutely necessary. If a password is compromised or stolen, all information that is available to the user associated with the password is also compromised.

Sections in this chapter include:

- “Administering Passwords”

- “Login Process with the CMW Dialog”

- “Login Process with Telnet or Serial Terminals”

## Administering Passwords

Passwords are the only mechanism available to authenticate your users. Once Trusted IRIX/CMW has accepted a user's password as valid, that user has access to all files available at his or her clearance for the duration of the login session.

The dangers involved when passwords are compromised cannot be overstated. An intruder can access all files available to the user at any time. Other features of Trusted IRIX/CMW make it likely that an intruder would be swiftly identified and locked out, but a tremendous amount of damage can take place in a short time if the accountability and Identification and Authentication procedures are not followed.

Many features taken for granted in standard IRIX are restricted in Trusted IRIX/CMW. In the area of user passwords, there are facilities to force the user to choose a system-generated password (which is random and difficult to guess). The length of time that this password is valid can be specified (with both a minimum and maximum lifetime), and the encrypted password is not visible to users. When an encrypted password is visible, a potential intruder may copy it and attempt to break the encryption.

Also in Trusted IRIX/CMW, if you choose to allow users to select their own passwords, a strict set of checks are performed on the passwords to disallow passwords without enough variation in the characters used. For example, all passwords must use a combination of letters, numerals, and control characters.

### Password Aging

Trusted IRIX/CMW supports password aging. Password aging is defined as being able to set a minimum and maximum lifetime for passwords. Standard IRIX also supports this feature, and it is described in detail in the guide titled IRIX Admin: Backup, Security, and Accounting.

Password aging is a very useful feature. By limiting the amount of time a password may be in use, you limit the amount of time a potential interloper has to crack the password. By enforcing a minimum password lifetime, you prevent lazy users from simply changing their password briefly and then returning to their usual password immediately. If a user does not change their password within the specified time period, the user is forced to change the account password when they next try to log in.

Generally, the only time that an account becomes locked is when the user is away for an extended period of time. But once locked, an account can be unlocked only by the superuser or system administrator. When the account is locked, the encrypted password is replaced by this string:

    *LK*

To unlock the account, the system administrator uses the `dbedit` utility to remove the string from the password field for that account. Then, the system administrator should force the user to choose a new password by executing this command:

    passwd -f username

Password aging is enforced for a particular user if his or her encrypted password in the `/etc/shadow` file is followed by a colon and a non-null string of characters from the 64-character alphabet:

    . / 0-9 A-Z a-z

The first character of the entry, Maximum, denotes the maximum number of weeks for which a password is valid. A user who attempts to log in after his or her password has expired is forced to change the password. The next character, minimum, denotes the minimum period in weeks that must pass before the password may be changed. If the second character is omitted, zero weeks is the default minimum. M and m have numerical values in the range 0-63 which correspond to the 64-character alphabet shown above (for example, / = 1 week; z = 63 weeks). If minimum = Maximum = 0 (derived from the string . or ..) the user is forced to change the password at the time of the next login (and the “age” disappears from the entry in the `/etc/shadow` file). If minimum > Maximum (signified, for example, by the string ./) only the system administrator can change the password. This is often done for accounts that are used for uucp logins. For example, the following command disallows the user from changing the password:

    passwd -x1 -n10 nuucp

For complete information on how to put an age limit on a user's password, consult the `passwd`(1) reference page.

### Administering Password Generation

Several options are available to the security officer when deciding on your password generation policy. You may allow users to select their own passwords, or your may choose to install a custom password generator. If you have a custom password generator you wish to use, it is subject to the following constraints:

- The system administrator is willing to accept the risk of using an unevaluated configuration.

- The new program should be placed in the `/sbin` directory and renamed `passwd_gen`.

- The owner of the file must be `root`.

- The group of the file must be `sys`.

- The DAC permission of the file must be 555 (-r-xr-xr-x).

- The security label of the file must be `dblow`.

- The `/etc/default/passwd` file is created or updated to specify the location of `passwd_gen`, for example, `PASSGEN=/sbin/passwd_gen`. For more information see the `passwd`(1) man page.

- The security label of `/etc/default/passwd` must be `dblow`.

- Your system is no longer running the evaluated software configuration.

Additionally, any custom password generation program must generate a set of passwords in the following format: one password per line, separated by a single new line character.

If you do not use a password generation program at your site, users are free to select their own passwords, subject to the following triviality checks:

- Each password must have at least six characters. However, only the first eight characters are significant.

- The password must contain at least two alphabet characters and one numeric character.

- The password must not be related to the user's login name. Any reversing or circular shift of the characters in the login name are not allowed. For the purposes of this test, capital letters are assumed to be equivalent to their lowercase counterparts.

- The password must have at least three characters different from the previous password. For the purposes of this test, capital letters are assumed to be equivalent to their lowercase counterparts.

## Login Process with the CMW Dialog

The process of logging in to a Trusted IRIX/CMW system is more complicated than meets the eye. Many activities go on within the operating system that are configurable through the `login.options` file.

When no one is logged in to a Trusted IRIX/CMW system, the system displays the CMW login dialog and waits for a user to enter a login name.

1. The trusted path window is displayed on the screen as shown in Figure 7-1, and the trusted path should be initialized “on:”

   Figure 7-1. Trusted Path Window

   If the trusted path is not on, the user should move the mouse cursor to the top button on the trusted path menu and click. If the trusted path window does not indicate that the trusted path is on, the user should call the system administrator. The user should move the pointer to the CMW Login Dialog window. The trusted path window should state “You Are On The Trusted Path.” If it does not state that the user is on the trusted path, the user should call the system administrator.

2. On the CMW Login Dialog window, the user should see the `User Name:` prompt as shown in Figure 7-2:

   Figure 7-2. CMW Login Dialog Window

   The user must enter the desired account name; there is no default.

3. The user is prompted for a MAC label:

       MAC Label:

   If no MAC label name is entered (that is, the user simply presses the `Enter` key) the user is given his or her default login label.

4. The user is prompted for a capability set:

       Capabilities:

   If no capability set is entered (that is, the user simply presses `Enter`), the user is given the account's default capability set.

5. The user is prompted for a password:

       Password:

   The password is not displayed as it is typed in. The user should press the `Enter` key when finished typing a password.

6. If all responses were valid, the user is logged in. The screen clears and the default windows and icons are displayed. The login process is now complete. The`.sgisession` file executes.

The password step can be eliminated from the login process if the user has no password set and the following string appears in the `login.options` file:

    passwdreq=0

This means that a user who does not have an initial password set does not have to create one or enter any password to log in. Obviously, this is a highly insecure practice, and you should not allow it on your system.

It is recommended that you have `passwdreq` set to 2 on your system at all times. The effect of setting `passwdreq` to 2 is described below. However, even if passwords are not required on a particular system, any user who maintains a password on his or her account must enter it at login time. Regardless of whether passwords are required, the system does not allow access to a password account without receiving the correct password.

If the string `passwdreq=1` appears in the `login.options` file, passwords are always required on the system and a user without a password is prompted to choose one immediately. This is the default behavior for the Trusted IRIX/CMW system.

If the `passwdreq` line reads `passwdreq = 2` then a user without a password already set is not allowed access and the system administrator must create a password for the user before he or she can log in.

Assuming that the user enters the correct password, no other user input is required to complete the login process. If the password or any previous entry was incorrectly entered, the system responds with the following message and the login process is aborted:

    Login incorrect. Try again.

If the account is new and has no password and passwords are required, the user sees this prompt:

    Enter New Password:

At this time, the user is forced to enter a password before being allowed to complete the login process. The user is always prompted to re-enter the new password as an error check.

### Login Failures

During the login process, login failures are counted and compared against the values set in the `/etc/default/login` file. The following line indicates the number of unsuccessful attempts allowed per login port:

    MAXTRYS = number

The default value for this keyword is 5. If the user unsuccessfully attempts to log in 5 consecutive times on the same terminal, the system disallows logins on that terminal for the number of seconds specified in the `/etc/default/login` `f`ile by this entry:

    DISABLETIME = number

The default value for `DISABLETIME` `time` is 20 seconds. The system administrator is exempt from this restriction, because it may be necessary to log in quickly in an emergency.

If the keyword `SYSLOG` is in the `/etc/default/login` file with either of the following settings, unsuccessful login attempts are placed in the system log with the date and time:

    SYSLOG = ALL SYSLOG = FAIL

### /etc/default/login File

The `/etc/default/login` file allows you to set the following options for all users on the system, as shown in Table 7-1.

Table 7-1. `/etc/default/login` File

Option | Default Value | Meaning
--- | --- | ---
MAXTRYS | 5 | Maximum consecutive number of unsuccessful login attempts to any login name through the same port. A 0 in this space indicates “no limit.”
DISABLETIME | 20 | The amount of time in seconds `login` waits before ending the session after `MAXTRYS` unsuccessful attempts.
PASSWDREQ | 0 | This field indicates whether passwords are required. If this field contains a 0, passwords are not required. If the field contains a 1, you may select a password when you log in if you do not have one. If the field contains a 2, you may not log in without a previously set password.
LASTLOG | 1 | This field indicates whether the user is to be notified about the last successful login attempt. A 1 in this field indicates that the user should be notified. If a 0 is present in this field, notification is suppressed.
SYSLOG | all | This field directs the system to log all successful and failed login attempts to the system log. If the value in the field is `FAIL`, then only failed attempts are logged.

After your installation is complete, you may edit the `/etc/default/login` file to enforce your particular system security policies. Before you edit the file, be sure to make a backup copy of the original. If the file is removed, the default values in effect at installation time are used.

### /etc/shadow, /etc/passwd, /etc/clearance, and /etc/capability Files

When a user logs in, the system encrypts the password and tests it against the encrypted password for the account listed in the `/etc/shadow` file. This file is labeled `dblow`, owned and readable only by `root`, thus shielding the encrypted passwords. The `/etc/passwd` file is still in existence, though, and still contains all pertinent user information except the encrypted password and label ranges. The `/etc/shadow` file also contains information about the minimum and maximum age of the user's password. The `/etc/clearance` and `/etc/capability` files contain the user's permitted MAC labels and capabilities, respectively.

## Login Process with Telnet or Serial Terminals

At times a user may need to log in to a Trusted IRIX/CMW machine without using the graphical login program. Logging in can be done by using Telnet sessions and serial terminals.

The Trusted IRIX TTY login appears the same as a typical IRIX console login, but it does not prompt a user for a MAC label or capabilities. A user can specify a MAC label or capability on the login line in addition to their user ID. A TTY device may be configured to have a restricted MAC range, thereby limiting a user to labels within that range. By default, a serial console will allow all labels. A MAC label specification is ignored by Telnet sessions.

To specify a MAC label, add `MAC=`label, as follows:

    login: root MAC=dblow
    Password:

To specify a capability set, add `CAP=`capabiility, as follows:

    login: root CAP=CAP_FOWNER,CAP_KILL+eip
    Password:

A user can specify both a MAC label and capability set, as follows:

    login: user CAP=all+eip MAC=userlow
    Password:

A login attempt will fail if the user requests a capability that does not exist or is not in the user's capability set, or if the user logs in with a MAC label not in the user's clearance or not allowed by the TTY device.

Prev | Table of Contents | Next
Chapter 6. Administering the System Audit Trail |  | Chapter 8. Trusted IRIX/CMW System Data Files