Trusted Solaris Administration Overview

Understanding Labels

Labels and clearances are the heart of mandatory access control in the Trusted Solaris environment. They determine which users can access which files and directories. Labels and clearances consist of one classification component and zero or more compartment components. The classification component indicates a hierarchical level of security such as TOP SECRET or CONFIDENTIAL. The compartment component represents a group of users who may need access to a common body of information. Some typical types of compartments are projects, departments, or physical locations.

The Trusted Solaris environment mediates all attempted security-related transactions. It compares the labels of the accessing entity, typically a process, and the entity being accessed, usually a file, and then permits or disallows the transaction depending on which label is dominant. Labels are also used to determine access to other system resources, such as allocatable devices, networks, frame buffers, and other hosts.

Note -

CMW labels are primarily of importance to programmers. They are composed of regular labels (also called sensitivity labels) and an obsolete label type called an information label. Although they are present in CMW labels for backwards compatibility, information labels are no longer used by the system, and process as ADMIN_LOW.

Dominance Relationships Between Labels

One 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 higher than the second entity's classification. (The security administrator assigns numbers to classifications in thelabel_encodings(4) file. These numbers are compared when determining dominance.)
The set of compartments in the first entity includes all of the second entity's compartments.

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 and access is permitted.

If one label has a higher classification or if it has the same classification and its compartments are a superset 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.

The following table presents examples of label comparisons for dominance. In the example, NEED_TO_KNOW is a higher classification than INTERNAL. There are three compartments: Eng, Mkt, and Fin.

Table 1-5 Examples of Label Relationships


Label 1	Relationship	Label 2
NEED_TO_KNOW Eng Mkt	(strictly) dominates	INTERNAL Eng Mkt
NEED_TO_KNOW Eng Mkt	(strictly) dominates	NEED_TO_KNOW Eng
NEED_TO_KNOW Eng Mkt	(strictly) dominates	INTERNAL Eng
NEED_TO_KNOW Eng Mkt	dominates (equals)	NEED_TO_KNOW Eng Mkt
NEED_TO_KNOW Eng Mk	is disjoint with	NEED_TO_KNOW Eng Fin
NEED_TO_KNOW Eng Mkt	is disjoint with	NEED_TO_KNOW Fin
NEED_TO_KNOW Eng Mkt	is disjoint with	INTERNAL Eng Mkt Fin

Administrative Labels

The Trusted Solaris environment provides two special administrative labels that are used as labels or clearances: ADMIN_HIGH and ADMIN_LOW. (You can rename these two labels in the label_encodings(4) file if you choose.) These labels are used to protect system resources and are intended for administrators rather than normal users.

ADMIN_HIGH is the highest label. ADMIN_HIGH dominates all other labels in the system and is used to protect system data, such as administration databases or audit trails, from being read. You need to work at the ADMIN_HIGH label (typically in a role) or have the privilege to read up from your current label to read data labeled ADMIN_HIGH.

ADMIN_LOW is the lowest label. ADMIN_LOW is dominated by all other labels in a system. Mandatory access control does not permit users to write data to files with labels lower than the subject's label. Thus, applying ADMIN_LOW, the lowest label, to a file ensures that normal users cannot write to it although they can read it. ADMIN_LOW is typically used to protect public executables and configuration files to prevent them from being modified, since only a user working at ADMIN_LOW or with the privilege to write down would be able to write to these files. Typically, only an administrator would work at ADMIN_LOW.

Label Encodings Files

All label components for a system--that is, classifications, compartments, and the associated rules--are stored in a file called label_encodings(4), located in the /etc/security/tsol directory. The security administrator sets up the label_encodings file for the site. A label encodings file contains:

Component definitions - Definitions of classifications, compartments, labels, and clearances, including rules for required combinations and constraints
Accreditation range definitions - Specification of the clearances and minimum labels that define the sets of available labels for the entire system and for normal (non-administrative) users
Printing specifications - Identification and handling information for print banners, trailers, headings, footers, and other security features for printouts
Customizations - Local definitions including label color codes, alternative names for classifications, compartments, and markings in the graphical interface, and other items

For more information on the label_encodings file, see the man page for label_encodings(4) and the guides Trusted Solaris Label Administration and Compartmented Mode Workstation Labeling: Encodings Format.

Label Ranges

A label range is the set of potentially usable labels at which users can operate. Resources that can be protected by label ranges include such things as allocatable devices, file systems, networks, interfaces, frame buffers (effectively, computers), and commands or actions. A label range is defined by a clearance at the top of the range and a minimum label at the bottom. A range is not necessarily all combinations of labels that fall between a maximum and minimum label. There may be rules in the label encodings file that disqualify certain combinations. A label must be well-formed, that is, permitted by all applicable rules in the label encodings file, in order to be included in a range. On the other hand, a clearance does not have to be well-formed. Suppose, for example, that a label encodings file prohibits any combination of compartments Eng, Mkt, and Fin in a label. INTERNAL Eng Mkt Fin would be a valid clearance but not a valid label. As a clearance, it would let a user access files labeled INTERNAL Eng, INTERNAL Mkt, and INTERNAL Fin.

Account Label Range

When you assign a clearance and a minimum label to a user, you define the upper and lower boundaries of the account label range in which that user is permitted to operate. The following equation describes the account label range, using <= to indicate dominated by or the same as:

minimum label <= permitted label <= clearance

Thus, the user is permitted to operate at any label that is dominated by the clearance as long as that label is not strictly dominated by the minimum label. If you do not expressly set a user's clearance or minimum label, the defaults defined in the label encodings file will take effect. Make sure when you assign a clearance that the classification dominates (or is the same as) all classifications at which the user can work and that the list of compartments include all compartments that user might need. Combinations of compartments in the clearance will be governed by rules in the label_encodings file.

To assign single-label operation to a user, you set the user's clearance equal to the minimum label.

Session Range

The session range is the set of labels available to a user during a Trusted Solaris session. The session range must be within the user's account label range and the label range set for the system. If the user selects single-label session mode, the session range will be limited to that label. If the user selects multilabel mode, then the label entered will serve as the session clearance, defining the upper boundary of the session range while the user's minimum label defines the lower bound. The user enters the session at the minimum label and can switch to a workspace at any label in the session range.

How Labeled Files are Stored

In the Trusted Solaris environment, labels are automatically associated with all files and directories, and are stored as extended attributes of the file. These attributes are protected by privilege and mandatory controls.

In addition, special directories called multilevel directories (MLDs) allow files to be isolated by label in subdirectories called single-level directories (SLDs). SLDs are transparent to users and applications.

The purpose of MLDs is to enable applications that are running at different labels to write into what appears to be the same directory. For example, the /tmp directory is often used by multiple applications. For that reason, /tmp is an MLD. Applications are not aware that when they write a file into /tmp they are actually writing the file into the SLD within /tmp that has the label at which the application is running. If a single-level directory corresponding to the label does not yet exist, the Trusted Solaris environment creates one automatically.

New MLDs are built by creating a new folder in File Manager using the MLD option or at the command line using the -M option of the mkdir(1). The crontab(1) and at-job directories are shipped as MLDs so that you can set up batch jobs for a user that run at different labels. See the "Administering cron, at, and batch Jobs" section in Trusted Solaris Administrator's Procedures.

Home directories are MLDs so that accounts can create files and folders at different labels within their home directories. When user or role accounts change into their home directories, they do not need to be aware that they have actually changed into an SLD that is at the same label as their current workspace. For example, when setting up a new account for user janez, the Users tool creates the home directory /export/home/janez as an MLD. When the user janez changes to her home directory, she is automatically and transparently redirected to an SLD within her home directory MLD. The SLD has the same label as her current workspace, so if the workspace has a label of NEED_TO_KNOW, she changes into the SLD that has the NEED_TO_KNOW label.

To allow normal users to create their own MLDs, the administrator role must first create a new directory that is not an MLD and make it writable by normal users. For example, an administrator could create a directory called /myDir/doc mounted by and writable by all developers at a single label, so that design specifications and other project-wide documentation could be kept in one commonly accessible place. Anyone in the development group could then create a new directory within that directory and make it an MLD. If desired, the prefix can be changed from MLD using the mount(1M) command.

Multilevel directory names contain the hidden string .MLD., referred to as an adornment. The adornment is prefixed to the directory name but is not visible to standard UNIX commands.

Single-level directories are named .SLD.n where the number n represents the order in which the SLDs in the multilevel directory are created. Thus, the single-level directories are named .SLD.0, SLD.1, and so on. The implementation is transparent so that directory names with adornments are not displayed except through the special commands in the table below. A user with appropriate privileges can view the contents of a hidden directory outside of the current SLD by explicitly specifying the adornments to the path.

Table 1-6 Adornment-Related Commands


Command Name	Description
adornfc(1)	The `adornfc` command displays the specified directory path name with the final component adorned, that is, the strings `.MLD.` or `.SLD.` used to identify whether the directory is multilevel or single-level.
getfattrflag(1)	The `-m` option indicates whether the directory is an MLD.
getmldadorn(1)	The `getmldadorn` command displays the MLD adornment of the file system on which the specified path name resides.
getsldname(1)	The `getsldname` command displays the single-level directory name associated with the label of the current process within the multilevel directory referred to by path name.
mkdir(1)	When used with the `-M` option or when the directory name has the `.MLD.` adornment, creates a new MLD.
mldpwd(1)	The `mldpwd` command displays the path name of the current working directory, including any MLD adornments and SLD names.
mldrealpath(1)	The `mldrealpath` command displays the canonicalized absolute path name, including any MLD adornments and SLD names. It expands all symbolic links and resolves references to special characters (/. and /..) and translations in path names. The resulting path has no special characters, unadorned multilevel directories, or any hidden SLD names.
rm(1), rmdir(1)	The `-M` option when used with the `-R` option removes SLD subdirectories recursively.

The following figure illustrates the normal view of an SLD, depicting directories as ovals, files as rectangles, visible items with solid lines and bolding, and hidden items with dashed lines and normal font. In this case, the user is operating with a NEED_TO_KNOW Eng Mkt label and executes the ls command as shown on the left side of the figure. The user can view files with the Top Secret label only. The actual structure and contents of myHomeDir, which is a multilevel directory, are shown at the right of the figure.

Figure 1-4 Normal Viewing of a Directory

The following figure demonstrates how a user can view directory contents outside of the current SL. By typing ls /.MLD.myHomeDir/.SLD.*, the user sees all hidden directories in the multilevel directory, in this case, .SLD.0 which contains files with an SL of INTERNAL Eng and .SLD.1 which holds a TOP SECRET file.

Figure 1-5 Viewing the Contents of Multiple SLDs

Applying Labels to Email

All email messages have labels in the Trusted Solaris environment. The underlying tool sendmail(1M) does not deliver mail to a user outside of the user's account range. Use the -p option in the sendmail.cf file to provide for out-of-range mail. Furthermore, the restrictmailq option in the sendmail.cf file is set by default to restrict users from listing mail sent by other users. Only users in the same group as the mail queue can list jobs in the queue. Email operations make use of multilabel directories both for messages queued prior to delivery and for storage of incoming messages. Users are notified separately about mail received at each label in their account range and in the range of any role they have assumed. In addition, an option exists to promote email from administrators from ADMIN_LOW to the user's minimum label.

Applying Labels to Printed Output

You can arrange for labels, handling information, and other security information to be printed out in the banner and trailer pages on a printer by printer basis. The following figure shows a typical banner page. For more information on configuring printing in the Trusted Solaris environment, see "Managing Printing" in Trusted Solaris Administrator's Procedures and "Configuring How Labels are Printed on Banner/Trailer and Body Pages" in Trusted Solaris Label Administration.

Figure 1-6 Typical Print Banner Page