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:
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.
The Light Directory Access Protocol (LDAP) devines a standard method for accessing and updating information in a directory (a database) either locally or remotely in a client-server model. The LDAP method is exploited by AIX to allow distributed security authentication as well as access to user, group and role information. This functionality is intended to be used in a clustering environment to keep authentication, user, group and role information common across the cluster.
Once LDAP is enabled to serve user, group and role information, most high level APIs, commands and system management tools should work in the same manner as in a normal environment. One restriction is tha tto create a new user, the mkuser command must be called on the server machine and the calling process must have the AUTHSTATE environment variable set to LDAP. It is also required that all users and groups that are provided by default on a system must remain locally defined on all client LDAP enable machines. This allows the root user at least to be able to log in on a client if there happens to be some server problem.
The client system knows a user is an LDAP user if that user's SYSTEM attribute in the /etc/security/user file is set to LDAP. If the SYSTEM attribute in the default stanza is set to LDAP, then all users are considered LDAP users. The LDAP keyword may be used with other SYSTEM attribute values as described in Identification and Authentication. The client side communicates to the server through the secldapclntd daemon. The daemon accepts requests from applications, queries the LDAP server and returns data to the application. The secldapclntd daemon is also responsible for caching.
To set up a system as an LDAP server to serve authentication and user, group and role information through LDAP, the LDAP server and client packages must be installed and configured. The AIX LDAP server needs to be configured as a client as well as a server. The DB2 database is also required, as the LDAP server needs it. If the Secure Socket Layer (SSL) version is required, then the SSL version of the LDAP server and client should be installed and configured. When using the SSL version of LDAP, the system administrator must create a key using the LDAP Web Interface. The certificate must be carried to the clients.
To set up the server, use the mksecldap command.
For non-SSL, type :
mksecldap -s -a <adminDN> -p <adminpasswd>
followed by:
mksecldap -c -h <hostlist> -d <AIXtreeDN> -u <ALL|userlist> -a <adminDN> -p <adminpasswd>
For SSL, type:
mksecldap -s -a <adminDN> -p <adminpasswd> -k <ssl key file path> -w <client certificate passwd>
The LDAP client must have the LDAP client package installed. If the SSL version of the client package needs to be installed, running the mksecldap command changes the user's SYSTEM line to LDAP, stores all the information the client needs to talk to the server, and starts the client side daemon.
For non-SSL, type :
mksecldap -c -h <hostlist> -d <AIXtreeDN> -u <ALL|userlist> -a <adminDN> -p <adminpasswd>
For SSL, type:
mksecldap -c -h <hostlist> -d <AIXtreeDN> -u <ALL|userlist> -a <adminDN> -p <adminpasswd> -k <ssl key file path> -w <client certificate passwd>