Chapter 1 Introduction to Trusted Solaris Label Encodings

This chapter prepares the administrator who is responsible for creating the label_encodings(4) file. This chapter covers the following topics:

• "Labels-Related Tasks: Who Does What"

• "Types of Labels, Their Components and Uses"

• "Overview of Planning "

• "Planning the Encodings File"

• "Creating Large Numbers of Labels"

This chapter assumes you have read the following:

• "Assuming a Role and Working in a Role Workspace" in the Trusted Solaris Administrator's Procedures manual, which prepares the security administrator to assume the security administrator role

• "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 " of this manual.

This chapter does not give details about encoding complex relationships between classifications, inverse, and hierarchical words that are needed by some organizations. 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], which is included in the Trusted Solaris document set. Keep in mind that information labels and their components are not used at Sun when using the DIA manual (see also "Sections for Defining Labels").

Labels-Related Tasks: Who Does What

The following defines what needs to be done and can help to identify who should do this task:

• The security administrator is the person who defines and plans the implementation of an organization's security policy, establishes information-protection procedures, makes sure computer users and administrators are properly trained, and monitors compliance.

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

• The security administrator who defines the site's security policy may or may not be the same person who implements the policy while working in the security administrator role.

• The security administrator role is assigned to one or more administrators who fully understand Trusted Solaris administration and who are cleared to view and to protect the highest level of information processed on the Trusted Solaris system.

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

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

• The security administrator specifies the numeric values and bits that make up the internal representation of label components.

• Certain types of labels must be defined.

• The labeling software translates between the internal and human-readable forms of labels, from their binary representation to the character strings assigned to them, based on the rules in the label_encodings file.

• A default version of the label_encodings file is initially installed on every Trusted Solaris host.

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

• One of the responsibilities of the security administrator role is to create the label_encodings(4) file to replace the default version.

• Every computer in the system needs its own copy of the master label_encodings file. For interoperability, the label encodings file on every computer in the system should be the same, or at least should recognize each other's labels.

Types of Labels, Their Components and Uses

Two types of labels are used in the Trusted Solaris system:

• Clearance labels

• Sensitivity labels

Labels, label ranges, and clearances are all used to determine who gets access to what in the Trusted Solaris system. Clearance labels (which are also called clearances) are assigned to users and to processes that act on their behalf. Sensitivity labels are assigned to processes and to files and directories. Sensitivity labels are often referred to simply as labels in the Trusted Solaris documentation set.

Some objects have a default label range that allow access at all labels, and the security administrator can restrict that label range. These objects can be accessed at a single-label within the defined label range. Objects with label ranges include the following:

• All hosts and networks with which communications are allowed

• Network interfaces

• File systems

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

• Other devices that are not allocatable, for example, printers, workstations (controlled through a label range set on the framebuffer, fb0), and serial lines when they are configured for use at login.

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.

The following sections detail these concepts and give examples:

• "How Labels Are Used in Access Control Decisions"

• "Labels' Components"

• "Label Dominance"

• "Accreditation Ranges, Label Ranges, and Valid Labels"

• "System Accreditation Range"

• "User Accreditation Range"

• "Account Label Range"

• "Account Label Range Examples"

• "Session Range"

• "Labeled Workspaces"

• "Label Availability in Trusted Solaris Sessions"

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 restricting the labels at which files can be written to storage media in these devices

• The labels at which users can send jobs to printers

• The labels at which users can log into workstations--in addition to the user's label range, a label range on the frame buffer may be used to restrict access

Labels are automatically assigned to email messages and printed on printer output.

How Labels Are Used in Access Control Decisions

In the Trusted Solaris system, both discretionary access control checks and mandatory access control checks must be passed before access is allowed to an object. Discretionary access control is based on Permission Bits and Access Control Lists (see the DEFINITIONS section of the Intro(1) man page, if needed).

Most of the Trusted Solaris documentation does not use the term sensitivity label. In releases beginning with Trusted Solaris 7, information labels are not supported, so it is no longer necessary to differentiate between sensitivity labels and information labels. However, because the label encodings file still has sections for both sensitivity labels and information labels, this document uses these terms where it is needed to clarify the differences.

Mandatory access control compares the label and clearance label of a process running an application with the label or the label range of anything that the process tries to access, according to a set of rules that is sometimes called the system security policy.

• Site security policy is the security policy set up by an organization to protect its information.

  Using Trusted Solaris may be part of the site's security policy.

• System security policy is the set of rules that is enforced by the operating system software to protect information being processed on the Trusted Solaris system.

If the term security policy appears by itself, consider the context.

The write up/read down (wurd) rule applies when a process tries to access an object.

As shown in the previous table, writes up are always limited by the session clearance. A process cannot read or write an object whose label is higher than the process's clearance.

Strictly speaking everything, whether it is a file, directory, device, or other object, is treated as a file in a UNIX system. However, files and directories have slightly different access rules from each other and from process objects, System V IPC objects, STREAMS objects, network endpoint objects, device objects, and X window objects. In addition, an object can be accessed three different ways shown in the following list, and for each of the three ways an object can be accessed, a slightly-different set of rules applies:

• The name of the file, directory, or device may be viewed

• The contents or the attributes of the file, directory, or device may be viewed

• The contents or the attributes of the file, directory, or device may be modified

For more details about the rules that are enforced when various types of access are attempted, see the DEFINITIONS sections in Intro(1) and Intro(2) man pages.

Simple Mandatory Access Control Example

If a user brings up a text editor in a workspace with a label of PUBLIC, the process executing the text editor gets the same label as the workspace.

Figure 1-1 shows a comparison between two labels used in making an access control decision. When a user in a workspace with the label INTERNAL_USE_ONLY brings up a text editor, the label of the process running the text editor is automatically set to be equal to the label of the 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 label of the process running the text editor is compared to the label of the file. In the example, because the two labels are equal, access for writing is allowed.

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

If the label of a file is less than that of the text editor, the file can be opened only for reading. (For example, a normal user can use a text editor to open and read a system file at ADMIN_LOW while working at INTERNAL_USE_ONLY, but the text editor cannot save a change to the file. Another consequence of the WURD rule, because of the read down requirement a user cannot see a file whose label is higher than the current working label. However, if a normal user knows the name of a file that has a higher label, the text editor could be used to make a change to the higher-labeled file, even though the user cannot see the file's name.

Labels' Components

Both labels and clearance labels are made up of a single classification and zero or more compartment words. The human-readable format of labels is shown in the following table.

The security administrator creates all the label components by assigning names and numeric values to classifications and assigning compartment words to bits in the label_encodings(4) file. Along with a classification field of 15 bits, each label and clearance label has a 256 bit field available for compartments, as shown in Table 1-2. Each compartment word has one or more compartment bits assigned. The same compartment bit may be assigned to more than one word.

The classification portion of a label indicates a relative level of protection. When a label is assigned to an object, the label's classification indicates the sensitivity of the information contained in the object. When a clearance label is assigned to a user, the classification portion of the clearance label indicates the user's level of trust.

The use of one or more optional compartment words in a label can help to group individuals with a common area of interest and to further identify how information should be handled. A compartment word can be used to represent what ever kind of grouping you desire, such as a work group, a department, a division, or a geographical area.

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 have the NEED TO KNOW classification and the LEGAL compartment in their clearances.

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. By these criteria, TS A dominates TS and TS dominates TS.

Another kind of dominance called strict dominance is sometimes required for access. One label strictly dominates another label when the first label has a security level greater than the security level of the other label. 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. By these criteria, TS A B strictly dominates TS A and S A but does not strictly dominate TS A B or S C. Because S C contains a word (C) that is not in the TS A B label, and it does not contain all the words in TS A B, the two labels are said to be disjoint.

The security administrator must make sure that the clearance labels assigned to user or role accounts dominate all the labels the account is allowed to access. An account's clearance must contain the highest classification and all the compartment words that are in any label that the account needs to work at. Suppose, for example, that a label_encodings file prohibits the combination of compartments A, B, and C in a label and that the minimum label allowed is TS with no compartments. TS A B C would be a valid clearance label although it would not be a valid label. As a clearance, it would let a user work at TS A, TS B, TS C, and TS.

Accreditation Ranges, Label Ranges, and Valid Labels

Certain combinations of label components may be disqualified by rule specified by the security administrator in the label_encodings file. By defining combination rules, the security administrator implictly defines all the organization's usable labels.

A valid or well-formed label is one that satisfies any combination rules that may have been defined by the security administrator. The combination rules are defined using one of the means listed below:

• Initial compartments (compartment bits) can be assigned to a classification.

  Initial compartment bits are always associated with the classification when it appears in a label. For more details, see also "Adding or Renaming a Classification" for more about default words and inverse words that are assigned to initial compartment bits.

• A minimum classification, output minimum classification, and maximum classification can be associated with any word.

• Hierarchies among words can be defined by the bit patterns chosen for each word.

• Required combinations of words can be specified.

• Combination constraints can be specified for words.

• A minimum clearance and a minimum sensitivity label must be specified.

  These system-wide minimums establish the lowest clearance and the lowest label that any normal user can have.

Two accreditation ranges listed below are implicitly specified in the label_encodings file:

• System accreditation range

• User accreditation range

The term accreditation range is also sometimes used for the label ranges that are assigned to user and role accounts, printers, hosts, networks, and other objects. Because rules can constrain the set of valid labels, label ranges and accreditation ranges may not include all the potential combinations of label components in a range.

See the following sections: System Accreditation Range and User Accreditation Range for illustrations of how labels can be disallowed by some of the means listed in the previous list. Chapter 2, Creating or Modifying the Encodings File gives more details on how the rules are specified.

System Accreditation Range

The system accreditation range always includes administrative labels ADMIN_HIGH and ADMIN_LOW. The system accreditation range also includes all the well-formed labels that can be made up out of all label components defined in the label_encodings file.

Administrative role accounts are usually the only accounts configured to be able to work at all of the labels within the system accreditation range. An organization may also set up normal user (non-role accounts) to be able to perform a task that can only be done at one of the administrative labels ADMIN_HIGH or ADMIN_LOW. A good example in the default Trusted Solaris system is the install user account that is used for configuring the system after installation. The install account needs to log in at ADMIN_LOW because the site's label_encodings file is not yet installed, and therefore the site's non-administrative labels are not yet defined.

The following figure presents an example of how rules can constrain the labels permitted in a system accreditation range.

Figure 1-2 How System Accreditation Range Is Constrained By Rules

Figure 1-2 (a) shows all potential combinations given the classifications, TS (TOP SECRET), S (SECRET), and C (CONFIDENTIAL), and the compartments, A and B.

Figure 1-2 (b) shows a typical rule from the REQUIRED COMBINATIONS subsection of the SENSITIVITY LABELS section and its effects. The arrows point to the labels disqualified by the rule, which appear with lines through them. The REQUIRED COMBINATIONS syntax B A means that any label that has B as a compartment must also contain A. (Note that the converse is not true; compartment A is not required to be combined with any other compartments.) Since compartment B is only permitted when A is also present, the labels TS B, S B, and C B are not well-formed and hence are not in the system accreditation range.

User Accreditation Range

The user accreditation range is the largest set of labels that normal users can access on a Trusted Solaris system. The user accreditation range always excludes ADMIN_HIGH and ADMIN_LOW. The user accreditation range is further constrained by any rules that constrain the system accreditation range. In addition, the user accreditation range can also be constrained by a set of rules in the ACCREDITATION RANGE section. The following figure continues the System Accreditation range example, showing three different types of rules in the ACCREDITATION RANGE section and their effects on the user accreditation range. The arrows point to the well-formed labels permitted by the particular rule.

Figure 1-3 ACCREDITATION RANGE Portion of label_encodings File

As shown in the right column, the user accreditation range excludes ADMIN_HIGH and ADMIN_LOW. The rule for the TS classification includes all TS combinations except TS B. However, because TS B, along with S B and C B, were previously overruled by the REQUIRED COMBINATIONS rule B A illustrated in Figure 1-2, TS A B, TS A, and TS are the only allowed TS combinations. With S A B defined here as the only valid combination for the S classification, S B is excluded again. All C combinations except C A are valid according the rule shown for the C classification, but since C B was overruled earlier, the only permitted combinations for the C classification are C A B and C alone without compartments.

Make sure that the minimum clearance you plan to set in the label_encodings file is dominated by all the clearances you plan to assign to users. Also make sure that the minimum sensitivity label is similarly dominated by all the minimum labels you plan to assign to users.

Account Label Range

The account label range is the range of labels available to an individual user or role account. It governs which labels are available for the user to work at when logging into the system. (See "Setting the Session Level" in Chapter 2, "Accessing and Leaving the Trusted Solaris Environment," in the Trusted Solaris User's Guide and "Session Range" of this chapter.)

The labels available in the account label range are constrained by:

• The user accreditation range--an unauthorized user cannot use any labels that have been disqualified for the user accreditation range in the label-encodings file.

• The top and bottom of the range can be set by security administrator role who defines security attributes for the account using the SMC User Accounts tool. If no values are set for the account, a DEFAULT USER SENSITIVITY LABEL and the DEFAULT USER CLEARANCE values in the optional LOCAL DEFINITIONS section of the label_encodings file are used, if they are defined. Otherwise, the minimum sensitivity label and minimum clearance set in the ACCREDITATION RANGE section of the label_encodings file are used. The values for each account are stored in the user_attr(4)database:

  • The user clearance defines the top of the account label range.

    A clearance does not have to be a valid label. Because it must dominate all labels at which the account is to work, the clearance must contain all the components of all the labels at which the account is to work.

  • The minimum label sets the bottom of the account label range.

    The minimum sensitivity label set in the label_encodings file defines an absolute minimum on labels at which any unauthorized users can work.

    The SMC User Accounts Properties dialog allows the setting of an account's minimum label to below the label_encodings-defined minimum, if the account has also been assigned a profile with the Set Label Outside User Accred Range authorization. For example, the install user can log in at ADMIN_LOW because that user account has the Outside Accred profile, with the e Set Label OUtside User Accred Range authorization.

Account Label Range Examples

The possible clearances and minimum labels that can be assigned to an account is shown in the following figure based on the accreditation examples from the previous sections.

Figure 1-4 Constraints on Account Label Ranges

TS A B is the highest label in the user accreditation range from the ongoing example and contains the only two compartments permitted to appear in together in a label with any classification: A and B. The example user account range illustrated on the left of the previous figure is bounded at the top by TS A B, which the clearance assigned to the account, and at the bottom by C, the (account) minimum label. As a result of these definitions, the account is constrained to work at labels TS A B, TS A, TS, S A B, C A B, or C. The permitted clearances shown are TS A B, TS A, TS and S A B, with the minimum clearance of S A B set in the label_encodings file Even if TS A B was not a valid label, the security administrator could assign it as a clearance to allow the account to use any valid labels that are dominated by TS and that contain the words A and B. In contrast, if TS was assigned as the account clearance, the only two labels at which the user could work would be TS and C, because TS without any compartments does not dominate S A B or C A B.

If you specify the account's clearance to be the same as the account's minimum label, the user can only work at the specified single label. To do this you would also need to make sure that the minimum clearance you set in the label_encodings file is dominated by all the account clearances you plan to assign.

The following table summarizes the differences between the potential label combinations, the system accreditation range, the user accreditation range, and some example account label ranges . Normal users without any authorizations can work only with the labels in the User Accreditation Range column. The fourth column in Table 1-3 shows the Account Label Range for a user with a clearance of TS A B and a minimum label of S A B, which allows the user to work with the following set of labels: TS A B, TS A, TS, and S A B. As shown in the fifth column of Table 1-3, an account with a clearance of TS and a minimum label of C would be allowed to work only with TS, S, and C labels, because all the other valid labels dominated by TS include the words A and B, which are not in the clearance. A sixth column shows a user authorized to work outside the user accreditation range, assigned a single label of ADMIN_LOW.

Session Range

Setting the range of labels available during a session is possible only when a user account is configured to use multiple labels. The user configured to work at a single label uses that single label throughout every login session. If a user account is set up to use multiple labels, that user can specify which labels are available during the session by doing one of the following:

• Restrict the session to a single 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

When a user logs in and starts a session on a Trusted Solaris host, the Workstation Information dialog box displays. The following indicator displays below the console message area when a user is configured to work only at a single label:

Single Label Session Label: name_of_label

The following indicator displays below the console message area with a check box to the left when the user is configured to work at multiple labels:

Restrict Session To a Single Label

If the user clicks the OK button after checking the box, then a Single-label Login: Setting Session Label dialog box displays, or if the user leaves the box unchecked, a Multilabel Login: Setting Session Clearance dialog box displays. The user then chooses the label or clearance for the session from the dialog box .

The choice of session clearances available in the clearance dialog box range from the account clearance down to the higher of the (accreditation) minimum clearance and the (account) minimum label, subject to any additional required combinations or constraints from the clearance rule definitions in the label_encodings file. The single label dialog allows the account to select among all the valid labels that are dominated by the account's clearance and that dominate the account's minimum label, subject to any required combinations or constraints from the label rule definitions in the label_encodings file.

The single label or session clearance chosen at login is in effect throughout the session until logout. During a multilabel session, the user may work at any valid label that is dominated by the session clearance and that dominates the user's minimum label. Processes started on behalf of a user get a process clearance equal to the session clearance.

The session range is the set of labels available to a user during a Trusted Solaris session. It is a function of:

• The account label range

• The account's choice of session mode (single-label or multilabel)

• The value the account enters in the Single-label Login: Setting Session Label dialog box (if single-label session) or the Multilabel Login: Setting Session LabelClearance dialog box (if multilabel session)

• The label range for the user's workstation

• The security administrator can restrict the default ADMIN_LOW to ADMIN_HIGH label range on a workstation by using the Device Allocation Manager to set the restricted label range on the framebuffer device, for example on fb0) For more information, see "Session Range".

In the ongoing example from Figure 1-4 that is continued in the following figure, the user can specify a session clearance using any well-formed label between TS A B and S A B.

In the next figure, (a) continues the example showing the range of labels available if the user selects a multilabel session with a session clearance of S A B. Since the other potential labels between S A B and C have been disallowed, the user can only work at S A B, C A B, or C.

(b) shows the range of labels if the user chooses a single-label session with a session label of C A B. Note that C A B is below the minimum clearance but is accessible because the user is selecting a session label, not a clearance. Since this is a single-label session, the user can work at only one label; in this example, the user specified C A B, although S A B or C could have been chosen instead.

Figure 1-5 Comparison of Session Ranges

The following figure summarizes the progressive eliminations of available labels in this example. The eliminated labels are shown with a line through them in the range where they are filtered out and are not shown in subsequent ranges.

Figure 1-6 Cumulative Effect of Constraints on a Session Range

Labeled Workspaces

Labeled workspaces help enable users to work at multiple labels during a single session.

If the user selects a range of labels for the session, the first workspace that comes up is at the user's minimum label. Buttons for three additional workspaces are created at the same minimum label in the workspace switch portion of the Front Panel.

Figure 1-7 Workspace Switch Area

The user can bring up additional workspaces using the Add Workspace option from the Trusted Path menu. The label of the active or selected workspace is assigned to each new window or normal user workspace that is created in that workspace. A newly-created file or directory is assigned the label of the process that creates it, which is usually the label of the workspace where the process is started.

Any user allowed a multilevel session can relabel any of the workspaces to any label that is dominated by the current session clearance. Users relabel workspaces by using the Change Workspace Label option on the Trusted Path menu. Users switch labels by changing the label of a workspace and then clicking its button.

The label of the first workspace that comes up in subsequent login sessions after the first login can be at any label of the user's choosing within the account's label range. Any user can use the Startup dialog box in the Tools subpanel on the Front Panel to configure startup sessions' characteristics.

Label Availability in Trusted Solaris Sessions

The following table shows session label limitations and availability based on users' session choices; it continues the example from Figure 1-6. The left column identifies the types of label settings used in sessions. The middle two columns apply to a Multilevel Session and the right two columns apply to a Single-level Session. The columns labeled General Case show how the label types are determined. The columns marked Example show a typical user's session selections at login.

In Example #1, the initial workspace label is set to [CONFIDENTIAL], which is the label at the bottom of the user's account label range. The user can work at a label of [CONFIDENTIAL], [CONFIDENTIAL A B], or [SECRET A B].

In Example #2, the user's initial workspace SL is [SECRET A B]. Since this is a single-level session, the only available workspace label is [SECRET A B].

More About Labels

A label can only be changed by a user or an administrator who has the appropriate authorization.

Authorizations for Upgrading and Downgrading Labels

The authorization to change a label to one that dominates it is called the Upgrade File Label authorization. The authorization to change a label to one that it dominates is called the Downgrade File Label authorization. For definitions for these authorizations, see /etc/security/auth_attr.

Options for Restricting Users to a Single Label

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

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

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

Label Translation

Label translation occurs whenever programs manipulate labels. Labels are translated to and from the character-coded strings to the binary representation. 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. And when the setlabel(1) program sets a label specified on the command line, the character-coded string that makes up the label's name must be translated to the label's internal representation. The Trusted Solaris system permits label translations only if the calling process's 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.

Administering Administrative Labels

Two default administrative labels are always defined.

• 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 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 label. According to the WURD (write up read down) MAC rule, anyone working at any label can read files at ADMIN_LOW, unless the files' DAC permissions deny read access to the account attempting the reading. Files that contain data that should not be viewed by normal users, such as system log files, the label_encodings and vfstab_adjunct files are maintained at ADMIN_HIGH. To allow administrators access to protected system files, the ADMIN_LOW and ADMIN_HIGH administrative labels are assigned as the minimum label and clearance for the default roles. The following sections of this manual describe issues about administrative labels that the security administrator needs to consider.

• "Issues About the Names of Administrative Labels"

• "Specifying Whether Users See Administrative Labels' Names"

• "Specifying Whether Users See Any Labels"

Issues About the Names of Administrative Labels

The site's security administrator role can choose to do the following:

• Specify alternate names for administrative labels (not recommended)

  Because this is not recommended, this manual does not describe how to do it.

• Prevent normal users from seeing the names of administrative labels by substituting names of the lowest and highest labels in the user accreditation range.

  See "Specifying Whether Users See Administrative Labels' Names".

• Prevent normal users from seeing any labels.

  See "Specifying Whether Users See Any Labels"

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. If the label view is set to external, another label is substituted: ADMIN_HIGH is demoted to the maximum label and ADMIN_LOW is promoted to the minimum label within the user accreditation range.

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.

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

• If not otherwise overridden, the system-wide label view is EXTERNAL.

• An optional system-wide setting can be made in the label_encodings(4) file

  The default label_encodings(4) file has the label view set to External in the LOCAL DEFINITIONS section. If the optional definition is not round in the file, the default system-wide setting of EXTERNAL is used.

• The User Accounts and Administrative Roles Tools can set an individual value for any user or role account

  The Security Administrator role can make an individual setting in the Trusted Solaris Attributes tab that is found in both the User Accounts and Administrative Roles Properties dialogs. The values are stored in the user_attr(4) file entry for the user or role account.

  ---

  Note -

  Do not edit the user_attr file directly. Change any account's labels views using the SMC tools.

  ---

  The View: choices are External | Internal | System Default

  If the System Default is chosen, the Default Label View is value in the optional LOCAL DEFINITIONS section of the label_encodings file applies.

• Programs can use library routines to manipulate the label view of the process running the program.

  The label view setting in a process can override the system-wide setting. A process's label view is set to be either internal, external, or sys. If sys, the process's label view is whatever is set in the label_encodings file, and if no value is set in the file, then the default of External is used.

A process's label view gets set indirectly through the following:

• From the user_attr entry for the owner of the process

  When a user or role starts a process, the user_attr 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 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, the PAF_VIEW_DEF is set equal to the optional setting in the label_encodings(4) file, or the default of EXTERNAL that applies if the option is not set.

• From within a program using library routines

  Programs can use library routines [described on the bltos(3TSOL) man page and under "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 form 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 option configured in the label_encodings(4) file or by the default system-wide value of EXTERNAL if the option is not specified.

Specifying Whether Users See Any Labels

The system-wide default is to show labels. The default setting for all accounts in the policy.conf(4) file is show labels. The Security Administrator can change the policy.conf entry to hide labels. The Security Administrator can also override the policy.conf setting for individuals accounts by choosing Hide from the Labels: menu on the Trusted Solaris Attributes tab of the User Accounts and Administrative Roles tools.

See "User Attributes and Defaults in policy.conf" and "Precedence Relationships for Attributes" in Trusted Solaris Administrator's Procedures for more details.

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 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 Modifying 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.

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

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 Table 1-2, the total number of classification values that you can use is 254. Do not use classification 0.

Whatever names you give 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.

Different names can not be specified with the same classification value. Each classification 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.

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

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. Short names can be entered interchangeably with long names when labels are being specified. Long names and short names display in the label dialog boxes.

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-8. 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-8 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-6 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.

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

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)

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 Accounts 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 user_attr(4) file while enforcing the rules.