Chapter 1 Introduction to Trusted Solaris Label Encodings

This chapter prepares the administrator who is responsible for creating the label_encodings(4) file. The following facts can help you to identify which administrator at your organization should do this task and to understand what needs to be done:

• The security administrator is the person who defines and plans the implementation of an organization's security policy.

• The task of implementing security policy is performed by a system administrator who logs in and assumes an administrative role called the security administrator role.

• The security administrator role is assigned to one or more administrators who fully understand Trusted Solaris administration.

• The person(s) allowed to assume the security administrator role must be cleared to view and to protect the highest level of information processed on your Trusted Solaris system.

• The security administrator role has the tools and capabilities to apply the organization's security policy while configuring the system.

• The security administrator may or may not be the same person who performs the security administrator role.

• On a Trusted Solaris system, certain types of labels must be defined.

• The components of labels are specified in each organization's label_encodings(4) file.

• The security administrator assigns names (also called words) to the values and bits that make up the internal representation of label components.

• The labeling software translates between the internal and human-readable forms of labels based on the rules in the label_encodings file.

• In the rare organization where human-readable labels are not used, the internal hexadecimal forms of labels can be used exclusively.

• A default version of the label_encodings file is initially installed on each NIS+ master or standalone Trusted Solaris host.

• The install team usually replaces the initially-installed label_encodings file with a version with the site's own labels. (Sometimes the default version is used in non-production environments while administrators or programmers are learning the system.)

• One of the security administrator role's responsibilities is the creation of the label_encodings(4) file that replaces the default version.

If you are working in the security administrator role, this manual is for you. This chapter gets you started with the following:

• Topics that the security administrator role needs to understand before encoding labels in the label_encodings file.

• Steps for planning the encodings file

• A review and expanded definition of some terms defined elsewhere that are needed for the label encoding task.

This chapter assumes you have read and comprehend "Understanding Labels" in Trusted Solaris Administration Overview.

Even if you plan to run without visible labels, read all of this chapter and the next, and especially see "Running Without Labels ".

When Using Either a Government-furnished or Already-Existing Labels File

Some organizations use a government-furnished label_encodings(4) file that is based on Defense Intelligence Agency (DIA) specifications. For a detailed description and for further reference, see the "Preface" in Compartmented Mode Workstation Labeling: Encodings Format, Defense Intelligence Agency document [DDS-2600-6216-93], Sun part number 805-8062-10, which is included in the Trusted Solaris administrator's document set. Sun has added extensions to the government-furnished file in the LOCAL DEFINITIONS section (local meaning local to Sun's implementation). The LOCAL DEFINITIONS section sets various label translation options and assigns colors to labels.

The security administrator role at a site with its own government-furnished label_encodings file should modify the LOCAL DEFINITIONS: section from one of the Trusted Solaris label_encodings files in /etc/security/tsol and append the section to the organization's label_encodings file before it is installed. Chapter 4, Modifying Sun's Extensions in the Local Definitions Section describes how to append the Sun extensions to your file and modify the extensions for your site.

If Your Site Does Not Have a Labels File

In most organizations, a version of the label_encodings(4) file is created by the security administrator role either before or after installation.

Appendix A, Example: Label Encodings File shows an example label_encodings file that is based on the planning described in Chapter 5, Example: Planning an Organization's Labels.

After Installation

An example label_encodings.simple file is in the /etc/security/tsol directory, and it can either be modified or used as is. The introduction to Appendix A, Example: Label Encodings File describes the labels and compartments defined in the example file. Alternately, the default version of the label_encodings file or one of the other label_encodings files in /etc/security/tsol can be modified to suit a site's requirements.

Before Installation

To prepare a label_encodings(4) file in advance, the security administrator role can make a manual copy of the example in Appendix A, Example: Label Encodings File and make modifications in the copy. Alternatively, a label_encodings file can be created using the examples in this manual and in the DIA document.

Creating Labels With Complex Relationships

This manual does not show how to encode the complex relationships between classifications, inverse, and hierarchical words that are sometimes needed. For that level of detail and for further reference, see the Compartmented Mode Workstation Labeling: Encodings Format: Defense Intelligence Agency document [DDS-2600-6216-93], Sun part number 805-8062-10, which is included in the Trusted Solaris document set.

Review of Label-Encodings Related Concepts

The Trusted Solaris User's Guide and the Trusted Solaris Administration Overview describe the distinctions between types of labels and how labels are compared when access control decisions are being made.

"Assuming a Role and Working in a Role Workspace" in Trusted Solaris Administrator's Procedures prepare the security administrator to assume the security administrator role. The security administrator role sets up labels and performs other tasks involved in security administration.

The following definitions review some of the basic label concepts that are directly related to defining and encoding labels. These concepts are needed when making decisions about how sensitivity labels, and user clearances are going to be configured for a site. For more information about these and other related terms you may not recognize, see also the DEFINITIONS in the Intro(2) man page.

How Labels Are Used

In UNIX systems just about everything (such as a spreadsheet, a printer, a letter, a chapter of a book, or a mail message) is handled as a file. Files are stored in directories. (In the window system. files are called documents, directories are called folders and both are displayed as icons.)

Because a user must access files and directories to do just about anything, labels are assigned to all users and administrators and to all files and directories. Labels are compared when access decisions are being made by the Trusted Solaris mandatory access control mechanism.

How Labels Are Defined

Label components are defined by the security administrator role in the /etc/security/tsol/label_encodings file. The following table shows the mandatory sections of the label_encodings file identified by the keywords that start each section. The components that the security administrator role defines in each section are described in the rest of this chapter.

Even though information labels are not used in Trusted Solaris 7, the INFORMATION LABELS section must be present and must have a word defined for every compartment that is specified in the SENSITIVITY LABELS section.

Introduction to Clearances, Minimum Labels, and Account Label Ranges

A clearance label and a minimum label are assigned to each user and role account. These labels are assigned by the security administrator role when configuring the security aspects of the account, using the Labels dialog box in the User Manager. The clearance establishes the upper bound of the set of labels at which the account can work, while the minimum label establishes the lower bound. Clearance labels are defined in the CLEARANCES section of the label_encodings. See also "More About Clearance Labels".

Account Label Range

The set of labels at which a user or role can work at any time is referred to as the account label range. The upper bound of the account label range is the account's clearance, and the lower bound is the account's minimum label. Users who are allowed only to work at a single label have a clearance that equals their minimum label. See "Accreditation Range Examples" for how the account clearance is selected from the total set of labels available to all users on the system.

Two Types of Clearance

There are two types of clearance: the account clearance assigned when the account is created, and the session clearance. When an employee logs into the system, he or she specifies a session clearance that is in effect for the time between login and logout. The session clearance must be within the account's clearance. (See the following section below and "Specifying the Session Clearance" for more about the session clearance.)

Session Clearance

The session clearance is provided to allow an account that is set up to work with multiple labels to voluntarily restrict the range of labels available during a particular session. The session clearance default is the account's clearance. A lower clearance may be chosen.

The session clearance establishes the upper limit on the range of labels at which processes can be run on the behalf of the normal user during a session. The minimum label is always the lower bound on the labels at which an account can work during a session.

Label Ranges on Things Being Accessed

Label ranges are assigned to the following:

• All hosts and networks with which communications are allowed

• File systems

• Allocatable devices: such as tape drives, floppy drives, CD drives, and audio devices

• Other devices that are not allocatable: printers (controlled through a label range set on the name assigned to the printer) and workstations (controlled through a label range set on the framebuffer)

See the various means for setting labels described in Trusted Solaris Administrator's Procedures. "Managing Device Allocation and Setting Device Label Ranges" in Trusted Solaris Administrator's Procedures describes how to set label ranges on devices.

What Labels Ranges Do

Label ranges set limits on:

• The labels at which hosts can send and receive information

• The labels at which processes acting on behalf of users and roles can access files and directories within file systems

• The labels at which users can allocate devices, thereby limiting the writing of files to storage media in these devices

• The labels at which users can send jobs to printers

• The labels at which users can access workstations

Labels are also used in deciding the actual level of sensitivity of information and how information should be handled. In addition, labels are automatically assigned to email messages and printed on printer output.

Types of Labels

Besides the clearance labels mentioned already, there are two other types of labels, sensitivity labels and information labels. One of each type of label must be defined in each site's label_encodings(4) file:

• Clearance

• Sensitivity label

• Information label

Even though information labels are not used in Trusted Solaris 7, one information label must be defined.

All types of labels have these components defined in the label_encodings(4): classifications and optional words.

Classifications

The classification is the hierarchical portion of a label or clearance. Each type of label has one and only one classification. The internal representation of each label type has 15 bits available for storing classification values.

The labels translation software enforces a limit of 256 classification values. A numeric value (integer) from 1 to 255 is assigned to each classification in the label_encodings file. The values 0 is reserved for the ADMIN_LOW administrative label. (See also "Administrative Labels".)

The classification portion of a label indicates a relative level of protection based on the sensitivity of the information contained in a file or directory. In a clearance assigned to a user and to processes that execute applications and commands on behalf of the user, a classification can indicate a level of trust.

A classification with a higher value is said to dominate a classification with a lower value. (Dominance is explained more fully under "Label Dominance".)

Registered

6

Top Secret

6

Need to Know

5

Secret 	

5

Internal Use Only

4

Confidential

4

Public

1

Unclassified

1

At least one sensitivity label, information label, and clearance must be defined. All types of labels need at least a classification component. A set of labels can be made up only of one classification each and no words.

Classifications are defined once for all types of labels in the CLASSIFICATIONS section of the label_encodings(4).

The following table may be used for planning classifications. An asterisk (*) is used where the item is optional.

Words

Words are components of labels other than the classification. While all types of labels use the same classifications, the words used for each type of label can be different, even when they are encoded with the same bits and literally refer to the same thing.

• Compartments (in all types of labels)

  See "Compartments".

For each section for each type of label, the following table shows the subsections in the label_encodings(4) file that define the words in the label and that optionally restrict how the words can be used together.

Compartments

A compartment is one of the optional types of words that may appear in a sensitivity label or clearance. Compartments are called categories in some other trusted systems. Compartments are also sometimes referred to as channels in government organizations.

Compartment words are assigned to bits that are not intrinsically hierarchical. Hierarchies can be established between compartment words, but the hierarchies are based on rules for including bits from one compartment word in the bits defined for another compartment word.

Examples of Compartments

A compartment word can be used in many ways. For example, it can be used to represent an area of interest, a work group, a department, a division, or a geographical area. A compartment word in a label helps identify files and the individuals that are cleared to access them. For example, a classification of NEED TO KNOW in a label can be restricted by the presence of one or more compartment words defined with department names, such as ENGINEERING or HUMAN RELATIONS or LEGAL. A file with NEED TO KNOW LEGAL would be available only to individuals who had NEED TO KNOW classification and the LEGAL compartment word in their clearances.

For another example, a government agency or an international corporation might create a compartment word for each country or continent: USA, Mexico, China, Japan, Africa. A large company might create a compartment for each division: SunSoft, SunFed, SMCC, SunConnect, JavaSoft.

How Compartment Words Are Defined

Compartment words are optionally defined in the WORDS subsection for each label type. Each compartment word is assigned to one or more bits. The following example shows the SUN FEDERAL compartment word specified with a short name (sname) of SUNFED and compartment bits 40-50.

Example 1-1 Example Compartment Definition for a Sensitivity Label

SENSITIVITY LABELS:

WORDS:

name= SUN FEDERAL; sname= SUNFED; compartments= 40-50;

Along with its classification field, each label has a 256 bit compartment field. Each bit is assignable in zero or more compartment words, as shown in Table 1-3. One or more compartment bits can be assigned to each compartment word. Out of the 255 available bits, the number of compartment words that can be created is practically limitless.

The following table can be used to keep track of comparment bit assignments.

Sensitivity Labels (SLs): Uses and Format

The sensitivity label of a file or directory is a fixed security label. A newly-created file or directory is assigned the sensitivity label of the process that creates it, which is usually the sensitivity label of the workspace where the process is started. The sensitivity label stays the same unless explicit action is taken by:

• The object's owner

• An administrator or another user who has the needed authorization

  The authorizations to change a label are described in "Authorizations for Upgrading and Downgrading SLs".

Sensitivity Label Components

Each sensitivity label is made up of a classification and zero or more compartments, as shown in the following table.

The example in the following table shows that one sensitivity label consists only of the classification INTERNAL_USE_ONLY with no compartments, while another sensitivity label is made up of a NEED_TO_KNOW classification and the compartments ENGINEERING and SALES.

INTERNAL_USE_ONLY

Sensitivity Label Internal Representation

Along with its classification field, each sensitivity label has a 256 bit field available for compartments, as shown in Table 1-7. Labels contain zero or more compartments. Each compartment word has 1 or more compartment bits assigned. The same compartment bit may be assigned to more than one word.

Authorizations for Upgrading and Downgrading SLs

A sensitivity label can only be changed by a user or an administrator who has the appropriate authorization in one of his or her profiles. The authorization to change a sensitivity label to one that dominates it is called the upgrade file sensitivity label authorization. The authorization to change a sensitivity label to one that it dominates is called the downgrade file sensitivity label authorization. See also auth_desc(4).

Restricting Users to a Single Label

If a system is configured to run with only a single sensitivity label, all non-administrative user accounts on that system are restricted to work at that single sensitivity label. In such systems, the clearance for every user's account would necessarily be set to be equal to the account's minimum sensitivity label.

In systems running with multiple sensitivity labels, any account may be restricted to work at a single sensitivity label if the security administrator role sets the account's clearance equal to its minimum sensitivity label.

When the security administrator role has configured an account with a account label range that includes multiple sensitivity labels, the user can voluntarily restrict a working session to a single sensitivity label, which is explained in the next section.

Specifying the Session Clearance

Directly after a user logs in and starts a session on a Trusted Solaris host, if the account is set up to use multiple labels, the user can specify which sensitivity labels are available during the session by doing one of the following:

• Restrict the session to a single sensitivity label

• Set the session clearance to be the same as the user's own clearance

• Set a session clearance lower than the user's own clearance

The selected single label or session clearance is in effect throughout the session, from login until logout. During a session, the user may work at any sensitivity label that is dominated by the session clearance and that dominates the user's minimum label. The sensitivity label must be a valid label defined in the label_encodings(4) file, as described in "Valid Labels".

Labeled Workspaces

The Trusted Solaris windowing system is a labels-aware version of the CDE window system. CDE workspaces play an important part in making it possible for users to work at multiple sensitivity labels during a single session.

When the employee logs in for the first time, the first workspace that comes up is assigned the employee's minimum sensitivity label. (Buttons for three additional workspaces are created at the same minimum sensitivity label in the workspace switch portion of the Front Panel.) The employee can bring up additional workspaces and change the sensitivity labels on any workspaces, but he or she cannot set the sensitivity label on a workspace to be higher than the current session clearance--which constrains the user from working at any sensitivity label higher than the session clearance. The sensitivity label of the workspace is assigned to each new window that is created in that workspace.

Any user allowed a multilevel session may relabel any of the workspaces. Any user may specify which workspaces and applications are launched at future logins by means of the Startup dialog box in the Style Manager available on the Front Panel. Because the first workspace that comes up after second and subsequent logins may be specified by the user, the sensitivity label of the first workspace that comes up after any login after the initial login can be at any sensitivity label the user chooses (within the account's label range).

More About Clearance Labels

Clearance labels were introduced in "Introduction to Clearances, Minimum Labels, and Account Label Ranges". Clearance labels have the same components and internal representation as sensitivity labels.

Clearance Label Components

Each clearance label is made up of a classification and zero or more compartments, as shown in the following table.

The example in Table 1-9 shows a clearance label that consists only of the classification INTERNAL_USE_ONLY with no compartments and another clearance label made up of a NEED_TO_KNOW classification and the compartments ENGINEERING and SALES.

Clearance Labels' Internal Representation

Besides its classification field, each clearance label has a 256 bit field available for compartments, as shown in the following table.

How SLs and Clearances Are Used in Access Control Decisions

Sensitivity labels and clearances are compared when access control decisions are made. The clearance of a process executing an application is equal to the session clearance. The sensitivity label and clearance of the process are compared to the sensitivity label of anything that the application tries to access. The labels are compared for dominance. For more details about the mandatory access control rules that are enforced when sensitivity labels are compared, see the DEFINITIONS section in Intro(1).

Within the window system, the sensitivity label of the process generally must equal the sensitivity label of the thing being accessed or access is not allowed. (A notable exception to the read equal/write equal rule include email readers, for which the write up/read down (wurd) rule applies. Writes up are limited by the session clearance.)

Example Mandatory Access Control Decision

If an employee brings up a text editor in a workspace with a sensitivity label of PUBLIC, the process executing the text editor is assigned the same sensitivity label as the workspace.

Figure 1-1 shows a comparison between two sensitivity labels used in making an access control decision. The user is in a workspace with the sensitivity label INTERNAL_USE_ONLY. When he brings up a text editor, the sensitivity label of the process running the text editor is automatically set to be equal to the sensitivity label of his current workspace, and the text editor displays a label of INTERNAL_USE_ONLY. When the text editor attempts to open a file for editing, the sensitivity label of the text editor is compared to the sensitivity label of the file. In the example, because the two sensitivity labels are equal, access is allowed.

Figure 1-1 Comparing the SL of a Text Editor with the SL of the File to be Edited

Label Dominance

When any type of label has a security level equal to or greater than the security level of another label to which it is being compared, the first label is said to dominate the second. This comparison of security levels is based on classifications and compartments in the labels. The classification of the dominant label must be equal to or higher than the classification of the second label, and the dominant label must include all the compartments in the other label.

Two equal labels are said to dominate each other. Another kind of dominance is called strict dominance. One label strictly dominates another label, when the first label has a security level greater than the security level of another label to which it is being compared. Strict dominance is dominance without equality. The classification of the first label must be higher than that of the second label and the first label must contain all the compartments in the second label or, if the classifications of both labels are the same, the first label must contain all the compartments in the second label plus one or more additional compartments for the first label to strictly dominate the second.

Label Translation

Label translation occurs whenever programs manipulate labels. For example, when a program such as getlabel(1) gets the label of a file, before the label can display to the user, the binary representation of the label must be translated into human-readable form. The Trusted Solaris system permits label translations only if the calling process's sensitivity label dominates the label to be translated. If a process attempts to translate a label that the process' SL does not dominate, the translation is disallowed. The sys_trans_label privilege overrides this restriction.

So, for example, when a program has the sys_trans_label privilege in its effective privilege set, the program can translate labels that dominate its process label.

Information Labels in Trusted Solaris 7

Trusted Solaris 7 does not use information labels. The chk_encodings(1M) utility fails unless it finds an INFORMATION LABELS WORDS section defined in the label_encodings(4) file. Copying and pasting the WORDS defined in the SENSITIVITY LABELS section into the INFORMATION LABELS section fills the requirement.

Avoiding Abbreviations and Acronyms in Labels

To create easy-to-understand names for sensitivity labels and to avoid abbreviations and acronyms, specify the short name of the classifications and words equal to their long names. When the long name of a classification is specified to equal the short name, the full sensitivity label name displays alone within brackets. So, for example, with the sensitivity label INTERNAL_USE_ONLY, the security administrator role would define the short name identical to the long name and the sensitivity label would appear as [INTERNAL_USE_ONLY].

Administrative Labels

Two default administrative labels are always defined: ADMIN_LOW and ADMIN_HIGH.

The two administrative labels are always automatically defined for all types of labels:

• Sensitivity labels

• Clearances

ADMIN_LOW is the lowest label in the system with a classification value of 0 and no compartments or markings. The ADMIN_LOW label is dominated by every other label.

ADMIN_HIGH is the highest label in the system with the classification value of 32767. As the highest label in the system, the ADMIN_HIGH sensitivity label and the ADMIN_HIGH clearance have all 256 compartment bits set to 1. The ADMIN_HIGH label dominates all other labels.

System files and commonly-available executables are assigned an ADMIN_LOW sensitivity label. Any files that contain data that should not be viewed by normal users, such as system log files, are maintained at ADMIN_HIGH. Besides being used in sensitivity labels to protect system files, administrative labels are used in information labels and in the clearances and minimum labels of the default administrative roles.

Issues About the Names of Administrative Labels

The names of administrative labels do not need to be changed, but a site's security administrator role can choose to do the following:

• Specify alternate names for administrative labels or

• Hide the names of administrative labels from non-administrative employees, by substituting another label that is within the user accreditation range

Changing the Administrative Labels' Names

The site's security administrator role can activate and possibly edit the two commented-out lines in the label_encodings(4) file (shown in the following example) to substitute alternative names for the administrative labels.

Example 1-2 Changing the Names of Administrative Labels in the label_encodings File

LOCAL DEFINITIONS:

*
*       The names for the administrative high and low name are set to
*       site_high and site_low respectively by the example commands below.
*
*       NOTE:   Use of these options could lead to interoperability problems
*               with machines that do not have the same alternate names.

*Admin Low Name= site_low;
*Admin High Name= site_high;

If desired, see the procedure "To Change the Names of Administrative Labels (Optional)" in Chapter 4, Modifying Sun's Extensions in the Local Definitions Section ."

Specifying Whether Users See Administrative Labels' Names

The option to set a label view allows the security administrator role to determine whether the names for administrative labels are displayed to non-administrative users. Some reasons a site might hide the names of administrative labels are:

• The site assigns each user a single label to work at and chooses not to train users about administrative labels

• The site's security policy treats the names of administrative labels as classified information

  Setting the label view mode to EXTERNAL hides the names, and setting the label view to INTERNAL allows the names to be seen.

External View

When the label view is set to be EXTERNAL:

• The ADMIN_LOW label or its site-specified equivalent name is not shown, and the minimum valid label of the same type is shown instead, and

• The ADMIN_HIGH label or its site-specific name equivalent is not shown and the maximum valid label of the same type is shown instead.

  ---

  Note -

  Keep in mind that the binary label remains the same whichever view is specified and that the label view only determines whether the defined name of an administrative label is replaced by an alternative name when it is displayed.

  ---

  The option for setting the default label only affects whether the name of another label is substituted for the name of either administrative label.

Internal View

The INTERNAL view allows users to see the names of the administrative labels, which are either the strings ADMIN_HIGH and ADMIN_LOW or their administratively-set alternate names. (If desired, see "Changing the Administrative Labels' Names".)

The Hierarchy of Label View Settings

The label view is set to be either INTERNAL or EXTERNAL in three different ways that are described in this section in order of precedence, with the lowest first.

• In the label_encodings(4) file

• In the tsoluser(4) file (set in the User Manager)

• In programs

In the label_encodings File

The demonstration label_encodings(4) file has the label view set to External in the LOCAL DEFINITIONS section, as shown in Example 1-3. The term Default Label View is used because it is the default setting that applies unless it is overridden by either of the other two settings.

Example 1-3 Default Label View Setting

Default Label View is External;

When creating the site's label_encodings(4) file, the security administrator role may choose to accept the External setting or change it to Internal. For what the settings mean, see "Specifying Whether Users See Administrative Labels' Names". Also, this value may be changed by the security administrator role after the system is up and running by later editing of the label_encodings file.

As described in "Changing the Administrative Labels' Names", the security administrator role can specify alternate names for administrative labels in the label_encodings(4) file, so keep in mind that the administrative labels may have been renamed.

In the User Manager

The label view setting in a process can override the system-wide setting. A process' label view is set to be either internal, external, or sys. If sys, the process' label view is set to the setting in the label_encodings file. A process's label view gets set indirectly:

• Each account has its own label view set to be either internal, external, or sys by the User Manager and those settings stored in the tsoluser(4) file.

• The initial process created at login sets the label view process attribute flag based on the setting for the account logging in.

  Specifically, when each user and role account is being configured, the security administrator role specifies a label view using the User Manager menu, either internal, external, or sys. See the following figure.

Figure 1-2 User Manager: Labels Dialog Box

The label view is the first value stored in the labelview field in the account's entry in the /etc/security/tsol/tsoluser file, followed by either showsl or hidesl. In the example entry below, the first setting in the labelview field is internal, and therefore the label view is set to INTERNAL for the locally-created auditadmin administrative role account.

Example 1-4 Example tsoluser Entry for an Audit Administration Role Account

auditadmin:fixed:automatic:Audit Control,Audit Review,Media Restore,:none:5:
lock:internal,showsl:0x000000000000000000000000000000000000000
00000000000000000000000000000:0x7fffffffffffffffffffffffffffffffffffffffffff
ffffffffffffff:utadm:res1:res2:res3

Do not edit the tsoluser(4) file directly. Change any account's label view through the Labels dialog box in the User Manager.

How setpattr(2) Sets the PAF_LABEL_VIEW Flag for a Process

When a user or role starts a process, the tsoluser(4) file entry for the account is consulted and the process attribute flag PAF_LABEL_VIEW is set using setpattr(2), according to the label view specified in the tsoluser file entry for the account. PAF_VIEW_EXT sets the external view and a PAF_VIEW_INT sets the internal view. If the sys label view is specified in tsoluser, the PAF_VIEW_DEF is set equal to the default setting in the label_encodings(4) file.

In Programs

Programs can use library routines [described on the bltos(3) man page and in "Labels" in Trusted Solaris Developer's Guide to set or get the label view of a process.

Regardless of the value of the PAF_LABEL_VIEW flag, a library call used to translate labels from binary to text can specify that labels be translated with either an INTERNAL or EXTERNAL label view. If the VIEW_EXTERNAL or VIEW_INTERNAL flags are not specified in the call to the library routine, translation of ADMIN_LOW and ADMIN_HIGH labels is controlled by the label view process attribute flags. If the label view process attribute flag is defined as VIEW_SYS, the translation is controlled by the label view configured in the label_encodings(4) file.

Valid Labels

Rules in the label_encodings(4) file may disqualify certain combinations of label components. Valid or well-formed labels are those labels that satisfy the rules.

The rules are defined by the constraints specified for each type of label, which include:

• Initial compartments associated with each classification

• The minimum classification, output minimum classification, and maximum classification associated with each word

• Hierarchies defined by the bit patterns chosen for each word

• The required combinations of words

• The combination constraints that apply to the words.

  A sensitivity label must be well formed. Clearances do not need to be well-formed.

Example

If, for example, words A, B, and C are constrained from appearing together in a sensitivity label, the following table shows valid labels and clearances. Note that TS ABC is a valid clearance but is not a valid sensitivity label. The TS ABC clearance would allow a user access to files labeled with TS A, TS B, and TS C.

Accreditation Ranges

Two accreditation ranges are specified in the label_encodings:

• System accreditation range

• User accreditation range

The accreditation ranges are not really ranges--because they do not include all possible combinations of label components between the defined maximum and minimum. See "Accreditation Range Examples".

System Accreditation Range

The system accreditation range always includes administrative labels ADMIN_HIGH and ADMIN_LOW.

Rules in REQUIRED COMBINATIONS and COMBINATION CONSTRAINTS and other sections of the label_encodings file allow and disqualify certain combinations of classifications and words.

Administrators and authorized users can work in this range.

User Accreditation Range

The user accreditation range is the largest set of labels that normal users can access and always excludes ADMIN_HIGH and ADMIN_LOW.

The user accreditation range is determined by the set of rules in the ACCREDITATION RANGE section of the label_encodings(4) file

Accreditation Range Examples

The figures in this section (Figure 1-3, Figure 1-4, and Figure 1-5) illustrate how the system and user accreditation ranges are defined in a label_encodings(4) file with the classifications TOP SECRET (TS), SECRET (S), and CONFIDENTIAL (C) and the compartments A, B, and C.

Figure 1-3 shows which labels are included in and excluded from the system accreditation range when word B is defined in the REQUIRED COMBINATIONS section to always appear with A. TS B, S B, and C B are excluded because B always must appear with A. However, because A is not defined to always appear with B, TS A, S A, and C A are in the system accreditation range.

Figure 1-3 Example of Possible Combinations Restricted by REQUIRED COMBINATIONS

The following figure continues the example, showing that the user accreditation range is described by rules in the same file's ACCREDITATION RANGE section. The possible label combination S A and S alone are excluded by the line that specifies that S A B is the only valid compartment combination for S.

Figure 1-4 User Accreditation Range Constrained by Valid Compartment Combinations

The following figure shows the User Accreditation Range is further constrained by the minimum clearance and minimum sensitivity label settings S A B. C A B and C are now excluded.

Figure 1-5 User Accreditation Range Constrained By Minimum Clearance and Minimum Sensitivity Label

The table below summarizes the differences between the possible combinations, the system accreditation range and user accreditation range in the example.

Normal users without any authorizations can work only with the sensitivity labels in the User Accreditation Range column. The fourth column in Table 1-12 shows the Account Label Range for a user with a clearance of TS A B and a minimum sensitivity label of S A B. (Remember that a clearance does not have to be in the user accreditation range.) The account's label range allows the user to work with the following set of sensitivity labels: TS A, TS, and S A B. As shown in the fifth column of Table 1-12, an account with a clearance of TS A would be allowed to work only with TS A and TS sensitivity labels, because the sensitivity label S A B includes the word B, which is not in the clearance.

The following table can be used for planning compartments and user accreditation range combinations. The ACCREDITATION RANGE settings should be one of the following.

• only valid compartment combinations;

• all compartment combinations valid;

• all compartment combinations valid except;

Administrative Roles Review

By default, Trusted Solaris administrative tasks are divided between two major administrative roles: the security administrator role and the administrator role. The roles do not have direct logins. A user first logs in with her own user name, authenticates herself by providing a password, sets a session clearance (if allowed to work at more than one label), and begins work in a normal user workspace; all processes started by the account have the account's UID. Users who are able to assume an administrative role see an Assume Role option on the Trusted Path menu. Before doing administrative tasks, the user must take another step and select the option from the Trusted Path menu to assume an administrative role. The user has to re-authenticate herself with the role password.

Once the role is assumed, an administrative workspace is then created with a number of unique attributes. The normal user can only work at labels within the user's clearance and cannot have a clearance or minimum sensitivity label outside of the user accreditation range (unless that user has the use all defined labels authorization). The default roles can work at any valid label in the system including the two administrative labels, ADMIN_LOW and ADMIN_HIGH. In the default configuration, the ADMIN_LOW sensitivity label is assigned to an administrative role's initial workspace and to the three additional workspaces that are created and made available in the workspace switch area of the front panel. After the initial assumption of the role, the role can start new role workspaces and label them with any valid sensitivity label in that role`s account accreditation range. An application can be launched with the trusted path process attribute only in administrative role workspace.

In the Trusted Solaris environment, the security administrator and administrator roles work together to install and configure hosts and set up users. The security administrator role oversees the installation to ensure that decisions related to the site's security policy are enforced correctly, specifies label ranges and views for each account, and provides the organization's label_encodings(4) file.

Decision to Make for the Install Team to Follow

Decide whether your site's security policy requires a single sensitivity label or multiple labels

Decide whether or not your site's security policy requires that the names of upgraded files and directories be hidden

Types of Labels That Must Be Specified at Each Site

Each site must define at least one each of the following three types of labels:

• Sensitivity label

• Clearance

• Information label

  ---

  Note -

  The software enforces this requirement even though information labels are not used. If you define words for sensitivity labels, you must define equivalent words for information labels and clearances.

  ---

Configuring How Labels are Printed on Banner/Trailer and Body Pages

The security administrator role can change which labels are printed on banner/trailer and body pages of print jobs and can modify the text that appears on the banner/trailer page. Two fields that are specified in the label_encodings(4) file are:

• Printer banners and

• Channels (handling caveats)

  See Chapter 3, Specifying Labels and Handling Guidelines for Printer Output.

Overview of Planning

Allow time to complete the label_encodings(4) file before installing the system.

Be prepared to spend time on the planning process.

Building the encodings for a site and making it correct both syntactically and semantically is a manual, time-consuming process.

Know your site's security policy.

Many Trusted Solaris installations already have a security policy developed according to government methods. Commercial businesses, even though they may not have as much experience in planning labeled security, can start by examining their goals for information protection and use those goals to make some common-sense decisions about how to use labels. If the company has developed legal requirements for labeling printed information and email, those guidelines are a good place to start. For an example of how one commercial company developed a simple security policy based on its legal department's information labeling requirements, see Chapter 5, Example: Planning an Organization's Labels. For more about setting up your site's security policy, see Appendix A, "Site Security Policy" in Trusted Solaris Installation and Configuration.

Learn about the U. S. government label encodings file whose syntax and rules are used in the default Trusted Solaris installed version.

See the Compartmented Mode Workstation Labeling: Encodings Format: Defense Intelligence Agency document [DDS-2600-6216-93].

Plan to finalize your encodings before installation.

Changing the label_encodings(4) on a running system is risky. See "Changing the label_encodings File After System Start Up" of Chapter 2, Creating or Editing the Encodings File.

Planning the Encodings File

The following practices help achieve the good organization required for a correct label_encodings(4) file that may be extended safely later.

Plan to leave room to add items.

Plan ahead for extending the file later, which may save you from needing to create a whole new file if additions are needed. For example, you could number classifications in increments of 10 to allow intermediate classifications to be added if the need arises. For the same reason, consider spacing compartment bit numbers for possible later additions.

If your site uses inverse compartments and markings, plan to reserve some initial compartment and marking bits for later definition.

If you need to learn more about inverse compartments and markings see the DIA document, Compartmented Mode Workstation Labeling: Encodings Format . See also "Setting Default and Inverse Words".

Determine classifications for the site.

As described under "Classifications", the total number of classification values that you can use is 254. Do not use classification 0.

The classification part of the label represents the relative sensitivity of one classification over another. Irrespective of what you call the human readable names associated with each classification, the system treats a classification whose value is 10 as more security sensitive than a classification whose value is 2.

For CLASSIFICATIONS, COMPARTMENTS, the security administrator role can later change human readable names but cannot change the values without potentially serious complications.

Different WORDS can not be specified with the same classification value. Each classification WORD must be higher or lower than one or more others because all labels must dominate or be dominated by some other label. Assigning the same number to more than one name would create levels of security that are named differently but are treated as the same level by the system. No two labels can evaluate to the same level.

Decide on compartments.

Decide how data and programs are grouped and whether or not any data or programs can be intermixed. For example, perhaps weather data should not be seen by programs dealing with personnel files, but weather data should be accessible to programs that deal with targeting problems.

At this point, keep people out of the picture. Think in terms of what, not who.

Design the names.

CLASSIFICATIONS and WORDS in the label_encodings(4) file have two forms: a mandatory long name and an optional short name. Long names for classifications and any words appear by default in the information label portion of the CMW label. Short names for classifications and any words appear by default within brackets in the sensitivity label portion. Labels on windows are truncated after the real estate on the top of the window is used up, and, even though you can view the full label, so labels on window system objects can be read more easily if you keep the long and short names as short as possible while still retaining meaning.

Arrange the relationships.

Compartments and markings are intrinsically non-hierarchical, even though they can be configured to have hierarchical relationships. They represent bits (or flags) attached to objects or subjects in the system. The combination of those bits determines the accessibility of a subject or object. Before setting up relationships, read very carefully the example section of Compartmented Mode Workstation Labeling: Encodings Format several times, walking through the examples.

One way to make this step easier is to use a large board and pieces of paper marked with your classifications, compartments and markings, as shown in Figure 1-6. With this method, you can visualize the relationships and rearrange the pieces until they all fit together.

When the command, chk_encodings(1M), is used to check label encodings files for errors, it checks syntax only. With the -a option chk_encodings can be used to analyze and report on relationships between labels.

Figure 1-6 Example Planning Board for Label Relationships

Decide which clearances will be available to which users.

Use the following table, if desired, for planning clearances.

Table 1-14 Clearance Planner

CLASS	COMP	COMP	COMP	COMP	COMP	OOMP	Notes

Arrange the labels that will be formed from the classifications and compartments in order of increasing sensitivity.

Associate the definitions for each word with an internal format of integers, bit patterns, and logical relationship statements.

Decide what colors should be associated with labels.

Creating Large Numbers of Labels

Using the 256 compartment bits available for assignment to compartment words, the maximum total number of possible labels that can be constructed using these words is 32767 for each classification. See the following table for the totals of the possible different labels (labels that may dominate each other) and unique labels (labels that do not dominate each other)

Creating Unique Labels

The unique labels can use either words or numbers, such as social security numbers. Creation of large numbers of unique labels is made possible by:

• Defining sets (or groups) of compartments to use in constructing labels, and

• Making sure that each label contains one and only one compartment from each compartment group.

As shown by the examples in the following table, the larger the number of compartment groups you define, the smaller the number of compartment words you can have in each set, and the greater the number of possible unique labels.

The User Manager label dialog box is not suited to constructing large numbers of labels with large numbers of components. The label builder is not designed to enforce the rules, such as ensuring that each label has one compartment from each compartment group. When an organization needs large numbers of labels, a script should be written to automate the assignment of labels to users in the tsoluser(4) file while enforcing the rules.