分类：
2006-05-28 14:54:57
The following guidelines are for system administrators who need to implement and maintain system security.
Attention: Any operating environment may have unique security requirements that are not addressed in these guidelines. To ensure a secure system, system administrators may need to implement additional security measures not discussed here.
This information does not provide security guidelines for all operational environments. It is impossible to create a single set of guidelines for all security requirements. These guidelines are not intended to represent the only requirements for achieving a secure system.
It is helpful to plan and implement your security policies before you begin using the system. Security policies are very time consuming to change later, so a little planning now can save a lot of time later.
The security guidelines by category are:
Every system should maintain the level of security represented by these basic security policies.
Many attributes can be set for each user account, including password and login attributes. (For a list of configurable attributes, see the table in AIX Version 4.3 System Management Guide: Operating System and Devices. .) The following are recommended:
When a file is created, the operating system assigns the user ID of the new file the effective user ID of the process that created it. The group ID of the file is either the effective group ID of the process or the group ID of the directory that contains the file, based on the set group ID (SUID) bit of that directory.
File ownership can be changed with the command.
The command shows your user ID (UID), group ID (GID), and the names of all groups you belong to.
In file listings (such as the listings shown by the or command), the three groups of users are always represented in the following order: user, group, and others. If you need to find out your group name, the command shows all the groups for a user ID.
The "File Ownership and User Groups" in AIX Version 4.3 System User's Guide: Operating System and Devices contains more information about file and directory access modes.
Groups are collections of users who can share access permissions for protected resources. Plan your system groups before you begin creating them. Groups can make administration easier, but once you start using the system, it is harder to change your group organization. There are three types of groups: user, system administrator, and system-defined.
In general, create as few user groups as possible.
Groups should be made for people who need to share files on the system, such as people who work in the same department, or people who are working on the same project.
For example, consider a small engineering office with three sets of people in the office: office support personnel, system administrators, and engineers. Only two user groups, one for each function in the office, are needed: OFFICE (for the office management staff), and ENGINEER (for the engineers). Later, for example, if a small group of engineers begins work on a special project, a new group called PROJECT can be created and those engineer user IDs can be added to the PROJECT group. Though users can be in more than one group at a time, as in this case, they can only have one primary group at a time. Users can change their primary group with the command.
It is also recommended for simple systems that you do not set the admin characteristic when creating groups. If a group has admin=true set in the /etc/security/group file, only the root user can administer that group.
System administrators should be members of the SYSTEM group. SYSTEM group membership allows an administrator to perform some system maintenance tasks without having to operate with root authority.
There are several system-defined groups. The STAFF group is the default group for all nonadministrative users created in the system. You can change the default group by using the chsec command to edit the /usr/lib/security/mkuser.default file.
The SECURITY group is a system-defined group having limited privileges for performing security administration. SECURITY group members have access to programs and files in /etc/security directory. SECURITY group members can change most attributes for nonadministrative users and groups, such as the user's login shell or the membership of a nonadministrative group.
Most systems do not need to use this group; only multiuser systems with many users should consider using this group. Otherwise, system administrators can perform the same tasks as SECURITY group members by using the command to gain root privilege.
The other system-defined groups are used to control certain subsystems. Consult the subsystem information to see if certain users should be defined as a member of those groups. The system-defined groups and users appear in the /etc/group file.
All file system objects (including files, directories, special files, link files, symbolic link files, and pipes) have security mechanisms associated with them. The most commonly used is the access control list (ACL), but the following additional ways of controlling file security can also be used:
| Base ACLs | Specifies the permissions for the owner, group, and others. These permissions are controlled through the command. For more information, see the section on "File Directory and Access Modes" in the AIX Version 4.3 System User's Guide: Operating System and Devices. |
| Extended ACLs | Provides finer access control than the base ACLs. For more information about the extended ACLs, see the section on "Access Control Lists" in the AIX Version 4.3 System User's Guide: Operating System and Devices. |
| Status of Extended ACLs | The extended ACL must be enabled for a file system object; otherwise, the extended ACL is ignored. |
| Owner ID | This is the user ID of the owner of the file system object. Only this user ID has the permissions granted for the owner of the object. |
| Group ID | This is the ID of the group associated with the object. Only members of this group have the permissions granted for the group associated with the object. |
| Sticky bit | If the sticky bit is set for a directory, only the owner of the directory or the owner of a file can delete or rename a file within that directory, even if others have write permission to the directory. This can be set with the t flag with the command. |
| TCB bit | If the TCB bit is set for a file system object, it identifies that object as part of the Trusted Computing Base (TCB). |
| umask | The umask environment parameter specifies the default permissions for any file or directory created. |
| Status of the file system | A file system can be mounted with read/write or read-only permissions. |
Follow these guidelines when dealing with file system objects:
Attention: The root account should always have a password, and it should never be shared. Only one person, the system administrator, should know the root password. System administrators should only operate as root to perform system administration functions that require root privileges, and then return to a normal user account. Routinely operating as root can result in damage to the system as root overrides many safeguards in the system.
The system administrator should have the root password to gain root authority by using the command. Immediately after the system is installed, the root account should be given a password.
The root account should always be authenticated by means of the local security files.
The PATH environment variable is an important security control. It specifies the directories to be searched to find a command. The default systemwide PATH value is specified in the /etc/profile file, and each user normally has a PATH value in the user's $HOME/.profile file. The PATH value in the .profile file either overrides the systemwide PATH value or adds extra directories to it.
Unauthorized changes to the PATH environment variable can enable a user on the system to "spoof" other users (including root users). Spoofing programs (also called Trojan Horse programs) replace system commands and then capture information meant for that command, such as user passwords.
For example, suppose a user changes the PATH value so that the system searches the /tmp directory first when a command is executed. Then the user places in the /tmp directory a program called su that asks for the root password just like the command. Then the /tmp/su program mails the root password to the user and calls the real su command before exiting. In this scenario, any root user who used the su command would give away the root password and not even be aware of it. This is just one of many scenarios for gaining confidential information by altering PATH values.
However, following a few simple steps will prevent any problems with the PATH environment variable for system administrators and users:
su - rootThis will ensure that root's environment is used during the session. If a system administrator does operate as root in another user's session, then the system administrator should specify full path names throughout the session.
These security policies provide a greater level of security, but also require more work to maintain. Consequently, many system administrators use these security features only in a limited way, or not at all.
System accounting is not a direct security function, but the information it gathers is important for detecting security problems. You should activate basic accounting on your system, as explained in , although you may want to consider not activating disk accounting and printing accounting as specified in the procedure. Both of these accounting functions produce a large amount of data, and they are not vital to system security.
For smaller systems, auditing is generally not necessary. However, on large multiuser systems, it can provide useful information about system activity. For more information, see .
The Trusted Computing Base (TCB) allows administrators to closely monitor trusted programs and enhance the security of the system.
Most systems should use only two parts of the TCB: the command and the default /etc/security/sysck.cfg configuration file. The tcbck command uses information in the /etc/security/sysck.cfg file to compare the security status of key elements of the system against the base data stored in the file. All the administrator must do is protect the sysck.cfg file and run the tcbck command regularly.
