How the Trusted Solaris environment Enforces Access Control Policy

The Trusted Solaris environment controls which users can access which information by providing

• Discretionary access control

• Mandatory access control

Discretionary Access Control

Discretionary access control (DAC) is a software mechanism for controlling users' access to files and directories. It leaves setting protections for files or directories to the owner's discretion. The two forms of DAC are the traditional UNIX permission bits and Access Control Lists (ACLs).

Permission bits let the owner set read, write, and execute protection by owner, group, and other users. In traditional UNIX systems, the superuser (root) can override DAC protection; in the Trusted Solaris environment, the ability to override DAC is permitted for administrators and authorized users only. Access Control Lists (ACLs) provide a finer granularity of access control, letting owners specify separate permissions for specific individuals and groups.

Mandatory Access Control

Mandatory access control (MAC) is a system-enforced access control mechanism that uses clearances and labels to enforce security policy. Roughly speaking, MAC associates the programs a user runs with the security level (clearance or label) at which the user chooses to work in the session and permits access to information, programs, and devices at the same or lower level only. MAC also prevents users from writing to files at lower levels. MAC is enforced according to your site's security policy and cannot be overridden without special authorization or privileges.

Clearances

As part of your site's security policy, your security administrator assigns a user clearance to everyone at your site. The user clearance represents the degree of security with which a user is entrusted. It has two components:

• classification - indicates a (hierarchical) level of security. Applied to people, the classification represents a measure of trust; applied to data, it is the degree of protection required. In government, classifications are: TOP SECRET, SECRET, CONFIDENTIAL, and UNCLASSIFIED. Industry is not as standardized; a hypothetical classification hierarchy might be PUBLIC, INTERNAL, NEED TO KNOW, and REGISTERED.

• compartment - represents a grouping, such as a work group, department, project, or topic. Access to compartments is granted on a need-to-know basis.

Some typical clearances are shown in the following figure.

Figure 1-2 Typical Clearances

Labels

The Trusted Solaris environment uses a string called a label (containing a classification and compartments in similar fashion to clearances) to determine which information you can access. (Labels are also referred to as sensitivity labels or SLs, for short.) Labels may be displayed inside square brackets ([]) in window title bars, in the trusted stripe (a special area at the bottom of the screen), or not at all, depending on how your system is configured. Figure 1-3 shows a configuration configured to display labels; the labels and trusted stripe are indicated.

Figure 1-3 Typical Environment with Labels Displayed

All subjects and objects in a system have labels. A subject is an active entity, usually a process (running program), that causes information to flow among objects or changes the system state. An object is a passive entity that contains or receives data, such as a data file, directory, printer, or other device. In some cases, a process may be an object, such as when you use kill on a process.

The Part Labels Play in Transactions

The Trusted Solaris environment mediates all attempted security-related transactions. It compares the subject's label with the object's label and permits or disallows the transaction depending on which label is dominant (as described below). An entity's label is said to dominate another's if the following two conditions are met:

• The classification component of the first entity's label is equal to or outranks the object's classification.

• All compartments in the second entity's labels are included in the first entity's label.

Two labels are said to be equal if they have the same classification and the same set of compartments. If they are equal, they dominate each other so that access is permitted. If one label has a higher classification or includes all of the second label's compartments or both, the first label is said to strictly dominate the second label. Two labels are said to be disjoint or noncomparable if neither label dominates the other.

In a read transaction, the subject's label must dominate the object's label. This rule ensures that the subject's level of trust meets the requirements for access to the object and that the subject's label includes all compartment groupings that are allowed access to the object.

In a write transaction, that is, when a subject creates or modifies an object, the resulting object's label must dominate the subject's label. This rule prevents the subject from lowering the object's label.

Users sometimes refer to the acronym WURD (write up / read down) to remind themselves of the permitted directions in mandatory access control. In practice, subjects and objects in read and write transactions usually have the same label and strict dominance does not have to be considered.

When you perform a drag-and-drop or copy-and-paste operation between files with different labels, the Trusted Solaris environment displays a confirmation dialog box if you are permitted to change the label or, if you are not permitted, the Trusted Solaris environment bars the transaction. You can accept the upgrade of the destination (if you have special authorization), downgrade the information so that the destination will maintain its existing label, or cancel the transaction altogether.

User Responsibilities for Protecting Data

As a user, you are responsible for setting the permissions to protect your files and directories, as part of discretionary access control. You can check the permissions on your files and directories using the ls(1) command with the -l option or the File Manager, as described in "Viewing or Changing Permissions and ACL Entries".

Mandatory access control is enforced automatically by the system. If you are authorized to upgrade or downgrade information protected by labels, you have an extra special responsibility to ensure that there is a legitimate need for the change.

Another aspect of protecting data is that you should never follow emailed instructions from an administrator without verifying that the administrator actually sent the instructions. For example, if you followed emailed instructions to change your password to a particular value, you would enable the sender to log into your account.