This chapter covers the following topics:
For a greater level of detail and for further reference, see the Compartmented Mode Workstation Labeling: Encodings Format: Defense Intelligence Agency document [DDS-2600-6216-93]. This DIA reference is included in the Trusted Extensions document set. When using the DIA reference, keep in mind that information labels and their components are not used in Trusted Extensions.
Planning labels requires a general knowledge of site security, and specific knowledge of the syntax of the label_encodings file. The security administrator is responsible for planning labels.
The following task map describes the planning tasks and points to more information.
Task |
Description |
For Instructions |
---|---|---|
Study and outline your label encodings file |
Make a label encodings file that enforces your site security policy. | |
Build an extensible label_encodings file |
Create a file that can be modified without affecting existing label definitions. |
Allow time to build a correct label_encodings file.
Building the encodings for a site and making the encodings correct can be a time-consuming process. A system cannot be configured until the correct label_encodings file is installed.
Know your site's security policy.
Many sites already have a security policy that was developed according to government methods. Commercial businesses, even businesses that do not have much experience in planning labeled security, can start by examining their goals for information protection. These goals can be used 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, see Chapter 6, Example: Planning an Organization's Labels.
For more about setting up your site's security policy, see Appendix A, Site Security Policy, in Oracle Solaris Trusted Extensions Configuration Guide.
Study the U. S. government label encodings file.
The government's description of the file is in the Compartmented Mode Workstation Labeling: Encodings Format: Defense Intelligence Agency document [DDS-2600-6216-93].
Customize the LOCAL DEFINITIONS section for your site.
For suggestions and examples, see Chapter 5, Customizing LOCAL DEFINITIONS.
Finalize your encodings before installing Trusted Extensions.
Changing the label_encodings file on a running system is risky. For more information, see the label_encodings(4) man page.
The following practices help create a correct label_encodings file that can be safely extended later.
For CLASSIFICATIONS and COMPARTMENTS, the security administrator role can later change the textual representation. However, the integer and bit values cannot be changed without potentially serious complications.
Create a label_encodings file.
For ideas, see Sources for Encodings Files. For the procedure, see Managing Label Encodings (Task Map).
Leave room to add items.
Leave gaps when you number classifications.
For example, you could number classifications in increments of 10. The increments allow intermediate classifications to be added later.
Leave gaps in compartment bits.
Space compartment bit numbers for possible later additions.
Reserve some initial compartment bits for later definition.
If your site uses inverse compartments, see Default and Inverse Words. To learn more about inverse compartments, see the DIA reference, Compartmented Mode Workstation Labeling: Encodings Format.
Determine classifications for the site.
As described in Figure 1–2, the total number of classification values that you can use is 254. Do not use classification 0.
The system treats a classification value of 10 as more security-sensitive than a classification value of 2. The textual representations are not used to determine security levels.
The same classification value cannot be assigned to different names. Each classification must be higher or lower, or disjoint, from any other classification. No two labels can evaluate to the same level.
A table can be used to plan classifications. For a completed example, see Table 6–2.
Decide on compartments.
Decide how data and programs are grouped. Decide whether any data or programs can be intermixed. For example, perhaps purchase order data should not be seen by programs that manage personnel files. Perhaps purchase order data should be accessible to programs that deal with shipment tracking problems.
At this point, do not consider users. Think in terms of what, not who.
Design the names.
CLASSIFICATIONS and WORDS in the label_encodings 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.
Arrange the relationships.
Compartments are not intrinsically hierarchical. However, compartments can be configured to have hierarchical relationships. Before setting up relationships, study the example section of Compartmented Mode Workstation Labeling: Encodings Format.
One way to make this step easier is to use a large board and pieces of paper that are marked with your classifications and compartments. For an example, see Figure 2–1. With this method, you can visualize the relationships and rearrange the pieces until they all fit together.
Unless you are creating a set of encodings that must be compatible with another organization's labels, you can assign any valid number as a compartment bit. Keep track of the numbers that you use and their relations to each other.
Decide which clearances to assign to which users.
You can use a table to plan clearances. For a completed example, see Table 6–5.
When you assign a clearance to a user, the classification must dominate all classifications at which the user can work. The clearance can be equal to the user's highest work classification. The compartments in the clearance must include all compartments that the user might need.
Arrange the labels in order of increasing sensitivity.
Associate the definitions for each word with an internal format of integers, bit patterns, and logical relationship statements.
A table can be used to keep track of compartment bit assignments. For a completed example, see Table 6–4.
Copy the WORDS section under SENSITIVITY LABELS to the INFORMATION LABELS section.
Although Trusted Extensions does not support information labels, the INFORMATION LABELS: WORDS: section must be identical to the SENSITIVITY LABELS: WORDS: section to be a valid encodings file.
Decide which colors should be associated with which labels.
For suggestions and examples, see Specifying Colors for Labels.
Analyze the label relationships.
On a system that is configured with Trusted Extensions, use the chk_encodings -a command to write a detailed report on the label relationships in your file.
# chk_encodings -a encodings-file |
The label_encodings file is a flat text file. On a system that is configured with Trusted Extensions, the label of the file is ADMIN_HIGH to prevent ordinary users from reading it. The maximum line length in the label_encodings file is 256 bytes. The file can be edited with any text editor. The security administrator is responsible for the creation and distribution of the label_encodings file.
The label_encodings file can be created or edited on any system. However, the file must be checked and tested on a host that is configured with Trusted Extensions.
Some organizations have a government-furnished label_encodings file that is based on Defense Intelligence Agency (DIA) specifications. Other organizations might want to base their encodings file on one of the files that are provided with the Trusted Extensions packages.
Trusted Extensions installs sample files in the /etc/security/tsol directory. These samples can be modified to your site requirements.
Is installed by Solaris Trusted Extensions software.
Is similar to the example in Appendix A, Sample Label Encodings File.
The introduction to the appendix describes the label components in the file. Chapter 6, Example: Planning an Organization's Labels describes each step in creating this file.
Is the U.S. Government single-level file.
Is Sun's version of the U.S. Government single-level file. The color assignments are different.
Is the U.S. Government multilevel file.
Is Sun's version of the U.S. Government multilevel file. The combinations are less restricted, the minimum clearance is higher, the default user label is lower, and the colors are different.
Alternatively, you can build a label_encodings file from scratch. The syntax and structure of the label_encodings file is provided in Encodings File Syntax.
By default, the label_encodings.simple file is installed as /etc/security/tsol/label_encodings:
ACCREDITATION RANGE: classification= public; only valid compartment combinations: public minimum clearance= needtoknow; minimum sensitivity label= public; minimum protect as classification= public; |
The ACCREDITATION RANGE definition restricts the user to the following label:
PUBLIC is defined as the only classification
PUBLIC is defined as the only valid compartment combination
NEEDTOKNOW is defined as the minimum clearance
PUBLIC is defined as the minimum sensitivity label
PUBLIC is defined as the minimum protect as classification
The Classifications section is illustrated in the following figure.
The compartments in the file are illustrated in the following figure.
There are two government-furnished files, label_encodings.single and label_encodings.multi. The label_encodings.single file is single-level, and the label_encodings.multi is a multilevel version of the single-level file. The files also differ in the settings in the ACCREDITATION RANGE section. The ACCREDITATION RANGE section describes which classifications and compartments are available to ordinary users.
The ACCREDITATION RANGE settings in the label_encodings.multi file are shown in the following excerpt:
ACCREDITATION RANGE: classification= u; all compartment combinations valid; classification= c; all compartment combinations valid; classification= s; all compartment combinations valid; classification= ts; all compartment combinations valid; minimum clearance= c; minimum sensitivity label= u; minimum protect as classification= u; |
The ACCREDITATION RANGE definitions enable the site to use all the classifications and compartment words that are defined in the label_encodings.multi file:
UNCLASSIFIED, CLASSIFIED, SECRET, and TOP SECRET are defined with all compartment combinations valid
CLASSIFIED is defined as the minimum clearance
UNCLASSIFIED is defined as the minimum sensitivity label
UNCLASSIFIED is defined as the minimum protect as classification
The ACCREDITATION RANGE settings in the label_encodings.single file are shown in the following excerpt:
ACCREDITATION RANGE: classification= s; only valid compartment combinations: s a b rel cntry1 minimum clearance= s Able Baker NATIONALITY: CNTRY1; minimum sensitivity label= s A B REL CNTRY1; minimum protect as classification= s; |
The ACCREDITATION RANGE definition restricts the user to the following label:
SECRET is defined as the only classification
SECRET A B REL CNTRY1 is defined as the only valid compartment combination
SECRET ABLE BAKER NATIONALITY: CNTRY1 is defined as the minimum clearance
SECRET A B REL CNTRY1 is defined as the minimum sensitivity label
SECRET is defined as the minimum protect as classification
Sun's implementation of the label_encodings file supports a LOCAL DEFINITIONS section. This section is optional. The section can be appended to an already-existing label_encodings file. The word LOCAL in the keyword that starts the section means local to Sun's implementation.
Options in the LOCAL DEFINITIONS section set label translation options and associate colors with labels. The title bars of application windows display each label against a background of the color that is specified for that label. If an invalid color or no color is specified in the COLOR NAMES option, a default color is supplied. Chapter 5, Customizing LOCAL DEFINITIONS describes how to modify the Sun extensions for your site.