<?Pub UDT _bookmark _target?><?Pub EntList bsol dash hellip gt lt minus?><?Pub CX solbook(book(title()bookinfo()?><chapter id="api-intro-1"><title>Solaris Trusted Extensions APIs and Security Policy</title><highlights><para>The <trademark>Solaris</trademark> Trusted Extensions software (Trusted Extensions) provides application programming interfaces (APIs) that enable you to write applications that access and handle labels. This chapter summarizes the API functionality and introduces you to the Trusted Extensions security policy.</para><para>For Trusted Extensions term definitions, see the glossary in the <olink targetdoc="trssug" remap="external"><citetitle remap="book">Solaris Trusted Extensions User&rsquo;s Guide</citetitle></olink>.</para><para>For examples of how the Trusted Extensions APIs are used in the Solaris Operating System (Solaris OS), see the Solaris source code. Go to the <ulink url="http://opensolaris.org/" type="text_url">Open Solaris web site</ulink> and click Source Browser in the left navigation bar. Use the Source Browser to search through the Solaris source code.</para><itemizedlist><para>This chapter covers the following topics:</para><listitem><para><olink targetptr="txlabelintro" remap="internal">Understanding Labels</olink></para>
</listitem><listitem><para><olink targetptr="api-intro-15" remap="internal">Trusted Extensions APIs</olink></para>
</listitem><listitem><para><olink targetptr="txsecuritypolicy" remap="internal">Trusted Extensions Security Policy</olink></para>
</listitem>
</itemizedlist>
</highlights><sect1 id="txlabelintro"><title>Understanding Labels</title><para>The Solaris Trusted Extensions software provides a set of policies and services to extend the security features of the Solaris OS. These <emphasis>extensions</emphasis> provide access control that is based on label relationships.</para><para><indexterm><primary>Trusted Extensions APIs</primary><secondary>Solaris examples</secondary></indexterm><indexterm><primary>APIs</primary><secondary>examples of Trusted Extensions in Solaris</secondary></indexterm><indexterm><primary>Solaris</primary><secondary>examples of Trusted Extensions APIs</secondary></indexterm><indexterm><primary>examples of Trusted Extensions APIs in Solaris</primary></indexterm><indexterm><primary>security policy</primary><secondary>definition of</secondary></indexterm><indexterm><primary>terms</primary><secondary>definitions of</secondary></indexterm><indexterm><primary>definitions of terms</primary></indexterm>Labels control access to data and maintain the classification of data. The labels are attributes that are interpreted by the system security policy. The <firstterm>system security policy</firstterm> is the set of rules that is enforced by system software to protect information that is being processed on the system. The term <firstterm>security policy</firstterm> can refer to the policy itself or to the implementation of the policy. For more information, see <olink targetptr="txsecuritypolicy" remap="internal">Trusted Extensions Security Policy</olink>.</para><para>This section includes overview information about label types, ranges, components, and relationships.</para><sect2 id="labelsrangeslimits"><title>Label Types</title><para>The Trusted Extensions software defines two types of labels: sensitivity labels and clearance labels. A <firstterm>sensitivity label</firstterm> indicates the security level of an entity and is usually referred to as a <firstterm>label</firstterm>. A <firstterm>clearance label</firstterm> defines the upper boundary of a label range and is usually referred to as a <firstterm>clearance</firstterm>.</para><sect3 id="sensitivitylabels"><title>Sensitivity Labels</title><para><indexterm><primary>sensitivity labels</primary></indexterm><indexterm><primary>labels</primary><secondary>types</secondary><tertiary>sensitivity</tertiary></indexterm><indexterm><primary>sensitivity labels</primary></indexterm><indexterm><primary>APIs</primary><secondary>introduction to</secondary></indexterm><indexterm><primary>label APIs</primary><secondary>introduction to</secondary></indexterm><indexterm><primary>compartments</primary><secondary>label component</secondary></indexterm><indexterm><primary>classifications</primary><secondary>label component</secondary></indexterm><indexterm><primary>labels</primary><secondary>components of</secondary></indexterm>The Trusted Extensions software uses zones to contain classified information at various levels. Each level is associated with its own zone that has a sensitivity label. The sensitivity label specifies the sensitivity of the information in that zone and is applied to all of the subjects and objects in that zone. A label might be something like <constant>CONFIDENTIAL</constant>, <constant>SECRET</constant>, or <constant>TOP SECRET</constant>. A <firstterm>subject</firstterm> is an active entity, such as a process, that causes information to flow among objects or changes a system's state. An <firstterm>object</firstterm> is a passive entity that contains or receives data, such as a file or device. All processes that run in a zone, all files that are contained in a zone, and so on, have the same sensitivity label as their zone. All processes and objects have a sensitivity label that is used in mandatory access control (MAC) decisions. By default, sensitivity labels are visible in the windowing system.</para>
</sect3><sect3 id="clearancelabels"><title>Clearance Labels</title><para><indexterm><primary>labels</primary><secondary>types</secondary><tertiary>clearance</tertiary></indexterm><indexterm><primary>clearance labels</primary></indexterm><indexterm><primary>clearances</primary><secondary>session</secondary></indexterm><indexterm><primary>clearances</primary><secondary>user</secondary></indexterm><indexterm><primary>compartments</primary><secondary>clearance component</secondary></indexterm><indexterm><primary>classifications</primary><secondary>clearance component</secondary></indexterm>The security administrator assigns a clearance to each user. A clearance is a label that defines the upper boundary of a label range. For example, if you have a clearance of <constant>SECRET</constant>, you can access information that is classified at this level or lower, but not information that is classified at a higher level. A <firstterm>user clearance</firstterm> is assigned by the security administrator. It is the highest label at which a user can access files and initiate processes during a session. In other words, a user clearance is the upper boundary of a user's account label range. At login, a user selects his session clearance. The <firstterm>session clearance</firstterm> determines which labels a user can access. The session clearance sets the <firstterm>least upper bound</firstterm> at which the user can access files and initiate processes during that login session. The session clearance is dominated by the user clearance.</para>
</sect3>
</sect2><sect2 id="labelranges"><title>Label Ranges</title><indexterm><primary>label ranges</primary>
</indexterm><para>The security administrator defines label ranges and label sets to enforce <firstterm>mandatory access control</firstterm> (MAC) policy. A <firstterm>label range</firstterm> is a set of labels that is bounded at the upper end by a clearance or a limit and at the lower end by a minimum label. A <firstterm>label limit</firstterm> is the upper bound of a label range. A <firstterm>label set</firstterm> contains one or more discrete labels that might be disjoint from one another. Labels in a label set do not dominate one another.</para>
</sect2><sect2 id="api-intro-40"><title>Label Components</title><para>A label contains a hierarchical classification and a set of zero or more nonhierarchical compartments. A classification is also referred to as a <firstterm>level</firstterm> or a security level. A <firstterm>classification</firstterm> represents a single level within a hierarchy of labels, for example, <constant>TOP SECRET</constant> or <constant>UNCLASSIFIED</constant>. A <firstterm>compartment</firstterm> is associated with a classification and represents a distinct, nonhierarchical area of information in a system, such as private information for a human resources (HR) group or a sales group. A compartment limits access only to users who need to know the information in a particular area. For example, a user with a <constant>SECRET</constant> classification only has access to the secret information that is specified by the associated list of compartments, not to any other secret information. The classification and compartments together represent the label of the zone and the resources within that zone.</para><para>The textual format of a classification is specified in the <filename>label_encodings</filename> file and appears similar to this:</para><screen>CLASSIFICATIONS:
name= CONFIDENTIAL; sname= C; value= 4; initial compartments= 4-5 190-239;
name= REGISTERED; sname= REG; value= 6; initial compartments= 4-5 190-239;</screen><para>The textual format of a compartment is specified in the <filename>label_encodings</filename> file and appears similar to this:</para><screen>WORDS:
name= HR; minclass= C; compartments= 0;</screen><para>For more information about label definitions and label formats, see <olink targetdoc="trsollbladmin" remap="external"><citetitle remap="book">Solaris Trusted Extensions Label Administration</citetitle></olink> and <olink targetdoc="wslblencode" remap="external"><citetitle remap="book">Compartmented Mode Workstation Labeling: Encodings Format</citetitle></olink>. For information about the label APIs, see <olink targetptr="labelapi-1" remap="internal">Chapter&nbsp;2, Labels and Clearances</olink>.</para>
</sect2><sect2 id="labelrelationships"><title>Label Relationships</title><para>Comparing labels means that the label of a process is compared to the label of a target, which might be a sensitivity label or a clearance label. Based on the result of the comparison, the process is either granted access or denied access to the object. Access is granted only when the label of the process dominates the label of the target. Label relationships and dominance are described later in this section. For examples, see <olink targetptr="labelcode-8" remap="internal">Determining the Relationship Between Two Labels</olink>.</para><para><indexterm><primary>relationships between labels</primary></indexterm><indexterm><primary>labels</primary><secondary>relationships</secondary></indexterm><indexterm><primary>labels</primary><secondary>definition of</secondary></indexterm><indexterm><primary>process clearances</primary><secondary>labels defined</secondary></indexterm>A <firstterm>security level</firstterm> is a numerical classification. A label indicates the security level of an entity and might include zero or more compartments. An entity is something that can be labeled, such as a process, zone, file, or device.</para><itemizedlist><para>Labels are of the following types and relate to each other in these ways:</para><listitem><itemizedlist><para><indexterm><primary>clearances</primary><secondary>equal labels</secondary></indexterm><indexterm><primary>equal labels</primary></indexterm><indexterm><primary>compartments</primary><secondary>equal</secondary></indexterm><indexterm><primary>classifications</primary><secondary>equal</secondary></indexterm><emphasis role="strong">Equal &ndash;</emphasis> When one label is equal to another label, both of these statements are true:</para><listitem><para>The label's classification is numerically <emphasis>equal to</emphasis> the other label's classification.</para>
</listitem><listitem><para>The label has exactly the same compartments as the other label.</para>
</listitem>
</itemizedlist>
</listitem><listitem><itemizedlist><para><indexterm><primary>clearances</primary><secondary>dominant labels</secondary></indexterm><indexterm><primary>dominant labels</primary></indexterm><indexterm><primary>compartments</primary><secondary>dominant</secondary></indexterm><indexterm><primary>classifications</primary><secondary>dominant</secondary></indexterm><emphasis role="strong">Dominant &ndash;</emphasis> When one label dominates another label, both of these statements are true:</para><listitem><para>The label's classification is numerically <emphasis>greater than or equal to</emphasis> the other label's classification.</para>
</listitem><listitem><para>The label has exactly the same compartments as the other label.</para>
</listitem>
</itemizedlist>
</listitem><listitem><itemizedlist><para><indexterm><primary>clearances</primary><secondary>strictly dominant labels</secondary></indexterm><indexterm><primary>strictly dominant labels</primary></indexterm><indexterm><primary>compartments</primary><secondary>strictly dominant</secondary></indexterm><indexterm><primary>classifications</primary><secondary>strictly dominant</secondary></indexterm><emphasis role="strong">Strictly dominant &ndash;</emphasis> When one label strictly dominates another label, both of these statements are true:</para><listitem><para>The label's classification is numerically <emphasis>greater than or equal to</emphasis> the other label's classification.</para>
</listitem><listitem><para>The label has all the compartments that the other label has and at least one other compartment.</para>
</listitem>
</itemizedlist>
</listitem><listitem><itemizedlist><para><indexterm><primary>clearances</primary><secondary>disjoint labels</secondary></indexterm><indexterm><primary>disjoint labels</primary></indexterm><indexterm><primary>compartments</primary><secondary>disjoint</secondary></indexterm><indexterm><primary>classifications</primary><secondary>disjoint</secondary></indexterm><emphasis role="strong">Disjoint &ndash;</emphasis> When one label is disjoint with another label, both of these statements are true:</para><listitem><para>The labels are not equal.</para>
</listitem><listitem><para>Neither label dominates the other label.</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist><para>The <filename>label_encodings</filename> file is used to specify the classifications and compartments for labels. See the <olink targetdoc="refman" targetptr="label-encodings-4" remap="external"><citerefentry><refentrytitle>label_encodings</refentrytitle><manvolnum>4</manvolnum></citerefentry></olink> man page.</para><para><indexterm><primary>labels</primary><secondary>dominant</secondary></indexterm><indexterm><primary>dominant labels</primary></indexterm>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 greater 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>In the following sample excerpt of the <filename>label_encodings</filename> file, the <constant>REGISTERED</constant> (<constant>REG</constant>) label dominates the <constant>CONFIDENTIAL</constant> (<constant>C</constant>) label. The comparison is based on the value of each label's <literal>value</literal> keyword. The value of the <constant>REG</constant> label's <literal>value</literal> keyword is numerically greater than or equal to the value of the <constant>C</constant> label's <literal>value</literal> keyword. Both labels dominate the <constant>PUBLIC</constant> (<constant>P</constant>) label.</para><para>The value of the <literal>initial compartments</literal> keyword shows the list of compartments that are initially associated with the classification. Each number in the <literal>initial compartments</literal> keyword is a <firstterm>compartment bit</firstterm>, each of which represents a particular compartment.</para><programlisting>CLASSIFICATIONS:
name= PUBLIC; sname= P; value= 1;
name= CONFIDENTIAL; sname= C; value= 4; initial compartments= 4-5 190-239;
name= REGISTERED; sname= REG; value= 6; initial compartments= 4-5 190-239;</programlisting><para>The following <filename>label_encodings</filename> excerpt shows that the <constant>REG HR</constant> label (Human Resources) dominates the <constant>REG</constant> label. The <constant>REG HR</constant> label has the <constant>REGISTERED</constant> classification and the <constant>HR</constant> compartment. The <literal>compartments</literal> keyword for the <constant>HR</constant> compartment sets the <literal>0</literal> compartment bit, so the <constant>REG HR</constant> classification has compartments <literal>0</literal>, <literal>4&ndash;5</literal>, and <literal>190&ndash;239</literal> set, which is more than the compartments set by the <constant>REG</constant> classification.</para><programlisting>CLASSIFICATIONS:
name= REGISTERED; sname= REG; value= 6; initial compartments= 4-5 190-239;
...
WORDS:
name= HR; minclass= C; compartments= 0;</programlisting><para><indexterm><primary>labels</primary><secondary>strictly dominant</secondary></indexterm>Sometimes, strict dominance is required to access an object. In the previous examples, the <constant>REG</constant> label strictly dominates the <constant>P</constant> label, and the <constant>REG HR</constant> label strictly dominates the <constant>REG</constant> label. When comparing labels, a <constant>REG</constant> label dominates another <constant>REG</constant> label.</para><para><indexterm><primary>labels</primary><secondary>disjoint</secondary></indexterm>Labels that do not dominate each other are said to be disjoint. A <firstterm>disjoint</firstterm> label might be used to separate departments in a company. In the following example, the <constant>REG HR</constant> label (Human Resources) is defined as being disjoint from the <constant>REG Sales</constant> label. These labels are disjoint because each compartment sets a different compartment bit.</para><screen>CLASSIFICATIONS:
name= REGISTERED; sname= REG; value= 6; initial compartments= 4-5 190-239;
...
WORDS:
name= HR; minclass= C; compartments= 0;
name= Sales; minclass= C; compartments= 1;</screen><para>For information about label APIs, see <olink targetptr="api-intro-25" remap="internal">Sensitivity Label APIs</olink>.</para>
</sect2>
</sect1><sect1 id="api-intro-15"><title>Trusted Extensions APIs</title><itemizedlist><para>This section introduces the three Trusted Extensions APIs that are described in this book:</para><listitem><para>Label APIs</para>
</listitem><listitem><para>Trusted X Window System APIs</para>
</listitem><listitem><para>Label Builder APIs</para>
</listitem>
</itemizedlist><para><indexterm><primary>X Window System</primary><see>Trusted X Window System</see></indexterm><indexterm><primary>APIs</primary><secondary>security APIs from Solaris OS</secondary></indexterm>In addition to these Trusted Extensions APIs, you can use the security APIs that are available with the Solaris OS. An application that runs on Trusted Extensions might require the manipulation of other security attributes. For example, the user and profile databases contain information about users, roles, authorizations, and profiles. These databases can restrict who can run a program. Privileges are coded into various Solaris programs and can also be coded into third-party applications.</para><para>For more information about these Solaris OS security APIs, see <citetitle remap="chapter">Developing Privileged Applications,</citetitle> in <citetitle remap="book">Solaris Security for Developers Guide</citetitle>.</para><para>The Solaris OS provides <firstterm>discretionary access control</firstterm> (DAC), in which the owner of the data determines who is permitted access to the data. The Trusted Extensions software provides additional access control, which is called mandatory access control (MAC). In MAC, ordinary users cannot specify or override the <firstterm>security policy</firstterm>. The security administrator sets the security policy.</para><para>Applications use Trusted Extensions APIs to obtain labels for hosts, zones, users, and roles. Where the security policy permits, the APIs enable you to set labels on user processes or on role processes. Setting a label on a zone or on a host is an administrative procedure, not a programmatic procedure.</para><para>You can write applications to customize window labels. The Trusted Extensions software provides Motif based programming interfaces for adding a basic label-building user interface to an application. The label-building interface enables a user to interactively build valid sensitivity labels and valid clearances.</para><para>The label APIs operate on opaque labels. In an <firstterm>opaque label</firstterm>, the internal structure of the label is not exposed. Using an opaque label enables existing programs that are created with the APIs to function even if the internal structure of the label changes. For example, you cannot use the label APIs to locate particular bits in a label. The label APIs enable you to obtain labels and to set labels. You can only set labels if you are permitted to do so by the security policy.</para><sect2 id="api-intro-2"><title>Label APIs</title><para>Labels, label ranges, and a label limit determine who can access information on a system that is configured with Trusted Extensions.</para><para>The label APIs are used to access, convert, and perform comparisons for labels, label ranges and limits, and the relationship between labels. A label can dominate another label, or a label can be disjoint from another label.</para><para>The <filename>label_encodings</filename> file defines the sensitivity labels, clearance labels, label ranges, and label relationships that pertain to your Trusted Extensions environment. This file also controls the appearance of labels. The security administrator is responsible for creating and maintaining the <filename>label_encodings</filename> file. See the <olink targetdoc="refman" targetptr="label-encodings-4" remap="external"><citerefentry><refentrytitle>label_encodings</refentrytitle><manvolnum>4</manvolnum></citerefentry></olink> man page.</para><para>The label of a process is determined by the zone in which the process executes.</para><itemizedlist><para><indexterm><primary>label ranges</primary><secondary>overview</secondary></indexterm>All objects are associated with a label or sometimes with a label range. An object can be accessed at a particular label within the defined label range. The objects that are associated with a label range include the following:</para><listitem><para>All users and all roles</para>
</listitem><listitem><para>All hosts with which communications are permitted</para>
</listitem><listitem><para>Zone interfaces and network interfaces</para>
</listitem><listitem><para>Allocatable devices, such as tape drives, diskette drives, CD-ROM devices, and audio devices</para>
</listitem><listitem><para>Other devices that are not allocatable, such as printers and workstations</para><para>Workstation access is controlled by the label range that is set for the frame buffer or video display device. The security administrator sets this range by using the Device Manager GUI. By default, devices have a range from <constant>ADMIN_LOW</constant> to <constant>ADMIN_HIGH</constant>.</para>
</listitem>
</itemizedlist><para>For more information about labels, see <olink targetptr="labelsrangeslimits" remap="internal">Label Types</olink>.</para><sect3 id="api-intro-44"><title>How Labels Are Used in Access Control Decisions</title><para>MAC compares the label of the process that is running an application with the label or the label range of any object that the process tries to access. MAC permits a process to read down to a lower label and permits a process to write to an equal label.</para><screen>Label[Process] &gt;= Label[Object]</screen><para>A process bound to a multilevel port (MLP) can listen for requests at multiple labels and send replies to the originator of the request. In Trusted Extensions, such replies are write-equal.</para><screen>Label[Process] = Label[Object]</screen>
</sect3><sect3 id="api-intro-251"><title>Types of Label APIs</title><sect4 id="api-intro-25"><title>Sensitivity Label APIs</title><indexterm><primary>APIs</primary><secondary>sensitivity label</secondary>
</indexterm><itemizedlist><para>Sensitivity label APIs can be used to do the following:</para><listitem><para>Obtain a process label</para>
</listitem><listitem><para>Initialize labels</para>
</listitem><listitem><para>Find the greatest lower bound or the least upper bound between two labels</para>
</listitem><listitem><para>Compare labels for dominance and equality</para>
</listitem><listitem><para>Check and set label types</para>
</listitem><listitem><para>Convert labels to a readable format</para>
</listitem><listitem><para>Obtain information from the <filename>label_encodings</filename> file</para>
</listitem><listitem><para>Check that a sensitivity label is valid and within the system range</para>
</listitem>
</itemizedlist><para>For a description of these APIs, see <olink targetptr="labelapi-1" remap="internal">Chapter&nbsp;2, Labels and Clearances</olink>.</para>
</sect4><sect4 id="api-intro-21"><title>Clearance Label APIs</title><indexterm><primary>APIs</primary><secondary>clearance label</secondary>
</indexterm><para>Users, devices, and network interfaces have label ranges. The upper bound of the range is effectively the clearance. If the upper bound of the range and the lower bound of the range are equal, the range is a single label.</para><itemizedlist><para>Clearance label APIs can be used to do the following:</para><listitem><para>Find the greatest lower bound or the least upper bound between two labels</para>
</listitem><listitem><para>Compare labels for dominance and equality</para>
</listitem><listitem><para>Convert clearances between the internal format and the hexadecimal format</para>
</listitem>
</itemizedlist><para>For a description of these APIs, see <olink targetptr="labelapi-1" remap="internal">Chapter&nbsp;2, Labels and Clearances</olink>.</para>
</sect4><sect4 id="api-intro-43"><title>Label Range APIs</title><indexterm><primary>APIs</primary><secondary>label range</secondary>
</indexterm><indexterm><primary>labels</primary><secondary>ranges</secondary>
</indexterm><itemizedlist><para>A label range is used to 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 work on the system</para>
</listitem><listitem><para>The labels at which users can allocate devices</para><para>This use of a label range restricts the labels at which files can be written to storage media on these devices.</para>
</listitem>
</itemizedlist><para>Label ranges are assigned administratively. Label ranges can apply to users, roles, hosts, zones, network interfaces, printers, and other objects.</para><itemizedlist><para>You can use the following methods to obtain information about label ranges:</para><listitem><para><function>getuserrange</function> obtains the user's label range.</para>
</listitem><listitem><para><function>getdevicerange</function> obtains the label range of a device.</para>
</listitem><listitem><para><command>tninfo -t</command> <replaceable>template-name</replaceable> shows the label range of a template that is associated with a network interface.</para>
</listitem>
</itemizedlist><para>For a description of these APIs, see <olink targetptr="labelapi-1" remap="internal">Chapter&nbsp;2, Labels and Clearances</olink>.</para>
</sect4>
</sect3>
</sect2><sect2 id="api-intro-22"><title>Trusted X Window System APIs</title><indexterm><primary>APIs</primary><secondary>Trusted X Window System</secondary>
</indexterm><indexterm><primary>label APIs</primary><secondary>windows</secondary>
</indexterm><indexterm><primary>Trusted X Window System</primary><secondary>description of</secondary>
</indexterm><para>The Trusted X Window System, Version 11, server starts at login. The server handles the workstation windowing system by using a trusted interprocess communication (IPC) path. Windows, properties, selections, and <trademark>ToolTalk</trademark> sessions are created at multiple sensitivity labels as separate and distinct objects. The creation of distinct objects at multiple sensitivity labels is called <firstterm>polyinstantiation</firstterm>. Applications that are created with Motif widgets, Xt Intrinsics, Xlib, and desktop interfaces run within the constraints of the security policy. These constraints are enforced by extensions to the X11 protocols.</para><para><olink targetptr="windowapi-1" remap="internal">Chapter&nbsp;6, Trusted X Window System</olink> describes the programming interfaces that can access the security attribute information described in <olink targetptr="txsecuritypolicy" remap="internal">Trusted Extensions Security Policy</olink>. These programming interfaces can also be used to translate the labels and clearances to text. The text can be constrained by a specified width and font list for display in the Trusted X Window System.</para><para><indexterm><primary>security attributes</primary><secondary>Trusted X Window System</secondary><tertiary>contrast with Solaris</tertiary></indexterm><indexterm><primary>Trusted X Window System</primary><secondary>security attributes</secondary><tertiary>contrast with Solaris</tertiary></indexterm>The Trusted X Window System stores the following security attributes:</para><simplelist columns="2"><member>Audit ID</member><member>Group ID</member><member>Internet address</member><member>Process ID</member><member>Sensitivity label</member><member>Session ID</member><member>Trusted Path flag</member><member>Trusted Path window</member><member>User ID</member><member>X Window Server owner ID</member><member>X Window Server clearance</member><member>X Window Server minimum label</member>
</simplelist><para><indexterm><primary>Trusted Path window</primary><secondary>definition of</secondary></indexterm><indexterm><primary>Trusted X Window System</primary><secondary>Trusted Path window</secondary></indexterm>The Trusted Path flag identifies a  window as a Trusted Path window. The Trusted Path window protects the system from being accessed by untrusted programs. This window is always the topmost window, such as the screen stripe or login window.</para><para><olink targetptr="appb-1" remap="internal">Appendix&nbsp;B, Solaris Trusted Extensions API Reference</olink> lists the extensions that you can use to create an X11 trusted IPC path.</para>
</sect2><sect2 id="api-intro-18"><title>Label Builder APIs</title><indexterm><primary>label APIs</primary><secondary>windows</secondary>
</indexterm><indexterm><primary>Label Builder</primary><secondary>description of</secondary>
</indexterm><para>The Trusted Extensions software provides a label builder API that enables you to create a graphical user interface (GUI) for your application. The GUI takes user input and builds a valid label from that input.</para><para>A system that is configured with Solaris Trusted Extensions provides Motif based programming interfaces for adding a basic label-building user interface to an application. The label-building interface enables a user to interactively build valid sensitivity labels and valid clearances. For information about these programming interfaces, see <olink targetptr="lbuilder-1" remap="internal">Chapter&nbsp;7, Label Builder APIs</olink>.</para>
</sect2>
</sect1><sect1 id="txsecuritypolicy"><title>Trusted Extensions Security Policy</title><para>Sensitivity labels control access to data and maintain the classification of data. All processes and objects have a sensitivity label that is used in MAC decisions. The labels are attributes that are interpreted by the system security policy. The <firstterm>system security policy</firstterm> is the set of rules that is enforced by system software to protect information being processed on the system.</para><para>The following sections describe how the Trusted Extensions security policy affects multilevel operations, zones, and labels.</para><sect2 id="api-intro-7"><title>Multilevel Operations</title><indexterm><primary>multilevel operations</primary><secondary>security policy for</secondary>
</indexterm><indexterm><primary>security policy</primary><secondary>multilevel operations</secondary>
</indexterm><indexterm><primary>global zone</primary><secondary>controlling multilevel operations</secondary>
</indexterm><indexterm><primary>processes</primary><secondary>multilevel initiated in global zone</secondary>
</indexterm><itemizedlist><para>When you create an operation that runs at multiple security levels, you must consider the following issues:</para><listitem><para>Write-down policy in the global zone</para>
</listitem><listitem><para>Default security attributes</para>
</listitem><listitem><para>Default network policy</para>
</listitem><listitem><para>Multilevel ports</para>
</listitem><listitem><para>MAC-exempt sockets</para>
</listitem>
</itemizedlist><para>Operations that run at multiple security levels are controlled by the global zone because only processes in the global zone can initiate processes at specified labels.</para><sect3 id="api-intro-12"><title>Write-Down Policy in the Global Zone</title><indexterm><primary>security policy</primary><secondary>write-down in global zone</secondary>
</indexterm><indexterm><primary>global zone</primary><secondary>mounts in</secondary>
</indexterm><indexterm><primary>zones</primary><secondary>mounts and the global zone</secondary>
</indexterm><indexterm><primary>processes</primary><secondary>writing down from global zone</secondary>
</indexterm><indexterm><primary><constant>file_dac_search</constant> privilege</primary><secondary>overriding access to parent directory of zone's root directory</secondary>
</indexterm><indexterm><primary>privileges</primary><secondary><constant>file_dac_search</constant></secondary>
</indexterm><para>The ability of a subject, such as a process, to write an object whose label it dominates is referred to as <firstterm>writing down</firstterm>. The write-down policy in the global zone is specified administratively. Because global zone processes run at the <constant>ADMIN_HIGH</constant> label, certain file systems that are associated with other labels can be mounted read-write in the global zone. However, these special file system mounts must be administratively specified in automount maps, and they must be mounted by the global zone automounter. These mounts must have mount points within the zone path of the zone that has the same label as the exported file system. However, these mount points must not be visible from within the labeled zone.</para><para>For example, if the <constant>PUBLIC</constant> zone has a zone path of <filename>/zone/public</filename>, a writable mount point of <filename>/zone/public/home/mydir</filename> is permitted. However, a writable mount point of <filename>/zone/public/root/home/mydir</filename> is not permitted because it can be accessed by the labeled zone and <emphasis>not</emphasis> by the global zone. No cross-zone NFS mounts are permitted, which means that the NFS-mounted files can only be accessed by processes that run in the zone that mounted the file system. Global zone processes can write down to such files, subject to the standard discretionary access control (DAC) policy.</para><para>Local file systems associated with zones are protected from access by global zone processes by DAC, which uses file <firstterm>permissions</firstterm> and access control lists (ACLs). The parent directory of each zone's root (<filename>/</filename>) directory is only accessible by <literal>root</literal> processes or by processes that assert the <constant>file_dac_search</constant> privilege.</para><para>In general, the ability to write down from the global zone is restricted. Typically, writing down is used only when a file is reclassified by using the <function>setflabel</function> interface or when privileged users drag and drop files between File Manager applications in different zones.</para>
</sect3><sect3 id="gbeun"><title>Default Security Attributes</title><para>Default security attributes are assigned to messages that arrive on Trusted Extensions hosts from other <firstterm>host types</firstterm>. The attributes are assigned according to settings in the network database files. For information about host types, their supported security attributes, and network database file defaults, see <olink targetdoc="trsoladmproc" remap="external"><citetitle remap="book">Solaris Trusted Extensions Administrator&rsquo;s Procedures</citetitle></olink>.</para>
</sect3><sect3 id="api-intro-8"><title>Default Network Policy</title><indexterm><primary>security policy</primary><secondary>network</secondary>
</indexterm><indexterm><primary>network security policy</primary><secondary>default</secondary>
</indexterm><para>For network operations that send or receive data, the default policy is that the local process and the remote peer must have the same label. This policy applies to all zones, including the global zone, whose network label is <constant>ADMIN_LOW</constant>. However, the default network policy is more flexible than the policy for mounting file systems. Trusted Extensions provides administrative interfaces and programmatic interfaces for overriding the default network policy. For example, a system administrator can create an MLP in the global zone or in a labeled zone to enable listening at different labels.</para>
</sect3><sect3 id="api-intro-9"><title>Multilevel Ports</title><indexterm><primary>multilevel ports</primary><secondary>description of</secondary>
</indexterm><indexterm><primary>zones</primary><secondary>multilevel ports</secondary>
</indexterm><indexterm><primary>processes</primary><secondary>binding to multilevel ports</secondary>
</indexterm><indexterm><primary><literal>SO_RECVUCRED</literal> option</primary>
</indexterm><caution><para>Use extreme caution when using a multilevel port to violate MAC policy. When you must use this mechanism, ensure that your server application enforces MAC policy.</para>
</caution><para><indexterm><primary>privileges</primary><secondary><constant>net_bindmlp</constant></secondary></indexterm>Multilevel ports (MLPs) are listed in the <filename>tnzonecfg</filename> administrative database. Processes within the zone can bind to MLPs if these processes assert the <constant>net_bindmlp</constant> privilege. If the port number is less than 1024, the <constant>net_privaddr</constant> privilege must also be asserted. Such bindings allow a process to accept connections at all labels that are associated with the IP addresses to which the process is bound. The labels that are associated with a network interface are specified in the <filename>tnrhdb</filename> database and the <filename>tnrhtp</filename> database. The labels can be specified by a range, by a set of explicit enumerated labels, or by a combination of both.</para><para>When a privileged process that is bound to an MLP receives a TCP request, the reply is automatically sent with the label of the requester. For UDP datagrams, the reply is sent with the label that is specified by the <literal>SO_RECVUCRED</literal> option.</para><para><indexterm><primary>networks</primary><secondary>security attributes</secondary></indexterm><indexterm><primary>security attributes</primary><secondary>labels from remote hosts</secondary></indexterm>The privileged process can implement a more restrictive MAC policy by comparing the label of the request to other parameters. For example, a web server could compare the label of the requesting process with the label of the file specified in the URL. The remote label can be determined by using the <function>getpeerucred</function> function, which returns the credentials of the remote peer. If the peer is running in a zone on the same host, the <function>ucred_get</function> library routine returns a full set of credentials. Regardless of whether the peer is local or remote, the label of the peer is accessible from the <literal>ucred</literal> data structure by using the <function>ucred_getlabel</function> function. This label can be compared with other labels by using functions such as <function>bldominates</function>.</para><para>A zone can have single-level ports and multilevel ports. See <olink targetptr="ipcapi-19" remap="internal">Multilevel Port Information</olink>.</para>
</sect3><sect3 id="api-intro-11"><title>MAC-Exempt Sockets</title><indexterm><primary>sockets</primary><secondary>exempt from MAC</secondary>
</indexterm><indexterm><primary>MAC (mandatory access control)</primary><secondary>making socket exempt from</secondary>
</indexterm><indexterm><primary><literal>SO_MAC_EXEMPT</literal> option</primary>
</indexterm><indexterm><primary><constant>net_mac_aware</constant> privilege</primary>
</indexterm><indexterm><primary>privileges</primary><secondary><constant>net_mac_aware</constant></secondary>
</indexterm><indexterm><primary><function>setpflags</function> system call</primary>
</indexterm><para>The Trusted Extensions software provides an explicit socket option, <literal>SO_MAC_EXEMPT</literal>, to specify that the socket can be used to communicate with an endpoint at a lower label.</para><caution><para>The <literal>SO_MAC_EXEMPT</literal> socket option must <emphasis>never</emphasis> be used unintentionally. Use extreme caution when using this socket option to disable MAC policy. When you must use this mechanism, ensure that your client application enforces MAC policy.</para>
</caution><itemizedlist><para>The Trusted Extensions software restricts the use of the <literal>SO_MAC_EXEMPT</literal> option in these ways:</para><listitem><para>To explicitly set the socket option, a process must assert the <constant>net_mac_aware</constant> privilege.</para>
</listitem><listitem><para>To further restrict the use of this socket option, the <constant>net_mac_aware</constant> privilege can be removed from the limit set for ordinary users.</para>
</listitem>
</itemizedlist><para>See the <olink targetdoc="refman" targetptr="user-attr-4" remap="external"><citerefentry><refentrytitle>user_attr</refentrytitle><manvolnum>4</manvolnum></citerefentry></olink> man page for details.</para><para><indexterm><primary>privileges</primary><secondary><constant>net_mac_aware</constant></secondary></indexterm>Sometimes, explicitly setting the socket option is not practical, such as when the socket is managed by a library. In such circumstances, the socket option can be set implicitly. The <function>setpflags</function> system call enables you to set the <literal>NET_MAC_AWARE</literal> process flag. Setting this process flag also requires the <constant>net_mac_aware</constant> privilege. All sockets that are opened while the process flag is enabled automatically have the <literal>SO_MAC_EXEMPT</literal> socket option set. See the <olink targetdoc="refman" targetptr="setpflags-2" remap="external"><citerefentry><refentrytitle>setpflags</refentrytitle><manvolnum>2</manvolnum></citerefentry></olink> and <olink targetdoc="refman" targetptr="getpflags-2" remap="external"><citerefentry><refentrytitle>getpflags</refentrytitle><manvolnum>2</manvolnum></citerefentry></olink> man pages.</para><para>For applications that cannot be modified or recompiled, use the <command>ppriv -M</command> command to pass the <constant>net_mac_aware</constant> process flag to the application. In this case, all sockets that are opened by the application have the <literal>SO_MAC_EXEMPT</literal> option set. However, child processes of the application do not have this process flag or the related privilege.</para><para>Whenever you can, scrutinize and modify the source code of an application when you need to use the <literal>SO_MAC_EXEMPT</literal> socket option. If you <emphasis>cannot</emphasis> make such modifications to the code or if a safer method is not available to you, you may use the <command>ppriv -M</command> command.</para><para>The <literal>SO_MAC_EXEMPT</literal> socket option has been used sparingly by the Solaris OS. This option has been used by the NFS client. An NFS client might need to communicate with an NFS server that runs at a different label on an untrusted operating system. The NFS client enforces MAC policy to ensure that inappropriate requests are not granted.</para><para>In the Solaris OS, both the NFS server and client code include and enforce MAC policy so that communications between the Solaris client or server and an untrusted client or server has MAC policy enabled. To enable an untrusted host to communicate with a system that runs Trusted Extensions, the untrusted host must have an entry in the <filename>tnrhdb</filename> database. For more information, see <olink targetdoc="trsoladmproc" targetptr="managetnet-3" remap="external"><citetitle remap="section">Configuring Trusted Network Databases (Task Map)</citetitle> in <citetitle remap="book">Solaris Trusted Extensions Administrator&rsquo;s Procedures</citetitle></olink>.</para><note><para>For examples of how the Trusted Extensions APIs are used in the Solaris OS, see the Solaris source code. Go to the <ulink url="http://opensolaris.org/" type="text_url">Open Solaris web site</ulink> and click Source Browser in the left navigation bar. Use the Source Browser to search through the Solaris source code.</para>
</note>
</sect3>
</sect2><sect2 id="api-intro-4"><title>Zones and Labels</title><indexterm><primary>zones</primary><secondary sortas="Trusted Extensions">in Trusted Extensions</secondary>
</indexterm><indexterm><primary>zones</primary><secondary>labeled</secondary>
</indexterm><para>All objects on a system configured with Trusted Extensions are associated with a zone. Such zones are called <firstterm>labeled zones</firstterm>. A labeled zone is a non-global zone and is accessible to ordinary users. A user who is cleared at more than one label is permitted access to a zone at each of those labels.</para><para>The <firstterm>global zone</firstterm> is a special zone that contains files and processes that control the security policy of the system. Files in the global zone can only be accessed by roles and by privileged processes.</para><sect3 id="api-intro-10"><title>Labels in the Global Zone</title><indexterm><primary>security policy</primary><secondary>global zone</secondary>
</indexterm><indexterm><primary>labels</primary><secondary sortas="global">in global zone</secondary>
</indexterm><indexterm><primary>global zone</primary><secondary>labels in</secondary>
</indexterm><indexterm><primary><constant>ADMIN_LOW</constant> label</primary>
</indexterm><indexterm><primary><constant>ADMIN_HIGH</constant> label</primary>
</indexterm><indexterm><primary>labels</primary><secondary><constant>ADMIN_HIGH</constant></secondary>
</indexterm><indexterm><primary>labels</primary><secondary><constant>ADMIN_LOW</constant></secondary>
</indexterm><para>The global zone is assigned a range of labels. The range is from <constant>ADMIN_LOW</constant> to <constant>ADMIN_HIGH</constant>. <constant>ADMIN_HIGH</constant> and <constant>ADMIN_LOW</constant> are <firstterm>administrative labels</firstterm>.</para><para>Objects in the global zone that are shared with other zones are assigned the <constant>ADMIN_LOW</constant> label. For example, files in the <filename class="directory">/usr</filename>, <filename class="directory">/sbin</filename>, and <filename class="directory">/lib</filename> directories are assigned the <constant>ADMIN_LOW</constant> label. These directories and their contents are shared by all zones. These files and directories are typically installed from packages and are generally not modified, except during packaging or patching procedures. To modify <constant>ADMIN_LOW</constant> files, a process must typically be run by superuser or by someone who has all privileges.</para><para>Information that is private to the global zone is assigned the label <constant>ADMIN_HIGH</constant>. For example, all processes in the global zone and all administrative files in the <filename class="directory">/etc</filename> directory are assigned the <constant>ADMIN_HIGH</constant> label. Home directories that are associated with roles are assigned the <constant>ADMIN_HIGH</constant> label. Multilevel information that is associated with users is also assigned the <constant>ADMIN_HIGH</constant> label. See <olink targetptr="api-intro-7" remap="internal">Multilevel Operations</olink>. Access to the global zone is restricted. Only system services and administrative roles can execute processes in the global zone.</para>
</sect3><sect3 id="api-intro-3"><title>Labeled Zones</title><indexterm><primary>non-global zones</primary>
</indexterm><indexterm><primary>labeled zones</primary>
</indexterm><indexterm><primary>processes</primary><secondary>in labeled zones</secondary>
</indexterm><para>Non-global zones are called <firstterm>labeled zones</firstterm>. Each labeled zone has a unique label. All objects within a labeled zone have the same label. For example, all processes that run in a labeled zone have the same label. All files that are writable in a labeled zone have the same label. A user who is cleared for more than one label has access to a labeled zone at each label.</para><itemizedlist><para><indexterm><primary>APIs</primary><secondary sortas="zone">for zone labels and zone paths</secondary></indexterm><indexterm><primary>label APIs</primary><secondary sortas="zone">for zone labels and zone paths</secondary></indexterm><indexterm><primary>zones</primary><secondary>APIs for zone labels and zone paths</secondary></indexterm>Trusted Extensions defines a set of label APIs for zones. These APIs obtain the labels that are associated with labeled zones and the path names within those zones:</para><listitem><para><function>getpathbylabel</function></para>
</listitem><listitem><para><function>getzoneidbylabel</function></para>
</listitem><listitem><para><function>getzonelabelbyid</function></para>
</listitem><listitem><para><function>getzonelabelbyname</function></para>
</listitem><listitem><para><function>getzonerootbyid</function></para>
</listitem><listitem><para><function>getzonerootbylabel</function></para>
</listitem><listitem><para><function>getzonerootbyname</function></para>
</listitem>
</itemizedlist><para>For more information about these APIs, see <olink targetptr="accessinglabelsinzones" remap="internal">Accessing Labels in Zones</olink>.</para><para><indexterm><primary>privileges</primary><secondary><constant>file_upgrade_sl</constant></secondary></indexterm><indexterm><primary>privileges</primary><secondary><constant>file_downgrade_sl</constant></secondary></indexterm>The label of a file is based on the label of the zone or of the host that owns the file. Therefore, when you relabel a file, the file must be moved to the appropriate labeled zone or to the appropriate labeled host. This process of relabeling a file is also referred to as <firstterm>reclassifying</firstterm> a file. The <function>setflabel</function> library routine can relabel a file by moving the file. To relabel a file, a process must assert the <constant>file_upgrade_sl</constant> privilege or the <constant>file_downgrade_sl</constant> privilege. See the <olink targetdoc="refman" targetptr="getlabel-2" remap="external"><citerefentry><refentrytitle>getlabel</refentrytitle><manvolnum>2</manvolnum></citerefentry></olink> and <olink targetdoc="refman" targetptr="setflabel-3tsol" remap="external"><citerefentry><refentrytitle>setflabel</refentrytitle><manvolnum>3TSOL</manvolnum></citerefentry></olink> man pages.</para><para>For more information about setting privileges, see <citetitle remap="chapter">Developing Privileged Applications,</citetitle> in <citetitle remap="book">Solaris Security for Developers Guide</citetitle>.</para>
</sect3>
</sect2>
</sect1>
</chapter>