Chapter 1 Introduction to the Trusted Solaris Environment

This chapter introduces you to the Trusted Solaris operating environment, an environment with all the advantages of the Solaris operating environment plus powerful security features to accommodate an organization's security policy.

• "How the Trusted Solaris Environment Protects Against Intruders"

• "How the Trusted Solaris Environment Enforces Access Control Policy"

• "User Responsibilities for Protecting Data"

• "How the Trusted Solaris Environment Keeps Labeled Information Separate"

• "How the Trusted Solaris Environment Enables Secure Administration"

What Is Trusted Solaris?

The Trusted Solaris software package is an enhanced version of the Solaris operating environment (including the Common Desktop Environment (CDE)), with special security features. The Trusted Solaris environment enables an organization to define and implement a security policy for a single Sun workstation or a network of Sun workstations. A security policy is the set of rules and practices that help protect information and other resources (such as computer hardware) in your system. Typically, rules deal with such items as who has access to which information or who is allowed to write files to tape; practices are recommended procedures for performing tasks.

The following sections describe some major security features that Trusted Solaris provides. Note that your site may not implement all of these features.

How the Trusted Solaris Environment Protects Against Intruders

The Trusted Solaris environment protects against intruders by:

• Limiting access to the trusted computing base

• Making theft of passwords more difficult

• Protecting information on the system through access control

• Providing auditing

• Preventing spoofing programs

• Protecting local peripheral devices against unauthorized users

Limiting Access to the Trusted Computing Base

The term trusted computing base (or TCB) refers to the part of the Trusted Solaris environment that affects security; it includes software, hardware, firmware, documentation, and administrative procedures. Utility programs and application programs that can access security-related files are all part of the trusted computing base. Your administrator sets limits on all potential interactions that you can make with the TCB regarding programs that you need to do your job, files that you are allowed to access, and utility programs that can affect security.

Making Theft of Passwords More Difficult

Because intruders generally break into systems by guessing passwords, the Trusted Solaris environment supplies several options for tightening password security. Users may be required to change passwords at certain intervals or by set expiration dates. In addition, there is a password generator that creates random, non-language passwords. Check with your administrator to see which of these options are used at your site.

Protecting Information on the System Through Access Control

If an intruder does successfully log into the system, there are further obstacles to getting surreptitious access to information. Files and other resources are protected by both access control that is set by the owner of the information and access control enforced by the system. See "How the Trusted Solaris Environment Enforces Access Control Policy".

Providing Auditing

The Trusted Solaris environment enables administrators to audit all or selected user actions and run reports by user ID, file, date, and time. You are accountable for your actions in a Trusted Solaris system, particularly those actions that may affect security or sensitive files. User activity can be recorded in an audit trail so that administrators can detect suspicious actions on the system.

Preventing Spoofing Programs

Intruders sometimes spoof (that is, imitate) login or other legitimate programs to intercept passwords or other sensitive data. The Trusted Solaris environment protects users from hostile spoofing programs by displaying the Trusted Symbol, an unmistakable, tamper-proof icon at the bottom of the screen that is displayed whenever you interact with the trusted computing base (TCB). Its presence ensures the safety of performing security-related transactions. Its absence indicates a potential security breach. The following figure shows the trusted symbol.

Figure 1-1 Trusted Symbol

Protecting Local Peripheral Devices Against Unauthorized Users

In the Trusted Solaris environment, administrators can assign access to local peripheral devices such as tape drives, floppies, printers, and microphones on a user-by-user basis. The Trusted Solaris environment restricts access to peripheral devices as follows:

• Remote users cannot tap into local devices such as microphones or tape drives; users must be logged in locally to use a special device allocation tool.

• Only users with special authorization can access devices with removable media.

How the Trusted Solaris Environment Enforces Access Control Policy

The Trusted Solaris environment controls which users can access which information by providing both discretionary and 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. It 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, which contains a classification and compartments in similar fashion to clearances. The label determines 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.

Labels and 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. 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 File Manager, as described in Chapter 5, Managing Labels on Files and Directories.

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

Another aspect of protecting data is never following 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.

How the Trusted Solaris Environment Keeps Labeled Information Separate

The Trusted Solaris environment helps keep information at different labels separate by:

• Letting users select single- or multi-level sessions

• Providing labeled workspaces

• Storing files in separate directories according to label

• Enforcing MAC for email transactions

• Clearing objects prior to reuse

Single- or Multi-level Sessions

When you first log into a Trusted Solaris session, you specify whether you will be operating at a single label or at multiple labels. You then set your session clearance or session label. This is the security level at which you intend to operate.

In a single-level session, you can access only those objects at or dominated by your session label.

In a multi-level session, you can access information at different sensitivity levels, as long as they are at or lower than your session clearance. In the Trusted Solaris environment, you can specify different labels for different workspaces.

Session Selection Example

Table 1-2 provides an example of the difference between a single- and multi-level session. It contrasts a user choosing to operate in a single-level session at SECRET A with a user selecting a multi-level session, also at SECRET A. Note that labels are shown in their long form inside square brackets ([]).

The three columns on the left show the user's session selections at login. Note that users set session labels for single-level sessions and session clearances for multi-level sessions. (This is a minor distinction that is taken care of by the system; the correct label builder dialog box is always displayed with the choices permitted.)

The two columns on the right show the label values available in the session. The Initial Workspace label column represents the label when the user first enters the Trusted Solaris environment. The Available Labels column lists the labels that the user is permitted to switch to in the session.

In the first row of the table, the user has selected a single-level session with a session label of [S A]. In the Trusted Solaris environment, the user has an initial workspace label of [S A] which is also the only label at which the user can operate.

In the second row of the table, the user has selected a multi-level session with a session clearance of [S A]. The user's initial workspace label is set to [U], that is, a label of [UNCLASSIFIED], because that is the lowest possible label in the user's account label range. The user can switch to any label between [U], the minimum, and [S A], the session clearance.

Labeled Workspaces

The workspaces in the Trusted Solaris environment are accessed through buttons in the front panel, just as in the standard Solaris operating environment. However, in the Trusted Solaris environment, you can devote a workspace entirely to a single label. This is very convenient when you are in a multi-level session and do not want to move information between files at different labels.

Storing Files in Separate Directories by Labels

The Trusted Solaris environment provides two special types of directories for storing files and subdirectories with different labels and keeping them separate:

• Multi-level directory (MLD) - A special type of directory that transparently stores information by label in separate subdirectories called single-level directories. Your administrator typically creates your home directory as multi-level directory.

• Single-level directory (SLD) - A hidden subdirectory within a multi-level directory containing files and, optionally, subdirectories at a single label only.

When you attempt to view or access files in a multi-level directory (either through an application such as File Manager or through a shell using standard commands), only those files that are at your current label are visible and accessible. If you keep files at different labels in your home directory, for example, you cannot normally view files at labels other than your current label.

The following figure illustrates the concept of hidden single-level directories within a multi-level directory. The top part of the figure shows the contents of a multi-level home directory called /myHomeDir from the user's view while working at Confidential A B. The lower part of the figure shows the user at Secret A B. Dashed lines and unbolded text indicate hidden directories and files; the solid lines and bolded text indicate visible ones. (Note that the labels associated with the single-level directories are shown in their short form inside parentheses. The labels do not actually appear in the directory names.)

Figure 1-4 SLD Subdirectories

While working at Confidential A B, the user has the following results when trying to list the contents of the /myHomeDir directory:

% pwd
/myhomedir
% ls
file1

At Secret A B, the user sees these results:

% pwd
/myhomedir
% ls
file2    file3

Enforcing MAC for Email Transactions

The Trusted Solaris environment enforces mandatory access control whenever you use email. When you send email, the Trusted Solaris environment prevents users with insufficiently high clearance from receiving it. On the receiving end, email is sorted by the labels within your account range. Your current label must be at the same level as the email message you intend to read; otherwise, you must change your current label.

Clearing Objects Prior to Reuse

The Trusted Solaris environment prevents inadvertent exposure of sensitive information by automatically clearing (erasing) user-accessible objects, such as memory and disk space, prior to reuse. Processes on the system continuously allocate, deallocate, and reuse objects, such as memory and disk space. Failure to erase sensitive data prior to reuse of the object risks exposing the data to inappropriate users. Through device deallocation, Trusted Solaris clears all user-accessible objects prior to allocating them to processes. Note, however, that you must clear any removable storage medium (floppy disk, magnetic tape, and the like) before another user can have access to it.

How the Trusted Solaris Environment Enables Secure Administration

In contrast to traditional UNIX systems, the superuser (root) is not all-powerful in the Trusted Solaris environment. Rather, the ability to override protections is broken into discrete capabilities and assigned to administrative roles so that no single user can compromise the system's security. A role is a special user account that gives the user access to certain applications with the authorizations, privileges, and effective UIDs/GIDs necessary for performing the specific tasks.

In the Trusted Solaris environment:

• Users can only perform functions that override security policy if they are granted special authorizations or privileges by administrators.

• Users are granted access to applications and authorizations on a need-to-use basis.

• System administration duties can be divided among multiple roles.

Authorizations and Privileges

There are usually cases for every security policy when a control must be overridden. In conventional UNIX systems, the superuser has the ability to override all security policy. In the Trusted Solaris environment, a software mechanism called an authorization gives an individual user the right to override a specific security control. There is also a mechanism for overriding controls called a privilege that is associated with software programs and permitted for specific users only. If you are prevented from running a certain task, check with your administrator to see if an authorization is required for that application.

Accessing Applications and Authorizations

In the Trusted Solaris environment, you get access only to those applications you need to do your job. The administrator provides access by assigning one or more rights profiles to your account. A rights profile is a special package of CDE actions, commands, and authorizations. This restriction helps prevent users from misusing applications and harming data on the system. If you need to perform tasks that override the security policy, the administrator will grant you access to either an rights profile containing the necessary authorization or to a role with the authorization to run the program.

If you have access to a special version of a command that can override security policy, you should make sure that your path is set to find this version first; otherwise, you will not be able to take advantage of the security overrides.

In addition, your administrator may assign you a profile shell as the default shell when you log in or assume a role. A profile shell is a special version of the Bourne shell that provides access to a restricted set of applications and capabilities. If you are assigned a profile shell, you can determine which commands are permitted by using the clist command at the command line. The clist command lists all commands available in the profile shell.

If you try to run an action and receive a "Not Found" error message or if you try to run a command and receive a "Not in Profile" error message, you may not be permitted to use this application. Check with your administrator.

If you attempt to execute a command in the profile shell, you may see the message: Warning: command operating outside of trusted path. This means that although you are working in a profile shell and the trusted symbol is being displayed, the current command is not interacting with the trusted computing base.

Predefined Roles

Trusted Solaris provides five predefined roles: root, security administrator, primary administrator, system administrator, and system operator. The root role is used primarily for initial installation. The security administrator role is used for security issues, such as assigning labels or auditing user activity. The system administrator role is used to perform standard system management tasks such as setting up the non-security-relevant portions of user accounts. The system operator role is used for system backups, printer administration, and mounting removable media. The primary administrator role is used to perform any tasks requiring privileges beyond the capabilities of the other roles. If your site uses the predefined administration roles, make sure you know who is performing each set of duties.

No role can configure its own features. For example, the system administrator role is used to set up a user's access to the security administrator role and the security administrator role is used to set a user's access to the system administrator role.