Solaris Trusted Extensions User's Guide

Labels and Transactions

Trusted Extensions software manages all attempted security-related transactions. The software compares the subject's label with the object's label, then allows or disallows the transaction depending on which label is dominant. An entity's label is said to dominate another entity's label if the following two conditions are met:

Two labels are said to be equal if the labels have the same classification and the same set of compartments. If the labels are equal, the labels dominate each other. Therefore, access is permitted.

If one of the following conditions is met, then the first label is said to strictly dominate the second label.

A label that strictly dominates a second label is permitted access to the second label.

Two labels are said to be disjoint if neither label dominates the other label. Access is not permitted between disjoint labels.

For example, consider the following figure.

Illustration shows a Top Secret classification with two
possible compartments, A and B.

Four labels can be created from these components:

TOP SECRET AB dominates itself and strictly dominates the other labels. TOP SECRET A dominates itself and strictly dominates TOP SECRET. TOP SECRET B dominates itself and strictly dominates TOP SECRET. TOP SECRET A and TOP SECRET B are disjoint.

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. That is, the subject's label includes all compartments that are allowed access to the object. TOP SECRET A can read TOP SECRET A and TOP SECRET data. Similarly, TOP SECRET B can read TOP SECRET B and TOP SECRET data. TOP SECRET A cannot read TOP SECRET B data. Nor can TOP SECRET B read TOP SECRET A data. TOP SECRET AB can read the data at all labels.

In a write transaction, that is, when a subject creates or modifies an object, the resulting object's labeled zone must equal the subject's labeled zone. Write transactions are not allowed from one zone to a different zone.

In practice, subjects and objects in read and write transactions usually have the same label and strict dominance does not have to be considered. For example, a TOP SECRET A subject can create or modify a TOP SECRET A object. In Trusted Extensions, the TOP SECRET A object is in a zone that is labeled TOP SECRET A.

The following table illustrates dominance relationships among U.S. Government labels and among a set of industry labels.

Table 1–1 Examples of Label Relationships in Trusted Extensions
 

Label 1 

Relationship 

Label 2 

U.S. Government Labels 

TOP SECRET AB

(strictly) dominates 

SECRET A

TOP SECRET AB

(strictly) dominates 

SECRET A B

 

TOP SECRET AB

(strictly) dominates 

TOP SECRET A

 

TOP SECRET AB

dominates (equals) 

TOP SECRET AB

 

TOP SECRET AB

is disjoint with 

TOP SECRET C

 

TOP SECRET AB

is disjoint with 

SECRET C

 

TOP SECRET AB

is disjoint with 

SECRET A B C

Industry Labels 

Confidential: Restricted

dominates 

Confidential: Need to Know

 

Confidential: Restricted

dominates 

Confidential: Internal Use Only

 

Confidential: Restricted

dominates 

Public

 

Confidential: Need to Know

dominates 

Confidential: Internal Use Only

 

Confidential: Need to Know

dominates 

Public

 

Confidential: Internal

dominates 

Public

 

Sandbox

is disjoint with 

All other labels 

When you transfer information between files with different labels, Trusted Extensions displays a confirmation dialog box if you are authorized to change the label of the file. If you are not authorized to do so, Trusted Extensions disallows the transaction. The security administrator can authorize you to upgrade or downgrade information. For more information, see Performing Trusted Actions.