Proper system administration is vital to maintaining the security of information resources on a computer system. AIX security is based on establishing and maintaining proper access control and accountability policies. It is an administrator's responsibility to configure the following aspects of security:
| Managing Protected Resources with Access Control | ||
| Addresses the privacy, integrity, and availability of information on your system. | ||
| Identification and Authentication | ||
| Determines how users are identified and how their identities are authenticated. | ||
| Trusted Computing Base (TCB) | ||
| Enforces the information security policies of the system. | ||
| Auditing | ||
| Records and analyzes events that take place on the system. | ||
The primary goal of security is the detection and prevention of security violations on a system. Computer security includes the following fundamental aspects.
User administration consists of creating users and groups and defining their attributes. A major attribute of users is how they are authenticated. Users are the primary agents on the system. Their attributes control their access rights; environment; how they are authenticated; and how, when, and where their accounts can be accessed.
Groups are collections of users who can share access permissions for protected resources. A group has an ID and is composed of members and administrators. The creator of the group is usually the first administrator.
The operating system supports the standard user attributes usually found in the /etc/passwd and /etc/group files, such as:
| Authentication Information | Specifies the password. |
| Credentials | Specifies the user identifier, principal group, and the supplementary group ID. |
| Environment | Specifies the home or shell environment. |
The operating system allows for greater control, if desired, with extended attributes. Security information can also be separately protected from public access.
Some users and groups can be defined as administrative. These users and groups can be created and modified only by the root user.
Each user account has a set of associated attributes. These attributes are created from default values when a user is created using the mkuser command. They can be altered by using the chuser command. The following are examples of user attributes:
The complete set of user attributes is defined in the /usr/lib/security/mkuser.default, /etc/security/user, /etc/security/limits, /etc/security/lastlog files. Several of these attributes control how a user can login, and these attributes can be configured to lock the user account (prevent further logins) under specified conditions.
Once the user's account is locked, the user will not be able to login until the system administrator resets the user's unsuccessful_login_count attribute in the /etc/security/lastlog file to be less than the value of login retries. This can be done using the following chsec command:
chsec -f /etc/security/lastlog -s username -a
unsuccessful_login_count=0
The defaults can be changed by using the chsec command to edit the default stanza in the appropriate security file, such as the /etc/security/user, /usr/lib/security/mkuser.default, or /etc/security/limits files. Many of the defaults are defined to be the standard behavior.
Identification and authentication establish a user's identity. Each user is required to log in to the system. The user supplies the user name of an account and a password, if the account has one (in a secure system, all accounts should either have passwords or be invalidated). If the password is correct, the user is logged in to that account; the user acquires the access rights and privileges of the account. The /etc/passwd and /etc/security/passwd files maintain user passwords.
Alternative methods of authentication are integrated into the system by means of the SYSTEM attribute that appears in /etc/security/user. For instance, the Distributed Computing Environment (DCE) requires password authentication but validates these passwords in a manner different from the encryption model used in /etc/passwd and /etc/security/passwd. Users who authenticate by means of DCE may have their stanza in /etc/security/user set to SYSTEM=DCE.
Other SYSTEM attribute values are compat, files, and NONE. The compat token is used when name resolution (and subsequent authentication) follows the local database, and if no resolution is found, the Network Information Services (NIS) database is tried. The files token specifies that only local files are to be used during authentication. Finally, the NONE token turns off method authentication. To turn off all authentication, the NONE token must appear in the SYSTEM and auth1 lines of the user's stanza.
Other acceptable tokens for the SYSTEM attribute may be defined in /etc/security/login.cfg.
Note: The root user should always be authenticated by means of the local system security file. The SYSTEM attribute entry for the root user is specifically set to SYSTEM = "compat" in /etc/security/user.
See the AIX Version 4.3 System User's Guide: Operating System and Devices for more information on protecting passwords.
Proper password management can only be accomplished through user education. But to provide some additional security, AIX provides configurable password restrictions. These allow the administrator to constrain the passwords chosen by users and to force passwords to be changed regularly. These restrictions are recorded in the /etc/security/user attribute file and are enforced whenever a new password is defined for a user. All password restrictions are defined per user. By keeping restrictions in the default stanza of the /etc/security/user file, the same restrictions are enforced on all users. To maintain proper password security, all passwords should be similarly protected.
The operating system also provides a method for administrators to extend the password restrictions. Using the pwdchecks attribute of the /etc/security/user file, an administrator can add new subroutines (known as methods) to the password restrictions code. Thus, local site policies can be added to and enforced by the operating system. See "Extending Password Restrictions" for more information.
Restrictions should be applied sensibly. Attempts to be too restrictive, such as limiting the password space (making guessing easier) or forcing the user to select difficult-to-remember passwords (which are then written down) can jeopardize password security. Ultimately, password security rests with the user. Simple password restrictions, coupled with proper guidelines and an occasional audit (checking current passwords to see if they are unique), are the best policy.
The restrictions that can be applied are:
Note: The minimum length of a password on the system is minlen or minalpha plus minother, whichever is greater. The maximum length of a password is eight characters. minalpha plus minother should never be greater than eight. If minalpha plus minother is greater than eight, then minother is reduced to eight minus minalpha.
Note: If both histexpire and histsize are set, the system retains the number of passwords required to satisfy both conditions up to the system limit of 50 passwords per user. Null passwords are not retained.
| Restriction Values | Advised Values | Default Values | Maximum Values |
| minage | 0 | 0 | 52 |
| maxage | 8 | 0 | 52 |
| maxexpired | 4 | -1 | 52 |
| minalpha | 4 | 0 | 8 |
| minother | 1 | 0 | 8 |
| minlen | 6 | 0 | 8 |
| mindiff | 3 | 0 | 8 |
| maxrepeats | 1 | 8 | 8 |
| histexpire | 26 | 0 | 260* |
| histsize | 0 | 0 | 50 |
| dictionlist | NA | NA | NA |
| pwdchecks | NA | NA | NA |
| *A maximum of 50 passwords are retained. NA = not applicable | |||
Restrictions should be set so that passwords are hard to guess, yet not hard to remember. Passwords that are hard to remember are often written down somewhere, which compromises system security.
If text processing is installed on the system, the administrator can use the /usr/share/dict/words file as a dictionlist dictionary file. In such a case, the administrator should set minother to 0. Since most words in this dictionary file do not contain characters that fall into the minother category, setting minother to 1 or more would eliminate the need for the vast majority of words in this dictionary file.
The rules used by the password program to accept or reject passwords (the password composition restrictions) can be extended by system administrators to provide site-specific restrictions. Restrictions are extended by adding subroutines, known as methods, which are called during a password change. The pwdchecks attribute in the /etc/security/user file specifies the methods called.
The AIX Version 4.3 Technical Reference contains a description of the pwdrestrict_method, the subroutine interface that specified password restriction methods must conform to. To properly extend the password composition restrictions, the system administrator must program this interface when writing a password restriction method. Caution is advised in extending the password composition restrictions. These extensions directly affect the login command, the passwd command, the su command, and other programs. The security of the system could easily be subverted by malicious or defective code. Only use code that you trust.
All audit events recorded for this user are labeled with this ID and should be examined when you generate audit records. Refer to the AIX Version 4.3 System User's Guide: Operating System and Devices for more information about login user IDs.