This chapter prepares the administrator who is responsible for creating the label_encodings(4) file. This chapter covers the following topics:
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").
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.
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:
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.
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.
Write Up to Session Clearance and Write Equal |
SL[Process] <= SL[Object] |
Read Down and Read Equal |
SL[Process] >= SL[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.
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.
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.
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.
Table 1-1 Components of a Label
Classification |
Compartments |
---|---|
name |
[word1, word2, ..., wordN] |
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.
Table 1-2 Bits and Values for Classification and Compartment Components
Classification |
Compartments |
---|---|
15 bits 32,767 possible values 256 values limit enforced |
256 bits possible compartment and bit combinations: 10 to the 70 power |
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.
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.
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:
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.
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 (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.
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.
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.
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.
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.
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.
Table 1-3 System and User Accreditation Range and Account Label Range Examples
Possible Labels |
System Accreditation Range |
User Accred.Range |
Account Label Range (with TS A B Clearance, S A B Min Label) |
Account Label Range (with TS Clearance, C Min Label) |
Account Label Range (with ADMIN_LOW Clearance and Min Label and the |
---|---|---|---|---|---|
ADMIN_HIGH |
ADMIN_HIGH |
|
|
|
|
TS A B |
TS A B |
|
TS A B |
|
|
TS A |
TS A |
TS A |
TS A |
|
|
TS |
TS |
TS |
TS |
TS |
|
S A B |
S A B |
S A B |
S A B |
|
|
S A |
|
|
|
|
|
S |
|
|
|
S |
|
C A B |
C A B |
|
|
|
|
C A |
C A |
|
|
|
|
C |
C |
C |
|
C |
|
ADMIN_LOW |
ADMIN_LOW |
|
|
|
ADMIN_LOW |
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:
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.
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.
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.
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.
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.
Table 1-4 Labels in Trusted Solaris Sessions
|
Multilevel Session |
Single-level Session |
||
---|---|---|---|---|
|
General Case |
Example #1: Multilevel with clearance of [SECRET A B] |
General Case |
Example #2: Single-level with session label of [SECRET A B] |
Initial Workspace Label (at first login) |
Lowest label in account label range. |
[CONFIDENTIAL] |
Session label specified by user |
[SECRET A B] |
Available workspace SLs |
Any label in account label range up to the session clearance |
[CONFIDENTIAL] [CONFIDENTIAL A B] [SECRET A B] |
Session label specified by user |
[SECRET A B] |
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].
A label can only be changed by a user or an administrator who has the appropriate authorization.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
Table 1-5 Classifications Planner
name= |
sname=/*aname= |
value= |
*initial compartments= bit numbers/WORD |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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.
Table 1-7 Compartment Bit Tracking Table
|
|
|
|
|
|
|
|
|
|
| ||||||
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)
Table 1-8 Potential Numbers of Labels for Each Classification# of Unique Labels | Total # of Different Labels |
---|---|
10 to the 40th power | 10 to the 70th power |
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.
Table 1-9 Example: Defining Elements of Unique LabelsNumber of Groups of Compartments | Number of Compartments in each Groups | Number of Possible Disjoint Labels |
---|---|---|
85 | 3 | 10 to the 40th power |
4 | 20 (company set) 50 (division set) 50 (group set) | 6 million |
9 | 10 | more than all the U.S. social security numbers |
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.