Chapter 2 Creating or Modifying the Encodings File

This chapter describes the steps for preparing the label_encodings(4) file.

This chapter includes these topics:

• "Preparing the Label Encodings File"

• "Central Administration"

• "Tools for Editing and Checking the label_encodings File"

• "Changing the label_encodings File After System Start Up"

• "For a Site Using a Government-furnished Labels File"

• "For a Site Without a Previously-existing Labels File "

• "Running Without Labels"

• "Word Order Requirements"

• "Adding or Renaming a Classification"

• "Setting Default and Inverse Words"

This chapter also describes these procedures:

• "To Modify the label_encodings File"

• "To Copy the label_encodings File to a Floppy Disk"

• "To Copy the label_encodings File from a Floppy Disk"

• "To Add Sun Extensions to a Pre-Existing Label Encodings File"

• "To Set Up No Labels Operation"

• "To Add or Rename a Classification in the Default label_encodings File"

• "To Specify Default and Inverse Words"

• "To Replace the Single Label in the Default Single-Label Encodings File"

• "To Make Your Own Single-label Encodings File"

• "To Configure Labels Not Visible to Users"

• "To Ensure Labels Map to CIPSO Labels"

Preparing the Label Encodings File

The overall process of configuring the label_encodings file is described below:

• Before the install team starts post-installation configuration, the security administrator finishes the analysis and planning described in Chapter 1, Introduction to Trusted Solaris Label Encodings.

  The security administrator prepares a site-specific security policy, decides what labels the site needs and which computer users can work at which labels, and prepares guidelines for the install team to follow when configuring users and hosts.

• The Security Administrator role prepares the label_encodings(4) file, as described in this chapter.

  If a label_encodings file has not been used previously at the site, the Security Administrator role can create one by doing one of the following:

  • Typing in and modifying a copy of the label_encodings files shown in Appendix A, Example: Label Encodings File

  • Waiting until after installation to copy and modify a demonstration file.

    ---

    Note -

    Since creating the label_encodings file is usually a lengthy process, it is recommended that the encodings file be prepared beforehand.

    ---

• The install team installs the site-specific label_encodings file before finishing the configuration.

For a Site Using a Government-furnished Labels File

Some organizations use a government-furnished label_encodings(4) file that is based on Defense Intelligence Agency (DIA) specifications. Sun's implementation of the label_encodings file supports an optional LOCAL DEFINITIONS section that 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 can be defined to set various label translation options and to associate colors with labels. Windows applications display each label against a background of the color specified for that label. If an invalid color or no color is specified in the COLOR NAMES option, a default color is supplied.

The Security Administrator role at a site with its own government-furnished label_encodings file can append a LOCAL DEFINITIONS: section to the organization's label_encodings file and then specify any desired options before the file's installation. Chapter 4, Modifying Sun's Extensions in the Local Definitions Section describes how to modify the Sun extensions for your site.

For a Site Without a Previously-existing Labels File

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

The Security Administrator can use the example label_encodings file in Appendix A, Example: Label Encodings File, which is based on a planning example in Chapter 5. The introduction to Appendix A describes the labels components defined in the example file.

Before Installation

To prepare a label_encodings(4) file in advance, the Security Administrator role can manually make a copy of the example in Appendix A, Example: Label Encodings File and make modifications in the copy. Alternatively, a label_encodings file can be created from the examples in this guide and in the Compartmented Mode Workstation Labeling: Encodings Format.

After Installation

The example label_encodings.simple file shown in Appendix A, Example: Label Encodings File can be found in the /etc/security/tsol directory, and this label encodings file can either be modified or used as is. Alternately, the default version of the label_encodings file or one of the other label_encodings files in /etc/security/tsol can be modified to suit a site's requirements. See Appendix B for the differences between the default single-label and multilabel files.

Central Administration

If a naming server is used, the master label_encodings file is installed during the naming server's configuration. After the naming server is fully configured (with the master label_encodings file in place), the install team goes on to install the other hosts in the Trusted Solaris distributed system. The Security Administrator role should ensure that an identical copy of the label_encodings file is installed on every host. The label_encodings file is a local file on each host.

Tools for Editing and Checking the label_encodings File

The label_encodings file is a flat text file. Its label is ADMIN_HIGH to prevent normal 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. During development of the file, the labels and their relationships can be checked by using the chk_encodings(1M) command with the -a option on the command line in a terminal. The file must pass chk_encodings(1M) before it is installed on the working system.

The Security Administrator role uses one of the two actions shown in Table 2-1. The actions are in the System_Admin folder within the Application Manager.

Starting with release 7, the Trusted Solaris environment does not support information labels. However, a label_encodings file still needs information labels defined. The chk_encodings(1M) utility fails unless the label_encodings(4) contains an INFORMATION LABELS WORDS section that defines the same bits defined SENSITIVITY LABELS WORDS section.

The label_encodings file may be created or edited on any system. However, it must be checked and tested on a host running the Trusted Solaris operating environment.

Suggested Working Policies

Make a backup copy (on a tape or floppy disk) of the original file installed with the system. If modifying the file on an operational system, back up the current file.

If your modifications create labels that cannot be resolved, you would need to manually reset labels to ADMIN_LOW before assigning the new labels from the modified file. Restore a known, usable label_encodings file from tape or floppy until problems with the new version are debugged. Backup copies are made using File Manager options.

The File Manager allows the Security Administrator role to restore ownership, group, and permissions on files. By default, the needed changes to maintain the correct file attributes cannot be made by using utilities on the command line.

Code the file using any text editor, and save a hard copy when done.

This procedure is detailed in "To Modify the label_encodings File". As soon as possible after you are satisfied with the file, print it out, and keep a record.

Check the syntax and relationships of the labels with the chk_encodings command and the -a option.

Check the syntax with the chk_encodings(1M) command.

Test the encodings file on a standalone test machine if possible before moving it to a working system.

Place an identical copy of the label_encodings file on every machine.

Changing the label_encodings File After System Start Up

After the Trusted Solaris system is fully configured and running, the Security Administrator role can later modify the label_encodings(4) file. See the man page for what to avoid and for how to safely make other changes.

Running Without Labels

An organization may not want non-administrative users to see labels or be aware of mandatory access controls. By following the steps in "To Set Up No Labels Operation", the Security Administrator role can configure what appears to be a no labels operation, so that all normal users work in an environment that is visually almost the same as working in the Solaris environment with the CDE window system.

Even if non-administrative users do not see labels, certain labels must always be present:

• ADMIN_LOW and ADMIN_HIGH clearances and labels are always included and do not need to be defined

• One sensitivity label in the user accreditation range must be defined

• One clearance in the user accreditation range must be defined

• One information label in the user accreditation range must be defined (even though information labels are not used in the Trusted Solaris 7 operating environment and later releases)

Even though the Trusted Solaris 7 operating environment does not use information labels, the label_encodings file cannot pass chk_encodings(1M) unless it has information labels defined. To fulfill this software requirement, copy the words defined in the SENSITIVITY LABELS WORDS to the INFORMATION LABELS WORDS section.

Setting Up Single-label Operation

You can use or modify the default example single-label file (/etc/security/tsol/label_encodings.single), copy the /etc/security/tsol/label_encodings.simple file manually from Appendix A, or create an encodings file with one classification and any number of compartments. The following example shows the settings in the ACCREDITATION RANGE: section with a single ANY_CLASS classification defined and compartments words A, B, and REL CNTRY 1 specified for all types of labels.

ACCREDITATION RANGE:

classification= ANY_CLASS;      only valid compartment combinations:

ANY_CLASS A B REL CNTRY1

minimum clearance= ANY_CLASS A B REL CNTRY1;
minimum sensitivity label= ANY_CLASS A B REL CNTRY1;
minimum protect as classification= ANY_CLASS;

Any of these ways of creating single-label operation also require supporting procedures described in "To Configure Labels Not Visible to Users".

Sections for Defining Labels

Label components are defined by the Security Administrator role in the /etc/security/tsol/label_encodings file in the sections described here. The encodings are comprised of a VERSION specification and seven mandatory sections: CLASSIFICATIONS, INFORMATION LABELS, SENSITIVITY LABELS, CLEARANCES, CHANNELS, PRINTER BANNERS, AND ACCREDITATION RANGE, which must appear in the order given. An optional LOCAL DEFINITIONS section may follow. Mandatory means only that all the keywords must be present. Not all keywords must be defined. See the notes for each section for what must be defined and what is optional.

For all the required sections, the keywords shown must be present, but not all of the sections must have elements defined. This means that you could have a valid label encodings file with only CLASSIFICATIONS and ACCREDITATION RANGE definitions.

Word Order Requirements

The order in which words are configured for sensitivity labels and clearances is not enforced, but it is important when setting up relationships between words. See "Specifying CHANNELS" of Chapter 3, Specifying Labels and Handling Guidelines for Printer Output for examples of how the order affects how words must be encoded. See also the Compartmented Mode Workstation Labeling: Encodings Format: Defense Intelligence Agency document [DDS-2600-6216-93]DIA] manual.

If a compartment word is defined for one type of label (by assigning the compartment word to one or more bits) in the label_encodings file, then the same bits must be assigned to a word in the definition of the other types of labels. While all types of labels use the same classification names, the words used for each type of label can be different, even when they are encoded with the same bits and literally refer to the same thing. Clearance labels may allow combinations of words that have been disallowed in the definitions for sensitivity labels words.

By convention, the WORDS in the SENSITIVITY LABELS section are arranged in increasing order of importance.

Adding or Renaming a Classification

The Security Administrator role can replace classification names defined in the default label_encodings file, define new classification names, or create a new file with unique classifications.

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

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

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

A classification with a higher value is said to dominate a classification with a lower value. The following table shows two sets of label names that are assigned to the same values in two example label_encodings file in the /etc/security/tsol directory. The left column shows example information protection labels from the label_encodings.simple file and the middle column shows example labels from the label_encodings.gfi.multi file. A label with the Registered or Top Secret classification would dominate all labels with any other classification shown.

Registered

Top Secret

6

Need to Know

Secret

5

Internal Use Only

Confidential

4

Public

Unclassified

1

Number of Classifications

The total number of classifications that can be defined at a site is 255.

Keywords Defined for Classifications

The following table shows the keywords that can be defined for classifications. Keywords that begin with an asterisk (*) are optional. See "Setting Default and Inverse Words" for more about how to set up optional initial compartments and markings that may be associated with classifications.

sname=

Unless you are creating a set of encodings that must be compatible with another organization's label encodings, do not worry about which numbers to use for compartment bits. Keep track of the ones you use and their relations to each other.

The following example shows the top of the demonstration Trusted Solaris label_encodings file, with the CLASSIFICATIONS section.

Example 2-1 Trusted Solaris Demonstration label_encodings File (Top)

CLASSIFICATIONS:

*
name= UNCLASSIFIED;  sname= U;  value= 1;
name= CONFIDENTIAL;  sname= C;  value= 4; initial compartments= 4-5 190-239;
name= SECRET;        sname= S;  value= 5; initial compartments= 4-5 190-239;
name= TOP SECRET;    sname= TS; value= 6; initial compartments= 4-5 190-239;

Each classification defined in Example 2-1 has the mandatory name, sname, and value. The CONFIDENTIAL, SECRET, and TOP SECRET classifications have initial compartments, while UNCLASSIFIED has none.

The following table shows some initial compartments bit assignments and what they mean.

Some of the initial compartments shown in Example 2-1 are used later to define default and inverse words, and some are reserved for possible later definitions of inverse words.

The following example shows a simple set of classifications that have no initial compartments.

Example 2-2 Simple Classifications Defined Without Initial Compartments or Markings

CLASSIFICATIONS:

name= PUBLIC; sname= PUBLIC; value= 1;
name= INTERNAL_USE_ONLY; sname= INTERNAL; aname= INTERNAL; value= 4;
name= NEED_TO_KNOW; sname= NEED_TO_KNOW; aname= NEED_TO_KNOW; value= 5;
name= REGISTERED; sname= REGISTERED; aname= REGISTERED; value= 6;
initial compartments= 10;

Setting Default and Inverse Words

When a bit is defined as an initial compartment, that means that the bit is on 1 in every label that contains the classification. Any bit specified for an initial compartment can be defined later in the label_encodings file so as to assign the bit to either a default word or an inverse word.

• A default compartment word is a word that appears in any label that contains the classification.

• An inverse compartment word is a word that appears in a label that has the associated classification when another word you define with the inverse compartment's bit is not present.

The following table summarizes the requirements for initial compartments values associated with classifications.

The following example shows the PUBLIC classification assigned no initial compartments while the SUN FEDERAL classification is assigned initial compartments 4 and 5.

Example 2-3 Simplified Assignment of Initial Compartments

name= PUBLIC;  sname= P;  value= 1;
name= SUN FEDERAL;  sname= SUNFED;  value= 4; initial compartments= 4-5

With the bits assigned in Example 2-3, a label that includes the PUBLIC classification has no default compartments assigned, while a label that includes the SUN FEDERAL classification always has compartment bits 4 and 5 turned on. See the example below and the following text for how these initial compartment bits can be assigned to words.

Example 2-4 Example of Defining Default and Inverse SENSITIVITY LABELS Words

SENSITIVITY LABELS:

WORDS:

name= DIVISION ONLY;     sname= DO;    minclass=  SUN FEDERAL; compartments= 4-5;
name= SMCC AMERICA;     sname= SMCCA;  minclass= SUN FEDERAL; compartments= ~4;
name= SMCC WORLD;     sname= SMCCW;    minclass= SUN FEDERAL; compartments= ~5;

The example above shows WORDS defined in the SENSITIVITY LABELS section of a label_encodings file. Compartment bits 4 and 5 are assigned to the word, DIVISION ONLY. Both compartment bits 4 and 5 are each also associated with an inverse word: SMCC AMERICA is assigned to the inverse compartment bit ~4 and SMCC WORLD is assigned to the inverse compartment bit ~5. As a result, a sensitivity label with the SUN FEDERAL classification initially includes the word DIVISION ONLY and its binary representation has the compartment bits 4 and 5 turned on, while a sensitivity label with the PUBLIC classification always has compartment bits 4 and 5 turned off, and as a result, the words SMCC AMERICA and SMCC WORLD are included in the label. Because a minclass of IUO is specified for the inverse words, SMCC AMERICA and SMCC WORLD are not displayed in the PUBLIC sensitivity label; the presence of these two inverse words is understood.

For any compartment or marking bits not reserved for later assignment, remember that for every initial compartment bit specified, you need to assign a word to the bit in the SENSITIVITY LABELS: WORDS:, INFORMATION LABELS: WORDS:, and COMPARTMENTS: WORDS: sections.

Defining Compartment Words

Compartments are optional words that may be defined to appear in labels. Compartments are called categories in some other trusted systems. Compartments are used to indicate the special handling procedures to be used for the information whose label contains the compartment and the general class of people who may have access to the information.

Compartment words are assigned to non-hierarchical bits. Hierarchies can be established between compartment words based on rules for including bits from one compartment word in the bits defined for another compartment word.

Compartment words are optionally defined in the WORDS subsection for each label type. Each compartment word is assigned to one or more bits.

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

The following example shows the SUN FEDERAL compartment word specified with a short name (sname) of SUNFED and compartment bits 40-50.

Example 2-5 Example Compartment Definition for a Sensitivity Label

WORDS:

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

Along with its classification field, each label has a 256 bit compartment field. Each bit is assignable in zero or more compartment words, as shown in Table 2-6. Each word can have one or more compartment bits assigned. Out of the 255 available bits, the number of compartment words that can be created is practically limitless. See "Creating Large Numbers of Labels" for examples.

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

• only valid compartment combinations;

• all compartment combinations valid;

• all compartment combinations valid except;

Hierarchical Words

Hierarchical compartments can be used when you want some way to differentiate between documents that have to be accessible to everyone in a larger group and documents that can be accessed only by subgroups. Hierachical compartments can be created by:

• Assigning shared bits to words

• Defining required combinations

Using Bit Combinations to Establish Hierarchies

By defining a word that uses one bit and a second word that uses that same bit along with a second bit, you define a hierarchical relationship between the two words. The compartment word that is more general must be defined below the word that is more specific.

For example, by defining a word that uses bit number 1 and another word that uses bits number 1 and 2, you give the two words a hierarchical relationship. The following screen example shows definitions for a Sales compartment with two subcompartments, Direct Sales, and Indirect Sales. It supposes that a single classification named WebCo is defined.

Figure 2-1 Bit Combinations Defining Hierarchical Relationships

name= Direct_Sales;   compartments= 1, 2
name= Indirect_Sales;   compartments= 1, 3
name= Sales;   compartments= 1

The definition in the screen example allows the WebCo company to differentiate between documents that can be accessed by anyone in the entire sales force, documents that can be accessed only by members of the indirect sales force, and documents that can be accessed only by members of the direct sales force.

• The Security Administrator can give the WebCo Direct_Sales clearance to employees in the direct sales organization and give the WebCo Indirect_Sales clearance to employees in the indirect sales organization.

• Documents created by anyone working at the WebCo Direct_Sales label get the same label, so the documents are only accessible to employees in the direct sales department.

• Anyone in the indirect or direct sales forces can work at the WebCo Sales label because the compartment word Sales is below both the Direct_Sales and Indirect_Sales words. Creating documents at the WebCo Sales label makes the documents available to everyone in the Sales department.

Using REQUIRED COMBINATIONS to Establish Hierarchies

If two words are specified together in the REQUIRED COMBINATIONS section, the second label is added to the label whenever the first word is used. The following example shows a definition of the Direct Sales, Indirect_Sales, and Sales that serves essentially the same effect as the example in Figure 2-2. The difference is that the Direct_Sales word will always have the Sales word with it

Figure 2-2 REQUIRED COMBINATIONS Used to Establish Hierarchies

name= Direct_Sales;   compartments= 2
name= Indirect_Sales;   compartments= 3
name= Sales;   compartments= 1

REQUIRED COMBINATIONS:

Direct_Sales            Sales
Indirect_Sales          Sales

Cautions About Mapping Labels to CIPSO Labels

When a template assigned to a computer is specified with one of the CIPSO label indicators, the trusted networking software derives a CIPSO label from the message's label and inserts the CIPSO label into the IP options portion of packets sent to that computer. For a label to map to and from a CIPSO label, the classification value must be less than or equal to 255 and all compartment bit numbers must be less than or equal to 239.

By default, a message to a CIPSO-identified host is dropped if it is sent with a sensitivity label that cannot be mapped to a CIPSO label. The ADMIN_HIGH label is too big to map to a CIPSO label, so, by default, a message sent at the ADMIN_HIGH label to a CIPSO-identified host is always dropped. To avoid this, the Security Administrator role can add the tsol_admin_high_to_cipso switch set equal to 1 in the /etc/system file. Setting this switch causes the label on a packet to be mapped to a valid CIPSO label with the highest classification and all compartments turned on, instead of being dropped. See "To Change Configurable Kernel Switch Settings" under "Changing and Accessing Security Information (Tasks)" in Trusted Solaris Administrator's Procedures

If the switch is set so that the ADMIN_HIGH label is mapped, make sure that no label in the user accreditation range has the classification value of 255 with all compartment bits from 0 to 239. Otherwise, the user label would be indistinguishable from ADMIN_HIGH after mapping.

To ensure that all labels are mappable, be sure that no user label has compartments numbered above 239.

Label Encodings Procedures

To Modify the label_encodings File

Modifying the label_encodings file can safely be done at the time the host is installed. If a need arises where an operational file needs to be changed, proceed with caution. Review the caveats described in the label_encodings(4) file.

1. Assume the Security Administrator role in an ADMIN_HIGH workspace.

2. Open a new or existing version of the file.

   1. If creating a new version of the label_encodings file, use any text editor or use the Edit Encodings action to create the file.

      The Edit Encodings action both edits and runs chk_encodings(1M) on the file.

      ---

      Note -

      If creating a new file from scratch, make sure to include all the sections shown in Table 2-2 or copy and modify the example in Appendix A, Example: Label Encodings File.

      ---

      ---

      Note -

      During development of the file, chk_encodings can be entered on the command line with the -a option to analyze and report on relationships between labels in the label_encodings file.

      ---

   2. When a new version is ready to install, use the Check Encodings action to open and check the file.

      The Check Encodings action runs chk_encodings(1M) on the specified file, and if the file passes the check, the action asks whether you want to overwrite the currently-installed label_encodings file. If the answer is yes, the action creates a backup copy (naming it label_encodings.orig), and overwrites the installed version.

      ---

      Note -

      By default, both the Security Administrator and the root role have the Check Encodings action. The root role uses the action to install the label_encodings file when configuring the system after installation.

      ---

   3. If you are installing a new label_encodings, answer affirmatively when prompted.

      Do you want to install this label_encodings file?

3. On a distributed system of Trusted Solaris hosts, distribute a copy of the label_encodings file from the naming service master to the /etc/security/tsol directory on all hosts in the system.

   See "To Copy the label_encodings File to a Floppy Disk" for how to copy the file to a floppy disk for manual distribution of the modified file.

To Copy the label_encodings File to a Floppy Disk

1. Assume the Security Administrator role in an ADMIN_HIGH workspace.

2. Allocate the floppy device at ADMIN_HIGH.

   1. Highlight the name of the floppy device.

   2. Move the device to the Allocated Devices list.

   3. In the Update With field, type in ADMIN_HIGH.

   4. Click OK.

3. Double-click the File Manager icon in the Front Panel.

4. Using the File Manager, navigate to the folder that contains the label_encodings file.

   ---

   Note -

   Give another name to the version of the label_encodings file to be copied. For compatibility with the PC file systems on most floppy disks, use a name with fewer than eight characters and without a dot (.) in the name. (A string after a dot in a PC file's name is treated as the suffix that indicates the file's type, like .doc.)

   ---

5. Choose Open Floppy from the File menu.

6. Highlight the icon for the file.

7. Drag the file to the floppy disk folder.

8. On the floppy disk folder, choose Eject from the File menu.

To Copy the label_encodings File from a Floppy Disk

1. Assume the Security Administrator role in an ADMIN_HIGH workspace.

2. Allocate the floppy device at ADMIN_HIGH.

   1. Highlight the name of the floppy device.

   2. Move the device to the Allocated Devices list.

   3. In the Update With field, type in ADMIN_HIGH.

   4. Click OK.

3. Double-click the File Manager icon in the Front Panel.

4. Using the File Manager, navigate to the desired destination directory.

5. Choose Open Floppy from the File menu.

   The floppy disk folder displays.

6. Highlight the icon for the label_encodings file.

7. Drag the file from the floppy disk folder to the desired destination directory.

   If dragging the file to the /etc/security/tsol folder, make sure the file being dragged is not named label_encodings. Otherwise, by dropping the file, you will be attempting to overwrite the existing label_encodings file. Instead, copy the file onto the host, and then use the Check Encodings action to install the file, as described in "To Modify the label_encodings File".

8. On the floppy disk folder, choose Eject from the File menu.

9. Initialize the new encodings file.

   Restart the Window Manager from the Workspace Menu.

To Add Sun Extensions to a Pre-Existing Label Encodings File

1. Copy the LOCAL DEFINITIONS sections from one of the default label_encodings files in /etc/security/tsol and append the section to your site's existing file.

   See "To Modify the label_encodings File", if needed, for how to edit and check the file.

2. Modify the definitions to suit your site's security policy.

   See Chapter 4, Modifying Sun's Extensions in the Local Definitions Section for how to configure the extensions.

3. Check the file using the Check Encodings action.

4. When prompted by the Check Encodings action, install the modified version of the label_encodings file.

To Set Up No Labels Operation

The install team should do the following:

1. Change or accept the name of the single label in the label_encodings.single.

   The example uses the label PUBLIC. See "To Replace the Single Label in the Default Single-Label Encodings File".

2. When setting up user accounts, restrict the user to single-label operation.

   1. Configure the user's clearance and initial (minimum) label to equal the only encoded label.

      Clearance: PUBLIC Minimum Label: PUBLIC

   2. Configure labels to be hidden.

      Labels: Hide

To Add or Rename a Classification in the Default label_encodings File

1. In the Security Administrator role in an ADMIN_HIGH workspace, open the label_encodings file for editing.

   See "To Modify the label_encodings File", if needed.

2. In the VERSION= section put your site's name, a title for the file, a version number and the date.

   VERSION= Sun Microsystems, Inc. Example Version - 5.8 97/05/28

   Sun uses SCCS keywords for the version number and the date. (See the sccs(1) man page, if needed, for more about SCCS.)

   VERSION= Sun Microsystems, Inc. Example Version - %I% %E%

3. In the CLASSIFICATIONS section, supply the long name, short name, and numeric value for the new classification.

   name= NEW_CLASS; sname= N; value= 2;

4. Add the new classification(s) to the ACCREDITATION RANGE section.

   The following example shows the three new classifications added to the ACCREDITATION RANGE section of the demonstration file. All three (INTERNAL_USE_ONLY, NEED_TO_KNOW, and REGISTERED) are specified with all compartment combinations valid.

   ACCREDITATION RANGE: classification= UNCLASSIFIED; all compartment combinations valid; * i is new in this file classification= INTERNAL_USE_ONLY; all compartment combinations valid; * n is new in this file classification= NEED_TO_KNOW; all compartment combinations valid; classification= CONFIDENTIAL; all compartment combinations valid except: c c a c b classification= SECRET; only valid compartment combinations: . . . * r is new in this file classification= REGISTERED; all compartment combinations valid;

5. Adjust the minimums specified in the ACCREDITATION RANGE section if necessary.

   minimum clearance= u; minimum sensitivity label= u; minimum protect as classification= u;

6. If you are done, save and quit the file.

7. If you want to install the file, use the Check Encodings action and answer yes when asked if you want to install the new version of the file.

To Specify Default and Inverse Words

1. In the Security Administrator role in an ADMIN_HIGH shell, open the file for editing.

   See "To Modify the label_encodings File" if needed.

2. Specify initial compartments and/or initial markings in the CLASSIFICATIONS section when defining the classification.

   CLASSIFICATIONS: name= PUBLIC; sname= P; value= 1; name= SUN FEDERAL; sname= SUNFED; value= 2; initial compartments= 4-5 ;

3. Specify a default word by assigning an initial compartment or initial marking bit to the word.

   name= DIVISION ONLY; sname= DO; minclass= IUO; compartments= 4-5; name= SMCC AMERICA; sname= SMCCA; minclass= IUO; compartments= 4; name= SMCC WORLD; sname= SMCCW; minclass= IUO; compartments= 5;

4. Specify an inverse word by assigning an initial compartment preceded by a tilde (~) to the word.

   name= DIVISION ONLY; sname= DO; minclass= IUO; compartments= 4-5; name= SMCC AMERICA; sname= SMCCA; minclass= IUO; compartments= ~4; name= SMCC WORLD; sname= SMCCW; minclass= IUO; compartments= ~5;

To Replace the Single Label in the Default Single-Label Encodings File

1. In the Security Administrator role in an ADMIN_HIGH workspace, open the /etc/security/tsol/label_encodings.single file for editing.

   See "To Modify the label_encodings File" if needed.

2. Replace the classification name with an alternate name.

   1. Under the CLASSIFICATIONS: section, change the name SECRET to an alternate name suitable for your site.

      In the example, the name= value is changed from SECRET to INTERNAL_USE_ONLY and the sname= value is changed from s to INTERNAL. For simplicity's sake, neither the value= nor the initial compartments= definitions are changed.

      CLASSIFICATIONS: name= INTERNAL_USE_ONLY; sname= INTERNAL; value= 5; initial compartments= 4-5 190-239;

   2. Under ACCREDITATION RANGE, replace the short name of the classification (S) with the new sname.

      ACCREDITATION RANGE: classification= INTERNAL; only valid compartment combinations: INTERNAL a b rel cntry1

3. If desired, delete the compartments a b rel cntry1 from the accreditation range.

   ACCREDITATION RANGE: classification= INTERNAL; only valid compartment combinations: INTERNAL

4. If appropriate, under ACCREDITATION RANGE, replace the definitions for minimum clearance, minimum sensitivity label, and minimum protect as classification with the new sname.

   ACCREDITATION RANGE: classification= INTERNAL; only valid compartment combinations: INTERNAL minimum clearance= INTERNAL; minimum sensitivity label= INTERNAL; minimum protect as classification= INTERNAL;

To Make Your Own Single-label Encodings File

1. In the Security Administrator role in an ADMIN_HIGH workspace, open the label_encodings file for editing.

   See "To Modify the label_encodings File" if needed.

2. Create an encodings file with only one classification and only the desired compartments.

   For example, you could set up a label_encodings file with the INTERNAL_USE_ONLY classification, and specify no words.

   VERSION= Single-label Encodings . . . CLASSIFICATIONS: name= INTERNAL_USE_ONLY; sname= INTERNAL; value= 5; INFORMATION LABELS: WORDS: SENSITIVITY LABELS: WORDS: CLEARANCES: WORDS: CHANNELS: WORDS: PRINTER BANNERS: WORDS:

3. In the ACCREDITATION RANGE section, include only one classification and one valid compartment combination.

   Make the settings in the ACCREDITATION RANGE section shown in the example using your own classification, and your own compartment words, if any.

   ACCREDITATION RANGE: classification= INTERNAL; only valid compartment combinations: INTERNAL minimum clearance= INTERNAL; minimum sensitivity label= INTERNAL; minimum protect as classification= INTERNAL;

4. Encode the LOCAL DEFINITIONS section as described in Chapter 4, Modifying Sun's Extensions in the Local Definitions Section , making sure to specify Default Label View is External.

5. Configure labels not visible to users.

   See "To Configure Labels Not Visible to Users".

To Configure Labels Not Visible to Users

1. When setting up user accounts using the Trusted Solaris Attributes tab on the SMC User Accounts tool, configure users to not see labels and to have only a single label in their label ranges.

   1. Make sure the label View is set to External.

   2. Choose Show from the Labels menu.

2. Specify the account's Clearance equal to its Minimum Label.

   With a clearance and label of INTERNAL_USE_ONLY, you would (naturally) set the Clearance and the Minimum Label to INTERNAL_USE_ONLY.

To Ensure Labels Map to CIPSO Labels

See the discussion in "Cautions About Mapping Labels to CIPSO Labels".

1. Assume the Security Administrator role on the forwarding host and go to an ADMIN_LOW workspace.

   See "Administering as a Role" in Trusted Solaris Administrator's Procedures, if needed.

2. Use the Admin Editor action to open the /etc/system file for editing.

   See "Accessing the Administration Tools" under "Administering Systems in an Administrative Role" in Trusted Solaris Administrator's Procedures, if needed.

3. Add a line to set the tsol_admin_high_to_cipso flag equal to 1.

   set tsolsys:tsol_admin_high_to_cipso=1

   The default in the kernel, which is not shown in the system file, is set to 0.

4. Write and quit the file.

   :wq

5. Make sure that no label in the user accreditation range has the classification value of 255 with all compartment bits from 0 to 239.

   This step ensures that no label is indistinguishable from ADMIN_HIGH after mapping.

6. Make sure that no user label has compartments numbered above 239.

   This step ensures that all labels are mappable to CIPSO labels.