<chapter id="overview-1"><title>Labels in Trusted Extensions Software</title><highlights><itemizedlist><para>This chapter prepares the security administrator to create the file
that encodes labels for Trusted Extensions. This chapter covers the following
topics:</para><listitem><para><olink targetptr="overview-24" remap="internal">Labels and Security Policy</olink></para>
</listitem><listitem><para><olink targetptr="overview-20" remap="internal">Types of Labels, Their Components
and Uses</olink></para>
</listitem>
</itemizedlist><itemizedlist><para>This chapter assumes that you have read the following sections:</para><listitem><para><olink targetdoc="trsoladmproc" targetptr="roles-1" remap="external">Chapter 9, <citetitle remap="chapter">Getting Started as a Trusted Extensions Administrator (Tasks),</citetitle> in <citetitle remap="book">Solaris Trusted Extensions Administrator&rsquo;s Procedures</citetitle></olink> guide, which prepares
the security administrator to assume the Security Administrator role</para>
</listitem><listitem><para><olink targetdoc="trsoladmproc" targetptr="txintro-15" remap="external"><citetitle remap="section">Labels in Trusted Extensions Software</citetitle> in <citetitle remap="book">Solaris Trusted Extensions Administrator&rsquo;s Procedures</citetitle></olink></para>
</listitem>
</itemizedlist>
</highlights><sect1 id="overview-24"><title>Labels and Security Policy</title><para>Site security policy is the security policy that an organization
sets up  to protect its proprietary information. With Trusted Extensions software,
labels and mandatory access control (MAC) can be part of this policy. Labels
implement a set of rules that is a part of <emphasis>system security policy</emphasis>.
System security policy is the set of rules that is enforced by system software
to protect information that is being processed on the system. The term security
policy can refer to policy or to implementation of the policy.</para><para>All systems that are configured with Trusted Extensions have labels. Labels
are specified in a <filename>label_encodings</filename> file. For a description
of the file, see the <olink targetdoc="trsolrefman" targetptr="label-encodings-4" remap="external"><citerefentry><refentrytitle>label_encodings</refentrytitle><manvolnum>4</manvolnum></citerefentry></olink> man page. For descriptions of the encodings files
that are delivered with Solaris Trusted Extensions packages, see <olink targetptr="planl-2" remap="internal">Sources
for Encodings Files</olink>.</para><para>Trusted Extensions installs a default version of the <filename>label_encodings</filename> file.
The default version supplies several commercial labels. This version can sometimes
be used in non-production environments for learning purposes. A site can also
customize one of the label encodings files that are delivered with the Solaris Trusted Extensions packages.
For an example of a site-specific file, see <olink targetptr="appendixa-1" remap="internal">Appendix&nbsp;A,
Sample Label Encodings File</olink>.</para><para>Every computer in the Trusted Extensions network needs its own copy of the
site's <filename>label_encodings</filename> file. For interoperability, the <filename>label_encodings</filename> file on every computer in the network should be
compatible. At the very least, each computer should recognize the labels on
every other computer in the network.</para><para>Certain types of labels must be defined. The security administrator
specifies the numeric values and the bits that make up the internal representation
of labels. Users and roles see the textual representation of labels. The labeling
software translates between the internal form and the textual form of labels.
The <filename>label_encodings</filename> file provides the rules for translating
the internal representation of labels to their textual strings. The textual
strings can be visible on the desktop. The internal representation is recorded
in the audit trail and is interpreted by the <command>praudit</command> command.</para><para>The <firstterm>security administrator</firstterm> is the person who
defines and plans the implementation of an organization's security policy.
The security administrator establishes information-protection procedures,
makes sure computer users and administrators are properly trained, and monitors
compliance.</para><para>The Security Administrator <emphasis>role</emphasis> is created in the
software. The role is assigned to one or more administrators who fully understand Trusted Extensions administration.
These administrators are cleared to view and to protect the highest level
of information that is processed by Trusted Extensions. One of the responsibilities
of the security administrator is to create the site's <filename>label_encodings</filename> file
to replace the version that Sun installs. The administrator can also decide
whether labels are visible on the desktop. Even when labels are not visible,
objects and processes on the system are labeled, and MAC is enforced.</para><para>Trusted Extensions provides the Security Administrator role with the tools
and capabilities to put the organization's security policy into effect. To
assume the role, you first log in as an ordinary user, then assume the role.
At your site, the security administrator who defines the site's security policy
might or might not be the same person who implements the policy.</para>
</sect1><sect1 id="overview-20"><title>Types of Labels, Their Components and Uses</title><itemizedlist><para>Trusted Extensions defines two types of labels:</para><listitem><para>Clearance labels, or <firstterm>clearances</firstterm></para>
</listitem><listitem><para>Sensitivity labels, often referred to as <firstterm>labels</firstterm></para>
</listitem>
</itemizedlist><para>Sensitivity labels, label ranges, and a label limit or <emphasis>clearance</emphasis> determine
who can access what objects on the system. Clearance labels are assigned to
users. Sensitivity labels are assigned to processes, including users' processes,
and to files and directories.</para><itemizedlist><para>Some objects have a label range. These objects can be accessed
at a particular label within the defined label range. A label range from <constant>ADMIN_LOW</constant> to <constant>ADMIN_HIGH</constant> allows access at all
labels. The security administrator can narrow that label range. Objects with
label ranges include the following:</para><listitem><para>All hosts and networks with which communications are allowed</para>
</listitem><listitem><para>Zones</para>
</listitem><listitem><para>Users and roles</para>
</listitem><listitem><para>Allocatable devices, such as tape drives, floppy drives, CD-ROM
and DVD devices, and audio devices</para>
</listitem><listitem><para>Other devices that are not allocatable, for example, printers,
workstations (controlled through the label range of the frame buffer), and
serial lines when they are used as a login device</para>
</listitem>
</itemizedlist><para>The various means for setting labels on these objects is described in <olink targetdoc="trsoladmproc" remap="external"><citetitle remap="book">Solaris Trusted Extensions Administrator&rsquo;s Procedures</citetitle></olink>. <olink targetdoc="trsoladmproc" targetptr="managedev-50" remap="external"><citetitle remap="section">Device Allocation Manager GUI</citetitle> in <citetitle remap="book">Solaris Trusted Extensions Administrator&rsquo;s Procedures</citetitle></olink> describes
how to set label ranges on devices.</para><sect2 id="overview-19"><title>Label Ranges Restrict Access</title><itemizedlist><para>Label ranges set limits on the following:</para><listitem><para>The labels at which hosts can send and receive information.</para>
</listitem><listitem><para>The labels at which processes acting on behalf of users and
roles can access files and directories in zones.</para>
</listitem><listitem><para>The labels at which users can allocate devices, thereby restricting
the labels at which files can be written to storage media in these devices.</para>
</listitem><listitem><para>The labels at which users can send jobs to printers.</para>
</listitem><listitem><para>The labels at which users can log in to workstations. In addition
to the user's label range, a label range on the frame buffer can be used to
restrict access to a system.</para>
</listitem>
</itemizedlist><para>Labels are automatically assigned to email messages, and the labels
then show on printed emails.</para>
</sect2><sect2 id="overview-37"><title>Labels Are Used in Access Control Decisions</title><para>Labels are used to implement and control access on a computer. Labels
implement mandatory access control (MAC). With Trusted Extensions, both discretionary
access control (DAC) checks and MAC checks must pass before access is allowed
to an object. As in the Solaris OS, DAC is based on permission bits and access
control lists (ACLs). For more information, see <olink targetdoc="sysadv6" targetptr="secfile-1" remap="external">Chapter 7, <citetitle remap="chapter">Controlling Access to Files (Tasks),</citetitle> in <citetitle remap="book">System Administration Guide: Security Services</citetitle></olink>.</para><para>MAC compares the label of a process that is running an application with
the label or the label range of any object that the process tries to access.
The labels implement the set of rules that enforce policy.  One rule is read
down-read equal.. This rule applies when a process tries to access an object.
The label of the process has to be greater than or equal to the label of the
object, as in:</para><screen>Label[Process] >= Label[Object]</screen><itemizedlist><para>On a system that is configured with Trusted Extensions, files and directories
have slightly different access rules from each other and from process objects,
network endpoint objects, device objects, and X window objects. In addition,
an object can be accessed in three different ways. For each of the three ways
that an object can be accessed, a slightly different set of rules applies:</para><listitem><para>The name of the file, directory, or device can be viewed</para>
</listitem><listitem><para>The contents or the attributes of the file, directory, or
device can be viewed</para>
</listitem><listitem><para>The contents or the attributes of the file, directory, or
device can be modified</para>
</listitem>
</itemizedlist><para><olink targetptr="overview-fig-39" remap="internal">Figure&nbsp;1&ndash;1</olink> shows
a system that uses labels to make an access control decision.</para><figure id="overview-fig-39"><title>Comparing the Label of a Text Editor with
the Label of a File</title><mediaobject><imageobject><imagedata entityref="la1-2.tiff"/>
</imageobject><textobject><simpara>The context describes the graphic.</simpara>
</textobject>
</mediaobject>
</figure><para>In the preceding figure, a user brings up a text editor in a workspace
with the label <literal>INTERNAL_USE_ONLY</literal>. The system sets the label
of the process that is running the text editor to be equal to the label of
the current workspace. Therefore, the text editor displays a label of <literal>INTERNAL_USE_ONLY</literal>. When the text editor attempts to open a file for editing, the
label of the process that is running the text editor is compared to the label
of the file. When the two labels are equal, access for writing is allowed.</para><para>If the label of a file is less than the label of the text editor, the
file can be opened for reading only. For example, the <literal>INTERNAL_USE_ONLY</literal> text
editor can open and read a system file at <constant>ADMIN_LOW</constant>,
but the text file cannot be changed. Also, because of the read down requirement,
a user cannot see a file whose label is higher than the current working label.</para>
</sect2><sect2 id="overview-35"><title>Label Components</title><para>Labels and clearances consist of a single <firstterm>classification</firstterm> and
zero or more <emphasis>compartment</emphasis> words. The classification portion
of a label indicates a <emphasis>relative level of protection</emphasis>.
When a label is assigned to an object, the label's classification indicates
the sensitivity of the information that is contained in the object. When a
clearance is assigned to a user, the classification portion of the clearance
label indicates the user's level of trust.</para><para>Trusted Extensions supports Common IP Security Option (CIPSO) labels.
Each label and clearance label has a classification field that allows 256
values, and a 256-bit compartments field. You cannot use 0 (zero) for a  classification,
so you can define a total of 255 classifications. For CIPSO labels, 240 compartment
bits are available, for a total of 2<superscript>240</superscript> compartment
combinations. The components are illustrated in the following figure.</para><figure id="overview-fig-10"><title>CIPSO Label Definition</title><mediaobject><imageobject><imagedata entityref="CIPSOLabelDefs.eps"/>
</imageobject><textobject><simpara>Illustration shows the classification and compartment
sections of a label.</simpara>
</textobject>
</mediaobject>
</figure><para>The <constant>ADMIN_HIGH</constant> label and the <constant>ADMIN_LOW</constant> label
are administrative labels. These labels define the upper and lower bound of
all labels on a system.</para><para>Each compartment word has one or more compartment bits assigned. The
same compartment bit can be assigned to more than one word.</para><para>The textual format of a classification appears similar to the following:</para><screen>CLASSIFICATIONS:

name= TOP SECRET; sname= TS; value= 6;initial compartments= 4-5;</screen><para>The compartment portion of a label is optional. Compartment words in
a label can be used to represent different kinds of groupings, such as work
groups, departments, divisions, or geographical areas. Compartment words can
also further identify how information should be handled.</para><para>When initial compartments are part of the classification definition,
then compartments are part of that label.</para><screen>WORDS:

name= A;         compartments= 0;
name= B;         compartments= 1;
name= CNTRY1;     sname= c1;     compartments= ~4;
name= CNTRY2;   sname= c2;     compartments= ~5;</screen><para>Possible labels from the preceding classifications and compartments
include <literal>TS</literal>, <literal>TS A</literal>, <literal>TS B</literal>,
and <literal>TS AB</literal>. A file with <literal>TS A</literal> would be
available only to individuals who have the <literal>TS</literal> classification
and the <literal>A</literal> compartment in their clearances. For an illustration,
see <olink targetptr="overview-fig-2" remap="internal">Figure&nbsp;1&ndash;3</olink>.</para>
</sect2><sect2 id="overview-42"><title>Label Dominance</title><para>When any type of label has a security level that is equal to or greater
than the security level of a second label, the first label is said to <firstterm>dominate</firstterm> the second label. 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. Additionally, the dominant label must include all the compartments
in the second label. Two equal labels are said to dominate each other.</para><para>By these criteria, <literal>TS A</literal> dominates <literal>TS</literal>,
and <literal>TS</literal> dominates <literal>TS</literal>. The classification
and compartment bits of the  <literal>TS</literal> label are shown in the
following figure.</para><figure id="overview-fig-2"><title>Representation of the <literal>TS</literal>, <literal>TS A</literal>, <literal>TS B</literal>, and <literal>TS AB</literal> Labels</title><mediaobject><imageobject><imagedata entityref="TS.AB.Label.eps"/>
</imageobject><textobject><simpara>Illustration shows the classification and compartment
sections of the TS labels.</simpara>
</textobject>
</mediaobject>
</figure><para>Another kind of dominance, <firstterm>strict dominance</firstterm>,
is sometimes required for access. One label <firstterm>strictly dominates</firstterm> another
label when the first label has a security level that is greater than the security
level of the other label. Strict dominance is dominance without equality.
The classification of the first label is higher than the classification  of
the second label. The first label contains all the compartments in the second
label. Or, if the classifications of both labels are the same, the first label
contains all the compartments in the second label plus one or more additional
compartments.</para><para>Labels that are not in a dominance relationship are said to be <firstterm>disjoint</firstterm>. Disjoint labels would be appropriate to separate departments
at a company. For example, the label <literal>TS HR</literal> (Human Resources)
would be disjoint from <literal>TS Sales</literal>.</para>
</sect2><sect2 id="overview-284"><title>Accreditation Ranges, Label Ranges, and Valid
Labels</title><para>Certain combinations of label components can be disqualified by
rules in the <filename>label_encodings</filename> file. Combination rules <emphasis>implicitly</emphasis> define the organization's usable labels. The security
administrator is responsible for specifying combination rules.</para><itemizedlist><para>A <firstterm>valid</firstterm> or <firstterm>well-formed</firstterm> label
is a label that satisfies a combination rule. The security administrator defines
combination rules by using one of the following means:</para><listitem><para><firstterm>Initial compartments</firstterm> (compartment bits)
can be assigned to a classification.</para><para>Initial compartment bits
are always associated with the classification in a label. For more details,
see <olink targetptr="modifyenc-28" remap="internal">Classification Name Syntax</olink>.</para>
</listitem><listitem><para>A <firstterm>minimum classification</firstterm>, an <firstterm>output
minimum classification</firstterm>, and a <firstterm>maximum classification</firstterm> can
be associated with any word.</para>
</listitem><listitem><para><firstterm>Hierarchies</firstterm> among words can be defined
by the <emphasis>bit patterns</emphasis> that are chosen for each word.</para>
</listitem><listitem><para><firstterm>Required combinations</firstterm> of words can
be specified.</para>
</listitem><listitem><para><firstterm>Combination constraints</firstterm> can be specified
for words.</para>
</listitem><listitem><para>A <firstterm>minimum clearance</firstterm> and a <firstterm>minimum
sensitivity label</firstterm> must be specified.</para><para>These system-wide
minimums establish the lowest clearance and the lowest label that any ordinary
user can have.</para>
</listitem>
</itemizedlist><itemizedlist><para>Two <firstterm>accreditation ranges</firstterm> are implicitly
specified in the <filename>label_encodings</filename> file:</para><listitem><para><olink targetptr="overview-285" remap="internal">System Accreditation Range</olink></para>
</listitem><listitem><para><olink targetptr="overview-286" remap="internal">User Accreditation Range</olink></para>
</listitem>
</itemizedlist><para>The term <emphasis>accreditation range</emphasis> is also 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 might not include all the potential
combinations of label components in a range.</para>
</sect2><sect2 id="overview-285"><title>System Accreditation Range</title><para>The system accreditation range includes the administrative labels <constant>ADMIN_HIGH</constant> and <constant>ADMIN_LOW</constant>. The system accreditation
range also includes all the well-formed labels that are constructed from the
label components in the <filename>label_encodings</filename> file.</para><para>Administrative role accounts are usually the only accounts that can
work at every label within the system accreditation range. An organization
can also set up ordinary user accounts to be able to perform a task that requires
an administrative label.</para><para>The following figure presents an example of how rules can constrain
the labels permitted in a system accreditation range.</para><figure id="overview-fig-12"><title>How System Accreditation Range Is Constrained
By Rules</title><mediaobject><imageobject><imagedata entityref="ao1-1.eps"/>
</imageobject><textobject><simpara>Illustration shows that the number of potential combinations
of classifications is greater than the number permitted by the rules.</simpara>
</textobject>
</mediaobject>
</figure><para><olink targetptr="overview-fig-12" remap="internal">Figure&nbsp;1&ndash;4</olink> (a) shows
all potential combinations given the classifications, <literal>TS</literal> (<literal>TOP SECRET</literal>), <literal>S</literal> (<literal>SECRET</literal>), and <literal>C</literal> (<literal>CONFIDENTIAL</literal>), and the compartments, <literal>A</literal> and <literal>B</literal>.</para><para><olink targetptr="overview-fig-12" remap="internal">Figure&nbsp;1&ndash;4</olink> (b) shows
a typical rule from the <literal>REQUIRED COMBINATIONS</literal> subsection
of the <literal>SENSITIVITY LABELS</literal> section and its effects. The
arrows point to the labels that are disqualified by the rule. Disqualified
labels appear with lines through the labels. The <literal>REQUIRED COMBINATIONS</literal> syntax <literal>B A</literal> means that any label that has <literal>B</literal> as a compartment
must also contain <literal>A</literal>. The converse is not true. Compartment
A is not required to be combined with any other compartments. Since compartment <literal>B</literal> is only permitted when <literal>A</literal> is also present, the
labels <literal>TS B</literal>, <literal>S B</literal>, and <literal>C B</literal> are
not well-formed. Labels that are not well-formed are not in the system accreditation
range.</para>
</sect2><sect2 id="overview-286"><title>User Accreditation Range</title><para>The <firstterm>user accreditation range</firstterm> is the largest set
of labels that ordinary users can access when using Trusted Extensions. The user
accreditation range always excludes <constant>ADMIN_HIGH</constant> and <constant>ADMIN_LOW</constant>. The user accreditation range is further constrained
by any rules that constrain the <olink targetptr="overview-285" remap="internal">System Accreditation
Range</olink>. In addition, the user accreditation range can be constrained
by a set of rules in the <literal>ACCREDITATION RANGE</literal> section. <olink targetptr="overview-fig-14" remap="internal">Figure&nbsp;1&ndash;5</olink> continues the <olink targetptr="overview-fig-12" remap="internal">Figure&nbsp;1&ndash;4</olink> example. <olink targetptr="overview-fig-14" remap="internal">Figure&nbsp;1&ndash;5</olink> shows three different
types of rules in the <literal>ACCREDITATION RANGE</literal> section and their
effects on the user accreditation range. The arrows point to the well-formed
labels that the particular rule permits.</para><figure id="overview-fig-14"><title><literal>ACCREDITATION RANGE</literal> Portion
of <filename>label_encodings</filename> File</title><mediaobject><imageobject><imagedata entityref="ao1-2.eps" width="100"/>
</imageobject><textobject><simpara>The context describes the graphic.</simpara>
</textobject>
</mediaobject>
</figure><para>As shown in the box to the right, the user accreditation range
excludes <constant>ADMIN_HIGH</constant> and <constant>ADMIN_LOW</constant>.
The rule for the <literal>TS</literal> classification includes all <literal>TS</literal> combinations
except <literal>TS B</literal>. However, because <literal>TS B</literal>,
and <literal>S B</literal> and <literal>C B</literal>, were previously overruled
by the <literal>REQUIRED COMBINATIONS</literal> rule <literal>B A</literal>,
as shown in <olink targetptr="overview-fig-12" remap="internal">Figure&nbsp;1&ndash;4</olink>, <literal>TS A B</literal>, <literal>TS A</literal>, and <literal>TS</literal> are the
only allowed <literal>TS</literal> combinations. Because <literal>S A B</literal> is
defined as the only valid combination for the <literal>S</literal> classification, <literal>S B</literal> is excluded again. All <literal>C</literal> combinations except <literal>C A</literal> are valid according the rule for the <literal>C</literal> classification.
However, because <literal>C B</literal> was overruled earlier, the only permitted
combinations for the <literal>C</literal> classification are <literal>C A
B</literal> and <literal>C</literal>.</para>
</sect2><sect2 id="overview-25"><title>Account Label Range</title><para>The <emphasis>account label range</emphasis> is the range of labels
that is  available to an individual user or to a role account. This range
governs the labels at which the user can work when logging in to the system. </para><itemizedlist><para>The labels that are available in the account label range have the following
constraints:</para><listitem><para>The user clearance defines the top of the account label range.</para><para>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.</para>
</listitem><listitem><para>The minimum label sets the bottom of the account label range.</para><para>The minimum sensitivity label in the <filename>label_encodings</filename> file
defines an absolute minimum on labels at which any user can work.</para>
</listitem><listitem><para>The user accreditation range defines the set of valid labels
from the user's clearance to the user's minimum label.</para>
</listitem>
</itemizedlist><example id="overview-30"><title>Defining a Valid Clearance That Is Not a
Valid Label</title><para>For example, a <filename>label_encodings</filename> file could prohibit
the combination of compartments <literal>A</literal>, <literal>B</literal>,
and <literal>C</literal> in a label.</para><itemizedlist><listitem><para>The minimum label would be <literal>TS</literal> with no compartments.</para>
</listitem><listitem><para><literal>TS A B C</literal> would be a valid clearance. <literal>TS A B C</literal> would not be a valid label.</para>
</listitem><listitem><para>Valid labels for a user would be <literal>TS</literal>, <literal>TS A</literal>, <literal>TS B</literal>, and <literal>TS C</literal>.</para>
</listitem>
</itemizedlist>
</example>
</sect2><sect2 id="overview-287"><title>Account Label Range Examples</title><para>The possible clearances and minimum labels that can be assigned
to an account are shown in the following figure. These labels are based on
the accreditation examples from the previous sections.</para><figure id="overview-fig-26"><title>Constraints on Account Label Ranges</title><mediaobject><imageobject><imagedata entityref="ao1-3.eps"/>
</imageobject><textobject><simpara>The context describes the graphic.</simpara>
</textobject>
</mediaobject>
</figure><para>In this example, <literal>TS A B</literal> is the highest label
in the user accreditation range. This label contains the only two compartments, <literal>A</literal> and <literal>B</literal>, that are permitted to appear together
in a label with any classification. The account range that is illustrated
on the left is bounded at the top by <literal>TS A B</literal>. <literal>TS
A B</literal> is the clearance assigned to the account. <literal>C</literal> is
the account's minimum label. These definitions constrain the account to work
at labels <literal>TS A B</literal>, <literal>TS A</literal>, <literal>TS</literal>, <literal>S A B</literal>, <literal>C A B</literal>, or <literal>C</literal>. The permitted
clearances are <literal>TS A B</literal>, <literal>TS A</literal>, <literal>TS</literal> and <literal>S A B</literal>. A minimum clearance of <literal>S A B</literal> is set in
the <filename>label_encodings</filename> file.</para><para>Even if <literal>TS A B</literal> was not a valid label, the security
administrator could assign the label as a clearance. The assignment would
allow the account to use any valid labels that are dominated by <literal>TS</literal> and
that contain the words <literal>A</literal> and <literal>B</literal>. In contrast,
if <literal>TS</literal> was assigned as the account clearance, the user could
work at the labels <literal>TS</literal> and <literal>C</literal> only. <literal>TS</literal> without any compartments does not dominate <literal>S A B</literal> or <literal>C A B</literal>.</para><table frame="topbot" pgwide="1" id="overview-tbl-294"><title>Accreditation
Range and Account Label Range Examples</title><tgroup cols="6" colsep="0" rowsep="0"><colspec colname="column1" colwidth="67.71*"/><colspec colname="column2" colwidth="63.86*"/><colspec colname="column3" colwidth="54.86*"/><colspec colname="column4" colwidth="81.34*"/><colspec colname="column5" colwidth="59.95*"/><colspec colname="colspec0" colwidth="161.48*"/><thead><row><entry colname="column1" colsep="1" rowsep="1"><para></para>
</entry><entry namest="column2" nameend="column3" colsep="1" rowsep="1"><para>Accreditation Range</para>
</entry><entry namest="column4" nameend="colspec0" colsep="1" rowsep="1"><para>Account Label Range</para>
</entry>
</row><row rowsep="1"><entry colsep="1" align="left" valign="bottom"><para>Possible Labels</para>
</entry><entry colsep="0" rowsep="1" align="left" valign="bottom"><para>System</para>
</entry><entry colsep="1" rowsep="1" align="left" valign="bottom"><para>User</para>
</entry><entry align="left" valign="bottom"><para><literal>TS&nbsp;A&nbsp;B</literal> Clearance, <literal>S&nbsp;A&nbsp;B</literal>&nbsp;Min
Label</para>
</entry><entry align="left" valign="bottom"><para><literal>TS</literal> Clearance, <literal>C</literal>&nbsp;Min Label</para>
</entry><entry colname="colspec0"><para><constant>ADMIN_LOW</constant> Clearance and Min Label, <constant>solaris.label.range</constant> Authorization</para>
</entry>
</row>
</thead><tbody><row><entry colsep="1" align="left" valign="top"><para><constant>ADMIN_HIGH</constant></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><constant>ADMIN_HIGH</constant></para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para> </para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>TS A B</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><literal>TS A B</literal></para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para> </para>
</entry><entry align="left" valign="top"><para><literal>TS A B</literal></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>TS A</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><literal>TS A</literal></para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para><literal>TS A</literal></para>
</entry><entry align="left" valign="top"><para><literal>TS A</literal></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>TS</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><literal>TS</literal></para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para><literal>TS</literal></para>
</entry><entry align="left" valign="top"><para><literal>TS</literal></para>
</entry><entry align="left" valign="top"><para><literal>TS</literal></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>S A B</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><literal>S A B</literal></para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para><literal>S A B</literal></para>
</entry><entry align="left" valign="top"><para><literal>S A B</literal></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>S A</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para> </para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>S</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para> </para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para><literal>S</literal></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>C A B</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><literal>C A B</literal></para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>C A</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><literal>C A</literal></para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para> </para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><literal>C</literal></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><literal>C</literal></para>
</entry><entry colsep="1" rowsep="0" align="left" valign="top"><para><literal>C</literal></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para><literal>C</literal></para>
</entry><entry colname="colspec0"><para></para>
</entry>
</row><row><entry colsep="1" align="left" valign="top"><para><constant>ADMIN_LOW</constant></para>
</entry><entry colsep="0" rowsep="0" align="left" valign="top"><para><constant>ADMIN_LOW</constant></para>
</entry><entry colsep="1" rowsep="1" align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry align="left" valign="top"><para></para>
</entry><entry colname="colspec0"><para><constant>ADMIN_LOW</constant></para>
</entry>
</row>
</tbody>
</tgroup>
</table><itemizedlist><para><olink targetptr="overview-tbl-294" remap="internal">Table&nbsp;1&ndash;1</olink> illustrates
the differences between the potential label combinations, the system accreditation
range, the user accreditation range, and some sample account label ranges.</para><listitem><para>Ordinary users without any authorizations can work only with
the labels in the User Accreditation Range column.</para>
</listitem><listitem><para>The fourth column shows the Account Label Range for a user
with a clearance of <literal>TS A B</literal> and a minimum label of <literal>S
A B</literal>. This range allows the user to work with the labels <literal>TS
A B</literal>, <literal>TS A</literal>, <literal>TS</literal>, and <literal>S
A B</literal>.</para>
</listitem><listitem><para>The fifth column of <olink targetptr="overview-tbl-294" remap="internal">Table&nbsp;1&ndash;1</olink> shows an account with a clearance of <literal>TS</literal> and
a minimum label of <literal>C</literal>. This account would be allowed to
work only with <literal>TS</literal>, <literal>S</literal>, and <literal>C</literal> labels,
because all the other valid labels that are dominated by <literal>TS</literal> include
the words <literal>A</literal> and <literal>B</literal>. <literal>A</literal> and <literal>B</literal> are not in the clearance.</para>
</listitem><listitem><para>A sixth column shows a user who is authorized to work outside
the user accreditation range. This user is assigned a single label of <constant>ADMIN_LOW</constant>.</para>
</listitem>
</itemizedlist>
</sect2><sect2 id="overview-28"><title>Session Range</title><itemizedlist><para>The <emphasis>session range</emphasis> is the set of labels that is
available to a user account during a Trusted Extensions session. The session range
is a function of the following constraints:</para><listitem><para>The label range of the user</para>
</listitem><listitem><para>The label that the user chose</para>
</listitem><listitem><para>The label range of the local system</para>
</listitem>
</itemizedlist><para>The session range of a single-label account is the label of the account.
A range of labels to choose from is possible only when a user account is configured
to use multiple labels. User accounts that are configured to use multiple
labels can choose different labels during the session. To specify a label,
see <olink targetdoc="trssug" targetptr="shared-commontasks-39" remap="external"><citetitle remap="section">How to Change the Label of a Workspace</citetitle> in <citetitle remap="book">Solaris Trusted Extensions User&rsquo;s Guide</citetitle></olink>.</para><para>The single label or session clearance that is chosen at login
is in effect throughout the session until logout. During a multilabel session,
the user can work at any valid label that is dominated by the session clearance
and that dominates the user's minimum label.</para><para>Example <olink targetptr="overview-fig-26" remap="internal">Figure&nbsp;1&ndash;6</olink> is
continued in <olink targetptr="overview-fig-29" remap="internal">Figure&nbsp;1&ndash;7</olink>.
In this example, the user can specify a session clearance that uses any well-formed
label between <literal>TS A B</literal> and <literal>S A B</literal>.</para><para>The (a) portion of <olink targetptr="overview-fig-29" remap="internal">Figure&nbsp;1&ndash;7</olink> shows
the labels that are available if the user selects a multilabel session with
a session clearance of <literal>S A B</literal>. Because the other intermediate
labels between S A B and C are not well-formed, the user can only work at <literal>S A B</literal>, <literal>C A B</literal>, or <literal>C</literal>.</para><para>The (b) portion of <olink targetptr="overview-fig-29" remap="internal">Figure&nbsp;1&ndash;7</olink> shows
the labels that are available if the user selects a single-label session with
a session label of <literal>C A B</literal>. Note that <literal>C A B</literal> is
below the minimum clearance. However, <literal>C A B</literal> is accessible
because the user is selecting a session label, not a clearance. Because the
session is single-label, the user can work at only one label. In this example,
the user specified <literal>C A B</literal>, although <literal>S A B</literal> or <literal>C</literal> could have been chosen instead.</para><figure id="overview-fig-29"><title>Comparison of Session Ranges</title><mediaobject><imageobject><imagedata entityref="ao1-4.eps"/>
</imageobject><textobject><simpara>The context describes the graphic.</simpara>
</textobject>
</mediaobject>
</figure><para>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. The filtered out labels are
not shown in subsequent ranges.</para><figure id="overview-fig-31"><title>Cumulative Effect of Constraints on a
Session Range</title><mediaobject><imageobject><imagedata entityref="ao1-5.eps" width="100"/>
</imageobject><textobject><simpara>The context describes the graphic.</simpara>
</textobject>
</mediaobject>
</figure>
</sect2><sect2 id="overview-33"><title>Label Availability in Trusted Extensions Sessions</title><para>The following table shows session label limitations and availability
based on users' session choices. The table continues the example from <olink targetptr="overview-fig-31" remap="internal">Figure&nbsp;1&ndash;8</olink>.</para><table frame="topbot" pgwide="1" id="overview-tbl-34"><title>Labels in Trusted Extensions Sessions</title><tgroup cols="5" colsep="0" rowsep="0"><colspec colnum="1" colname="column1" colwidth="2*"/><colspec colnum="2" colname="column2" colwidth="3*"/><colspec colnum="3" colname="column3" colwidth="3*"/><colspec colnum="4" colname="column4" colwidth="3*"/><colspec colnum="5" colname="column5" colwidth="3*"/><thead><row rowsep="1"><entry colname="column1" align="left" valign="bottom"><para></para>
</entry><entry colname="column2" namest="column2" nameend="column3" align="center" valign="bottom"><para>Multilevel Session</para>
</entry><entry colname="column4" namest="column4" nameend="column5" align="center" valign="bottom"><para>Single-level Session</para>
</entry>
</row><row><entry rowsep="1" align="left"><para></para>
</entry><entry rowsep="1" align="left"><para> General Case</para>
</entry><entry rowsep="1" align="left"><para>Example #1</para>
</entry><entry rowsep="1" align="left"><para> General Case</para>
</entry><entry rowsep="1" align="left"><para>Example #2</para>
</entry>
</row><row rowsep="1"><entry colname="column1" align="left" valign="bottom"><para></para>
</entry><entry colname="column2" align="left" valign="bottom"><para></para>
</entry><entry colname="column3" align="left" valign="bottom"><para>Multilevel with clearance of <literal>SECRET A B</literal></para>
</entry><entry colname="column4" align="left" valign="bottom"><para></para>
</entry><entry colname="column5" align="left" valign="bottom"><para>Single-level with session label of <literal>SECRET A B</literal></para>
</entry>
</row>
</thead><tbody><row><entry colname="column1" align="left" valign="top"><para>Initial Workspace Label (at first login)</para>
</entry><entry colname="column2" align="left" valign="top"><para> Lowest label in account label range.</para>
</entry><entry colname="column3" align="left" valign="top"><para><literal>CONFIDENTIAL</literal></para>
</entry><entry colname="column4" align="left" valign="top"><para>Session label is specified by user</para>
</entry><entry colname="column5" align="left" valign="top"><para><literal>SECRET A B</literal></para>
</entry>
</row><row><entry colname="column1" align="left" valign="top"><para>Available Workspace Labels</para>
</entry><entry colname="column2" align="left" valign="top"><para> Any label in account label range up to the session clearance</para>
</entry><entry colname="column3" align="left" valign="top"><para><literal>CONFIDENTIAL</literal></para><para><literal>CONFIDENTIAL A B</literal></para><para><literal>SECRET A B</literal></para>
</entry><entry colname="column4" align="left" valign="top"><para>Session label is specified by user</para>
</entry><entry colname="column5" align="left" valign="top"><para><literal>SECRET A B</literal></para>
</entry>
</row>
</tbody>
</tgroup>
</table><itemizedlist><listitem><para>The left column identifies the types of label settings that
are used in sessions.</para>
</listitem><listitem><para>The middle two columns apply to a <literal>Multilevel Session</literal>.</para>
</listitem><listitem><para>The right two columns apply to a <literal>Single-level Session</literal>.</para>
</listitem><listitem><para>The columns that are labeled <literal>General Case</literal> describe
how the label types are determined.</para>
</listitem><listitem><para>The columns marked <literal>Example</literal> show a typical
user's session selections at login.</para>
</listitem>
</itemizedlist><para>In Example #1, the initial workspace label is set to <literal>CONFIDENTIAL</literal>,
which is the label at the bottom of the user's account label range. The user
can work at a label of <literal>CONFIDENTIAL</literal>, <literal>CONFIDENTIAL
A B</literal>, or <literal>SECRET A B</literal>.</para><para>In Example #2, the user's initial workspace label is <literal>SECRET
A B</literal>. Since the session is single-level, the only available workspace
label is <literal>SECRET A B</literal>.</para>
</sect2><sect2 id="overview-218"><title>Labeled Workspaces</title><para>Labeled <emphasis>workspaces</emphasis> enable users to work at multiple
labels during a single session.</para><para>If the user selects a range of labels for the session, the first workspace
that comes up is at the user's <firstterm>minimum label</firstterm>. In CDE,
buttons for three additional workspaces are created at the same minimum label
in the workspace switch portion of the Front Panel.</para><figure id="overview-fig-1"><title>Workspace Switch Area</title><mediaobject><imageobject><imagedata entityref="WorkspaceSwitchArea.eps"/>
</imageobject><textobject><simpara>The window shows the Workspace menu, the Trusted Path
menu, and the Workspace Switch area on the Front Panel.</simpara>
</textobject>
</mediaobject>
</figure><para>For details on working in a labeled system, see <olink targetdoc="trssug" remap="external"><citetitle remap="book">Solaris Trusted Extensions User&rsquo;s Guide</citetitle></olink>.</para>
</sect2>
</sect1><sect1 id="overview-50"><title>Administering Labels</title><para>Several aspects about how labels appear to users can be configured.
Label visibility, label color, and labels on printed output can be configured.
Some actions on labels require authorization or privilege. Upgrading or downgrading
an object's label requires an authorization. Manipulating a label between
its internal and its textual representation can require a privilege.</para><sect2 id="overview-268"><title>Label Visibility</title><para>As described in <olink targetptr="overview-218" remap="internal">Labeled Workspaces</olink>,
labels appear on windows on the desktop. On a single-label system, you might
not want labels to be visible. Label visibility is configurable in the <filename>policy.conf</filename> file for a system, and in the Solaris Management Console for individual
users. For a pointer to the configuration procedures, 
see <olink targetptr="modifyenc-30" remap="internal">Managing Label Encodings (Task Map)</olink>.</para><para>Typically, the content of files at a lower label can be read by a user
at a higher label. For example, system files and commonly-available executables
are assigned an <constant>ADMIN_LOW</constant> label. According to the read
down-read equal rule, accounts who work at any label can read <constant>ADMIN_LOW</constant> files. As in the Solaris OS, DAC permissions can prevent read access.
Zones also protect files from being read. If a lower-level zone is not mounted,
a user in a higher-level zone cannot access the files for reading.</para><para>Files that contain data that should not be viewed by ordinary users,
such as system log files and the <filename>label_encodings</filename> files,
are maintained at <constant>ADMIN_HIGH</constant>. To allow administrators
access to protected system files, the <constant>ADMIN_LOW</constant> and <constant>ADMIN_HIGH</constant> administrative labels are assigned as the minimum label
and clearance for roles.</para>
</sect2><sect2 id="overview-337"><title>Labels on Printed Output</title><para>The labels that are printed on banner, trailer and body pages of print
jobs can be customized. Also, accompanying text that appears on the banner
and trailer pages can be customized. For more information, see <olink targetptr="printl-1" remap="internal">Chapter&nbsp;4, Labeling Printer Output (Tasks)</olink>.</para>
</sect2><sect2 id="overview-21"><title>Authorizations for Relabeling Information</title><para>The authorization to upgrade information to a label that dominates the
label of the current information is called the <literal>Upgrade File Label</literal> authorization.
The authorization to downgrade information to a label that is lower than the
the label of the current information is called the <literal>Downgrade File
Label</literal> authorization. For definitions for these authorizations, see <filename>/etc/security/auth_attr</filename>.</para>
</sect2><sect2 id="gcrth"><title>Privileges for Translating Labels</title><para>Label translation occurs whenever programs manipulate labels. Labels
are translated to and from the textual strings to the internal representation.
For example, when a program such as <command>getlabel</command> gets the label
of a file, before the label can display to the user, the internal representation
of the label is translated into readable output. When the <command>setlabel</command> program
sets a label specified on the command line, the textual string, that is, the
label's name, is translated into the label's internal representation. Trusted Extensions permits
label translations only if the calling process's label dominates the label
that is to be translated. If a process attempts to translate a label that
the process's label does not dominate, the translation is disallowed. The <constant>sys_trans_label</constant> privilege is required to override this restriction.</para>
</sect2>
</sect1>
</chapter>