PROCESS RIGHTS MANAGEMENT PRIVILEGES

8.4. PROCESS RIGHTS MANAGEMENT PRIVILEGES 111

The processes that do not have a UID of 0 will be assigned the inheritable set of privileges from its parent, as restricted by the limit set. When executing, the privileges in the process’s observed effective privilege set permit the process to perform restricted operations. A process can use any of the privilege manipulation functions to add or remove privileges from the privilege sets. Privileges can be removed always. Only privileges found in the permitted set can be added to the effective and inheritable set. The limit set cannot grow. Note in Figure 8.2 that the inheritable set can be larger than the permitted set. Thus, it is possible that a process’s children may have permissions additional to the process’s permitted set. When a process performs an exec, the kernel will first try to relinquish privilege awareness before making the following privilege set modifications: E ′ = P ′ = I ′ = LI 8.7 L is unchanged 8.8 If a process has not manipulated its privileges, the privilege sets effectively remain the same, as E, P and I are already identical. The limit set is enforced at exec time. To run a non-privilege-aware application in a backward-compatible manner, a privilege-aware application should start the non-privilege-aware application with I = basic. For most privileges, absence of the privilege simply results in a failure. In some instances, the absence of a privilege can cause system calls to behave differently. In other instances, the removal of a privilege can force a setuid application to seriously malfunction. Privileges of this type are considered unsafe. When a process is lacking any of the unsafe privileges from its limit set, the system will not honor the setuid bit of setuid root applications.

8.4.2 CONTROLLING PRIVILEGE ESCALATION

In certain circumstances, a single privilege could lead to a process gaining one or more additional privileges that were not explicitly granted to that process. To prevent such an escalation of privileges, the security policy will require explicit permission for those additional privileges. Common examples of escalation are those mechanisms that allow modification of system re- sources through raw interfaces; for example, changing kernel data structures through devkmem or changing files through devdsk. A special case of this is manipulating or creating objects owned by UID 0 or trying to obtain UID 0 using the setuid system call. The special treatment of UID 0 is needed because the UID 0 owns all system configuration files and ordinary file protection mechanisms allow only processes with UID 0 to modify the system configuration. While with appro- priate file modifications, a given process running with an effective UID of 0 could gain all privileges, other protection mechanisms come into play. When a process needs the permissions only available to root, it must be run with UID 0. Ultimately, we would like to eliminate this requirement for an all-powerful root principal, so that 112 CHAPTER 8. CASE STUDY: SOLARIS TRUSTED EXTENSIONS processes could be simply bestowed their appropriate privilege sets. However, better protection of the file resources above is necessary to prevent a malicious process from circumventing such limitations. Of course, administrators should use as few UID 0 processes as possible. This reduces the size of the system’s trusted computing base, thus limiting the number of processes that must be tamperproof. Where possible, a root process should be replaced with programs running under a different UID but with exactly the privileges they need. For example, daemons that never need to exec subprocesses should remove the privilege to execute processes from their permitted and limit sets.

8.4.3 ASSIGNED PRIVILEGES AND SAFEGUARDS

While it is possible for privileges to be assigned to a user, they should really be assigned to programs. An system administrator could give a user more powers than intended. The administrator should consider whether additional safeguards are needed. For example, if the privilege to lock process mem- ory is given to a user, the administrator should consider setting the project.max-locked-memory resource control as well, to prevent that user from locking all memory.

8.5 ROLE-BASED ACCESS CONTROL RBAC

Role-based Access Control RBAC in Solaris is an alternative to the all-or-nothing security model of traditional superuser-based systems. With RBAC [ 94 ], an administrator can assign privileged functions to specific user accounts or special accounts, called roles. RBAC is in keeping with the security principle of least privilege by allowing organizations to selectively grant privileges to users or roles based upon their unique needs and requirements. In general, organizations are strongly encouraged to use Solaris RBAC to restrict access to privileged operations rather than granting users complete access to the backwardly compatible root account. Solaris RBAC was introduced in the Solaris 8 operating system, having come from Trusted Solaris, and has been enhanced and expanded with each new release of Solaris. Solaris RBAC functionality contains several discrete elements that can be used individually or together including authorizations, privileges, rights profiles and role designations. Figure 8.3 illustrates the relationship between these elements that are described in turn below.

8.5.1 RBAC AUTHORIZATIONS

An authorization is a unique string that represents a user’s right to perform some operation or class of operations. Authorization definitions are stored in a database called auth_attr. For programming authorization checks, only the authorization name is significant. Some typical values in an auth_attr database are shown below. solaris.jobs.:::Cron and At Jobs::help=JobHeader.html solaris.jobs.grant:::Delegate Cron At \ Administration::help=JobsGrant.html