Access control consists of protected information resources that specify who can be granted access to such resources. The operating system allows for need-to-know or discretionary security. The owner of an information resource can grant other users read or write access rights for that resource. A user who is given access to an object may create additional copies of the object and give a third party access rights to the newly created object. However, only the object owner can grant a third party access rights to the original object. The owner of an object and the root user are the only users that may change the access rights to an object.
Users have user-based access only to the objects that they own. Typically, users receive either the group permissions or the default permissions for a resource. The major task in administering access control is to define the group memberships of users, because these memberships determine the users' access rights to the files that they do not own.
Access control lists (ACLs) increase the quality of file access controls by adding extended permissions that modify the base permissions assigned to individuals and groups. With extended permissions, you can permit or deny file access to specific individuals or groups without changing the base permissions.
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:
Note: The access control list for a file cannot exceed one memory page (approximately 4096 bytes) in size.
To maintain access control lists, use the aclget, acledit, and the aclput commands.
The chmod command in numeric mode (with octal notations) can set base permissions and attributes. The chmod subroutine, which the command calls, disables extended permissions. If you use the numeric mode of the chmod command on a file that has an ACL, extended permissions are disabled. The symbolic mode of the chmod command does not disable extended permissions. For information on numeric and symbolic mode, refer to the chmod command.
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.
Base permissions are the traditional file-access modes assigned to the file owner, file group, and other users. The access modes are: read (r), write (w), and execute/search (x).
In an access control list, base permissions are in the following format, with the Mode parameter expressed as rwx (with a hyphen (-) replacing each unspecified permission):
base permissions: owner(name): Mode group(group): Mode others: Mode
Three attributes can be added to an access control list:
These attributes are added in the following format:
attributes: SUID, SGID, SVTX
Extended permissions allow the owner of a file to define access to that file more precisely. Extended permissions modify the base file permissions (owner, group, others) by permitting, denying, or specifying access modes for specific individuals, groups, or user and group combinations. Permissions are modified through the use of keywords.
The permit, deny, and specify keywords are defined as follows:
| permit | Grants the user or group the specified access to the file |
| deny | Restricts the user or group from using the specified access to the file |
| specify | Precisely defines the file access for the user or group |
If a user is denied a particular access by either a deny or a specify keyword, no other entry can override that access denial.
The enabled keyword must be specified in the ACL for the extended permissions to take effect. The default value is the disabled keyword.
In an ACL, extended permissions are in the following format:
extended permissions:
enabled | disabled
permit Mode UserInfo...:
deny Mode UserInfo...:
specify Mode UserInfo...:
Use a separate line for each permit, deny, or specify entry. The Mode parameter is expressed as rwx (with a hyphen (-) replacing each unspecified permission). The UserInfo parameter is expressed as u:UserName, or g:GroupName, or a comma-separated combination of u:UserName and g:GroupName.
Note: If more than one user name is specified in an entry, that entry cannot be used in an access control decision, because a process has only one user ID.
The following is an example of an ACL:
attributes: SUID
base permissions:
owner(frank): rw-
group(system): r-x
others: ---
extended permissions:
enabled
permit rw- u:dhs
deny r-- u:chas, g:system
specify r-- u:john, g:gateway, g:mail
permit rw- g:account, g:finance
The parts of the ACL and their meanings are the following:
Note: More than one extended entry can apply to a process that is requesting access to a controlled object, with restrictive entries taking precedence over permissive modes.
See the acledit command in the AIX 5L Version 5.2 Commands Reference for the complete syntax.
The owner of the information resource is responsible for managing access rights. Resources are protected by permission bits, which are included in the mode of the object. The permission bits define the access permissions granted to the owner of the object, the group of the object, and for the others default class. The operating system supports three different modes of access (read, write, and execute) that can be granted separately.
When a user logs in to an account (using the login or su commands), the user IDs and group IDs assigned to that account are associated with the user's processes. These IDs determine the access rights of the process.
For files, directories, named pipes, and devices (special files), access is authorized as follows:
A process with a user ID of 0 is known as a root user process. These processes are generally allowed all access permissions. But if a root user process requests execute permission for a program, access is granted only if execute permission is granted to at least one user.
The identifier list of an ACL matches a process if all identifiers in the list match the corresponding type of effective identifier for the requesting process. A USER-type identifier matched is equal to the effective user ID of the process, and a GROUP-type identifier matches if it is equal to the effective group ID of the process or to one of the supplementary group IDs. For instance, an ACE with an identifier list such as the following:
USER:fred, GROUP:philosophers, GROUP:software_programmer
would match a process with an effective user ID of fred and a group set of:
philosophers, philanthropists, software_programmer, doc_design
but would not match for a process with an effective user ID of fred and a group set of:
philosophers, iconoclasts, hardware_developer, graphic_design
Note that an ACE with an identifier list of the following would match for both processes:
USER:fred, GROUP:philosophers
In other words, the identifier list in the ACE functions is a set of conditions that must hold for the specified access to be granted.
All access permission checks for these objects are made at the system call level when the object is first accessed. Because System V Interprocess Communication (SVIPC) objects are accessed statelessly, checks are made for every access. For objects with file system names, it is necessary to be able to resolve the name of the actual object. Names are resolved either relatively (to the process' working directory) or absolutely (to the process' root directory). All name resolution begins by searching one of these.
The discretionary access control mechanism allows for effective access control of information resources and provides for separate protection of the confidentiality and integrity of the information. Owner-controlled access control mechanisms are only as effective as users make them. All users must understand how access permissions are granted and denied, and how these are set.