Access control also involves managing protected resources using the setuid and setgid programs and hard-copy labeling. The operating system supports several types of information resources, or objects. These objects allow user processes to store or communicate information.
The most important types of objects are:
Each object has an associated owner, group, and mode. The mode defines access permissions for the owner, group, and other users.
The following are the direct access control attributes for the different types of objects:
|Owner|| The owner of a specific object controls its discretionary access attributes. The owner's attributes are set to the creating process's effective user ID. For file system objects, the direct access control attributes for an owner cannot be changed without root privilege.
For System V Interprocess Communication (SVIPC) objects, either the creator or owner can change the owner. SVIPC objects have an associated creator that has all the rights of the owner (including access authorization). However, the creator cannot be changed, even with root privilege.
|Group|| SVIPC objects are initialized to the effective group ID of the creating process. For file system objects, the direct access control attributes are initialized to either the effective group ID of the creating process or the group ID of the parent directory (this is determined by the group inheritance flag of the parent directory).
The owner of an object can change the group; the new group must be either the effective group ID of the creating process or the group ID of the parent directory. The owner of an object can change the group; the new group must be either the effective group or in the supplementary group ID of the owner's current process. (As above, SVIPC objects have an associated creating group that cannot be changed and share the access authorization of the object group.)
For more information about access control lists, see "Access Control List" in the AIX Version 4.3 System User's Guide: Operating System and Devices.
The permission bits mechanism allows effective access control for resources in most situations. But for more precise access control, the operating system provides setuid and setgid programs.
Most programs execute with the user and group access rights of the user who invoked them. Program owners can associate the access rights of the user who invoked them by making the program a setuid or setgid program; that is, a program with the setuid or setgid bit set in its permissions field. When that program is executed by a process, the process acquires the access rights of the owner of the program. A setuid program executes with the access rights of its owner, while a setgid program has the access rights of its group and both bits can be set according to the permission mechanism.
Although the process is assigned the additional access rights, these rights are controlled by the program bearing the rights. Thus, the setuid and setgid programs allow for user-programmed access controls in which access rights are granted indirectly. The program acts as a trusted subsystem, guarding the user's access rights.
Although these programs can be used with great effectiveness, there is a security risk if they are not designed carefully. In particular, the program must never return control to the user while it still has the access rights of its owner, because this would allow a user to make unrestricted use of the owner's rights.
Note: For security reasons, the operating system does not support setuid or setgid calls within a shell script.
The operating system provides privileged access rights for system administration. System privilege is based on user and group IDs. Users with effective user or group IDs of 0 are recognized as privileged.
Processes with effective user IDs of 0 are known as root user processes and can:
You can manage the system using two types of privilege: the su command privilege and setuid-root program privilege. The su command allows all programs you invoke to function as root user processes, and su is a flexible way to manage the system, but it is not very secure.
Making a program into a setuid-root program means the program is a root user-owned program with the setuid bit set. A setuid-root program provides administrative functions that ordinary users can perform without compromising security; the privilege is encapsulated in the program rather than granted directly to the user.
It can be difficult to encapsulate all necessary administrative functions in setuid-root programs, but it provides more security to system managers.