Overview of Trusted Software Administration

As mentioned earlier in this chapter, the superuser's capabilities are divided into separate role accounts rather than being concentrated in the superuser account only. This separation is accomplished through two override mechanisms in the Trusted Solaris environment: authorizations, which are rights associated with users, and privileges, which are rights associated with processes.

An application that can override system controls is called a trusted application. Trusted applications can be designed to check for authorizations. They can also be assigned special security attributes: effective and real user IDs (UIDs) and group IDs (GIDs), process labels, clearances, and privileges. Instead of becoming superuser, users or roles can run their assigned trusted applications with the same capabilities that the superuser would have when running these applications.

Trusted applications and authorizations are grouped in rights profiles (or profiles, for short) that can be assigned to users or more commonly to roles. Users access trusted CDE actions granted to them through the Front Panel, the Application Manager, the Workspace menu, and the File Manager. Users access trusted commands granted to them through special shells called profile shells. The profile shell is a Bourne, Korn, or C shell that has been modified to grant roles (and users) access to those programs assigned to their rights profiles and to make security attributes available to commands. From a profile shell, a user can execute those commands and only those commands assigned to that user's profiles. Note that a profile can be used to both enable and restrict users. It enables users by giving them access to commands, privileges, and authorizations not available to normal users. It can restrict users by limiting them to a specific set of commands. This might be appropriate for unsophisticated users.

In practice, here is an example of how access control is enforced and can be overridden by an administrator or authorized user. When a user attempts to access a file, the mandatory access controls (MAC) are checked. The process label of the program the user is running must dominate the label on the file. If this is not the case, then the user's process needs MAC privileges, such as file_mac_search to access the directory and file_mac_read to read the file. There are also discretionary access controls, that is, UNIX permissions, to be checked. If the user does not have read permission, then privileges such as file_dac_search and file_dac_read are needed. If the file's ownership were to be changed through the File Manager, then the user would need the authorization solaris.file.chown.

The following figure summarizes the elements used in the Trusted Solaris environment administration. The arrows in the figure indicate the direction of an assignment. In short, roles are special accounts that can be assigned to users. Rights profiles are packages of permitted operations that are assigned commonly to roles and occasionally to users. Authorizations, CDE actions, and commands are assigned to rights profiles. Privileges are assigned to sets. The allowed and forced privilege sets can be assigned to executable files. CDE action and command processes can have the following security attributes applied: privileges in the inheritable privilege set; effective and real UIDs/GIDs; and clearances and security labels.

These elements and their relations are discussed in the following sections.

Figure 1-1 Security Element Assignment in the Trusted Solaris Environment

The Solaris environment also provides roles, authorizations, rights profiles, and profile shells (also referred to as "administrator shells"). The only security attributes that trusted applications in the Solaris environment can make use of are real and effective UIDs/GIDs. There are no labels, clearances, or privileges in the Solaris environment.