Precise system administration is vital to maintaining the security of
information resources on a computer system. Security is based on
establishing and maintaining correct access control and accountability
policies. It is the responsibility of the administrator 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 Overview
|Enforces the information security policies of the system
|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 the same 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:
|Specifies the password
|Specifies the user identifier, principal group, and the supplementary group ID
|Specifies the home or shell environment.
If desired, the operating system allows for greater control with extended attributes. Security information can 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:
|Limits certain accounts to physically secure areas
|Manages student or guest accounts; also can be used to turn off accounts temporarily
|Restricts when a user can log in. For example, a user may be restricted to accessing the system only during normal business hours.
The complete set of user attributes is defined in the /usr/lib/security/mkuser.default, /etc/security/user, /etc/security/limits, and /etc/security/lastlog files. Several of these attributes control how a user can log in and they can be configured to lock the user account (prevent further logins) under specified conditions.
Once the user account is locked, the user is not be able to log in until the system administrator resets the user 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 must 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 can 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 can be defined in /usr/lib/security/methods.cfg.
Note: The root user is always 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 5L Version 5.1 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, the operating system 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 password security, all passwords must 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.
Apply password restrictions 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 sensible guidelines and an occasional audit (checking current passwords to see if they are unique), are the best policy.
The restrictions that can be
|Minimum number of weeks that must pass before a password can be changed.
|Maximum number of weeks that can pass before a password must be changed.
|Maximum number of weeks beyond maxage that a password can be changed before administrative action is required to change the password. (Root is exempt.)
|Minimum number of alphabetic characters the new password must contain.
|Minimum number of nonalphabetic characters the new password must contain. (Other characters are any ASCII printable characters that are nonalphabetic and are not national language code points).
|Minimum number of characters the new password must contain.
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 must never be greater than eight. If minalpha plus minother is greater than eight, then minother is reduced to eight minus minalpha.
|Maximum number of times a character can be used in the new password.
|Minimum number of characters in the new password that must be different from the characters in the old password.
|Number of weeks that a user is unable to reuse a password.
|Number of previous passwords that cannot be reused.
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.
|List of dictionary files checked when a password is changed. Dictionary files contain passwords that are not allowable.
|List of external password restriction methods that are used when a password is changed.
|*A maximum of 50 passwords are retained. NA = not applicable
Set restrictions 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 can set minother to 0. Because most words in this dictionary file do not contain characters that fall into the minother category, setting minother to 1 or more eliminates 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 5L Version 5.1 Technical Reference contains a description of the pwdrestrict_method, the subroutine interface to which specified password restriction methods must conform. To correctly extend the password composition restrictions, the system administrator must program this interface when writing a password restriction method. Use caution 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 can be examined when you generate audit records. See the AIX 5L Version 5.1 System User's Guide: Operating System and Devices for more information about login user IDs.