<?Pub UDT _bookmark _target?><chapter id="ovw-1"><?Pub Tag atict:info tracking="off" ref="0"?><?Pub Tag atict:user
user="sharonr" fullname="Sharon Veach"?><title>Security Planning for Trusted Extensions</title><indexterm><primary>actions</primary><see>administrative actions</see>
</indexterm><indexterm><primary>planning</primary><seealso>Trusted Extensions use</seealso>
</indexterm><indexterm><primary>network</primary><see>Trusted Extensions network</see>
</indexterm><indexterm><primary>Trusted Extensions</primary><seealso>Trusted Extensions planning</seealso>
</indexterm><highlights><itemizedlist><para><trademark>Solaris</trademark> Trusted Extensions implements a portion of your site's security policy in software.
This chapter provides an overview of the security and administrative aspects
of configuring the software.</para><listitem><para><olink targetptr="ovw-36" remap="internal">Planning for Security in Trusted
Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-41" remap="internal">Results of Enabling Trusted Extensions
From an Administrator's Perspective</olink></para>
</listitem>
</itemizedlist>
</highlights><sect1 id="ovw-36"><title>Planning for Security in Trusted Extensions</title><indexterm><primary>Trusted Extensions</primary><secondary>planning for</secondary>
</indexterm><indexterm><primary>planning</primary><secondary>Trusted Extensions</secondary>
</indexterm><para>This section outlines the planning that is required before enabling
and configuring Trusted Extensions software.</para><itemizedlist><listitem><para><olink targetptr="ovw-13" remap="internal">Understanding Trusted Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-14" remap="internal">Understanding Your Site's Security
Policy</olink></para>
</listitem><listitem><para><olink targetptr="ovw-15" remap="internal">Devising an Administration Strategy
for Trusted Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-16" remap="internal">Devising a Label Strategy</olink></para>
</listitem><listitem><para><olink targetptr="ovw-20" remap="internal">Planning System Hardware and Capacity
for Trusted Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-22" remap="internal">Planning Your Trusted Network</olink></para>
</listitem><listitem><para><olink targetptr="ovw-11" remap="internal">Planning for Zones in Trusted Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-12" remap="internal">Planning for Multilevel Access</olink></para>
</listitem><listitem><para><olink targetptr="ovw-25" remap="internal">Planning for the LDAP Naming Service
in Trusted Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-26" remap="internal">Planning for Auditing in Trusted
Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-18" remap="internal">Planning User Security in Trusted
Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-27" remap="internal">Devising a Configuration Strategy
for Trusted Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-28" remap="internal">Collecting Information Before Enabling&nbsp;Trusted
Extensions</olink></para>
</listitem><listitem><para><olink targetptr="ovw-29" remap="internal">Backing Up the System Before Enabling&nbsp;Trusted
Extensions</olink></para>
</listitem>
</itemizedlist><para>For a checklist of Trusted Extensions configuration tasks, see <olink targetptr="checklist-1" remap="internal">Appendix&nbsp;C, Configuration Checklist for Trusted
Extensions</olink>. If you are interested in localizing your site, see <olink targetptr="ovw-19" remap="internal">For International Customers of Trusted Extensions</olink>.
If you are interested in running an <olink targetptr="glossary-42" remap="internal">evaluated
configuration</olink>, see <olink targetptr="ovw-14" remap="internal">Understanding Your Site's
Security Policy</olink>.</para><sect2 id="ovw-13"><title>Understanding Trusted Extensions</title><itemizedlist><para>The enabling and configuration of Trusted Extensions involves more than
loading executable files, specifying your site's data, and setting configuration
variables. Considerable background knowledge is required. Trusted Extensions software
provides a labeled environment that is based on the following concepts:</para><listitem><para>Capabilities that in most <trademark class="registered">UNIX</trademark> environments
are assigned to superuser are available to discrete administrative <olink targetptr="glossary-104" remap="internal">role</olink>s.</para>
</listitem><listitem><para>In addition to UNIX permissions, access to data is controlled
by special security tags. These tags are called <firstterm>labels</firstterm>.
Labels are assigned to users, processes, and objects, such as data files and
directories.</para>
</listitem><listitem><para>The ability to override security policy can be assigned to
specific users and applications.</para>
</listitem>
</itemizedlist>
</sect2><sect2 id="ovw-14"><title>Understanding Your Site's Security Policy</title><indexterm><primary>site security policy</primary><secondary>understanding</secondary>
</indexterm><para>Trusted Extensions effectively enables you to integrate your site's security
policy with the Solaris OS. Thus, you need to have a good understanding of the
scope of your policy and the ability of Trusted Extensions software to accommodate
that policy. A well-planned configuration must provide a balance between consistency
with your site security policy and convenience for users who are working on
the system.</para><itemizedlist><para><indexterm><primary>Trusted Extensions configuration</primary><secondary>evaluated configuration</secondary></indexterm>Trusted Extensions is configured by default
to conform with the Common Criteria for  Information Technology Security Evaluation
(ISO/IEC 15408) at Assurance Level EAL4 against the following protection profiles:</para><listitem><para>Labeled Security Protection Profile</para>
</listitem><listitem><para>Controlled Access Protection Profile</para>
</listitem><listitem><para>Role-Based Access Control Protection Profile</para>
</listitem>
</itemizedlist><itemizedlist><para>To meet these evaluated levels, you must configure LDAP as the naming
service. Note that your configuration might no longer conform with the evaluation
if you do any of the following:</para><listitem><para>Change the kernel switch settings in the <filename>/etc/system</filename> file.</para>
</listitem><listitem><para>Turn off auditing or device allocation.</para>
</listitem><listitem><itemizedlist><para>Change the default entries in the following configurable files:</para><listitem><para><filename>/usr/openwin/server/etc/*</filename></para>
</listitem><listitem><para><filename>/usr/dt/app-defaults/C/Dt</filename></para>
</listitem><listitem><para><filename>/usr/dt/app-defaults/C/Dtwm</filename></para>
</listitem><listitem><para><filename>/usr/dt/app-defaults/C/SelectionManager</filename></para>
</listitem><listitem><para><filename>/usr/dt/bin/Xsession</filename></para>
</listitem><listitem><para><filename>/usr/dt/bin/Xtsolsession</filename></para>
</listitem><listitem><para><filename>/usr/dt/bin/Xtsolusersession</filename></para>
</listitem><listitem><para><filename>/usr/dt/config/sel_config</filename></para>
</listitem><listitem><para><filename>/usr/X11/lib/X11/xserver/TrustedExtensionsPolicy</filename></para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist><para>For more information, see the <ulink url="http://www.commoncriteriaportal.org/" type="text_url">Common Criteria
web site</ulink>.</para>
</sect2><sect2 id="ovw-15"><title>Devising an Administration Strategy for Trusted Extensions</title><indexterm><primary>planning</primary><secondary>administration strategy</secondary>
</indexterm><itemizedlist><para>The <literal>root</literal> user or the System Administrator role is
responsible for enabling Solaris Trusted Extensions. You can create roles to divide administrative
responsibilities among several functional areas:</para><listitem><para>The <olink targetptr="glossary-111" remap="internal">security administrator</olink> is
responsible for security-related tasks, such as setting up and assigning sensitivity
labels, configuring auditing, and setting password policy.</para>
</listitem><listitem><para>The <olink targetptr="glossary-125" remap="internal">system administrator</olink> is
responsible for the non-security aspects of setup, maintenance, and general
administration.</para>
</listitem><listitem><para>The <olink targetptr="glossary-146" remap="internal">primary administrator</olink> is
responsible for creating <olink targetptr="glossary-54" remap="internal">rights profile</olink> for
the security administrator, and for fixing problems when the security and
system administrators do not have sufficient privilege.</para>
</listitem><listitem><para>More limited roles can be configured. For example, an operator
could be responsible for backing up files.</para>
</listitem>
</itemizedlist><itemizedlist><para>As part of your administration strategy, you need to decide the following:</para><listitem><para>Which users are handling which administration responsibilities</para>
</listitem><listitem><para>Which non-administrative users are allowed to run trusted
applications, meaning which users are permitted to override security policy,
when necessary</para>
</listitem><listitem><para>Which users have access to which groups of data</para>
</listitem>
</itemizedlist>
</sect2><sect2 id="ovw-16"><title>Devising a Label Strategy</title><indexterm><primary>labels</primary><secondary>planning</secondary>
</indexterm><indexterm><primary>planning</primary><secondary>labels</secondary>
</indexterm><para>Planning labels requires setting up a hierarchy of sensitivity levels
and a categorization of information on your system. The label encodings file
contains this type of information for your site. You can use one of the <olink targetptr="glossary-69" remap="internal">label_encodings file</olink>s that are supplied on
the Solaris Trusted Extensions installation media. You could also modify one of the supplied
files, or create a new <filename>label_encodings</filename> file that is specific
to your site. The file must include the Sun-specific local extensions, at
least the <literal>COLOR NAMES</literal> section.</para><caution><para>If you are supplying a <filename>label_encodings</filename> file,
you must have the final version of the file ready before rebooting the system
after you enable the Trusted Extensions service. The file should be on removable
media.</para>
</caution><para>Planning labels also involves planning the label configuration. After
enabling the Trusted Extensions service, you need to decide if the system can
run at a single label only, or if the system can run at multiple labels. If
all of your non-administrative users can operate at the same security label,
select a single-label system.</para><para>You can also configure whether labels display and which label name format
is displayed. For more information, see <olink targetdoc="trsollbladmin" remap="external"><citetitle remap="book">Solaris Trusted Extensions Label Administration</citetitle></olink>.
You can also refer to <olink targetdoc="wslblencode" remap="external"><citetitle remap="book">Compartmented Mode Workstation Labeling: Encodings Format</citetitle></olink>.</para><sect3 id="ovw-19"><title>For International Customers of Trusted Extensions</title><indexterm><primary><filename>label_encodings</filename> file</primary><secondary>localizing</secondary>
</indexterm><para>When localizing a <filename>label_encodings</filename> file, international
customers must localize the label names <emphasis>only</emphasis>. The administrative
label names, <literal>ADMIN_HIGH</literal> and <literal>ADMIN_LOW</literal>,
must not be localized. All labeled hosts that you contact, from any vendor,
must have label names that match the label names in the <filename>label_encodings</filename> file.</para><para>Trusted Extensions supports fewer locales than does the Solaris OS. When you
are working in a locale that Trusted Extensions does not support, text that is
specific to Trusted Extensions, such as error messages about labels, is not translated
into your locale. Solaris software continues to be translated into your
locale.</para>
</sect3>
</sect2><sect2 id="ovw-20"><title>Planning System Hardware and Capacity for Trusted Extensions</title><indexterm><primary>Trusted Extensions</primary><secondary>planning hardware</secondary>
</indexterm><indexterm><primary>hardware planning</primary>
</indexterm><indexterm><primary>planning</primary><secondary>hardware</secondary>
</indexterm><para>System hardware includes the system itself and its attached devices.
Such devices include tape drives, microphones, CD-ROM drives, and disk packs.
Hardware capacity includes system memory, network interfaces, and disk space.</para><itemizedlist><listitem><para>Follow the recommendations for installing a Solaris release,
as described in <olink targetdoc="820-0157" remap="external"><citetitle remap="book">Solaris Express Installation Guide: Planning for Installation and Upgrade</citetitle></olink>. Trusted Extensions features can add to those requirements:</para><itemizedlist><para><indexterm><primary>Trusted Extensions</primary><secondary>memory requirements</secondary></indexterm>Memory beyond the suggested minimum is required on the following
systems:</para><listitem><para>Systems that run the Solaris Management Console, a required administrative GUI</para>
</listitem><listitem><para>Systems that run at more than one sensitivity label</para>
</listitem><listitem><para>Systems that are used by users who can assume an administrative
role</para>
</listitem>
</itemizedlist>
</listitem><listitem><itemizedlist><para>More disk space is required on the following systems:</para><listitem><para>Systems that store files at more than one label</para>
</listitem><listitem><para>Systems whose users can assume an administrative role</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</sect2><sect2 id="ovw-22"><title>Planning Your Trusted Network</title><indexterm><primary>Trusted Extensions</primary><secondary>planning network</secondary>
</indexterm><indexterm><primary>planning</primary><secondary>network</secondary>
</indexterm><indexterm><primary>Trusted Extensions network</primary><secondary>planning</secondary>
</indexterm><para>For assistance in planning network hardware, see <olink targetdoc="group-sa" targetptr="ipplan-1" remap="external">Chapter 2, <citetitle remap="chapter">Planning an IPv4 Addressing Scheme (Tasks),</citetitle> in <citetitle remap="book">System Administration Guide: IP Services</citetitle></olink>.</para><para>As in any client-server network, you need to identify hosts by their
function, that is, server or client, and configure the software appropriately.
For assistance in planning, see <olink targetdoc="819-2396" remap="external"><citetitle remap="book">Solaris Express Installation Guide: Custom JumpStart and Advanced Installations</citetitle></olink>.</para><para>Trusted Extensions software recognizes two host types, labeled and unlabeled.
Each host type has a default security template, as shown in <olink targetptr="ovw-tbl-3" remap="internal">Table&nbsp;1&ndash;1</olink>.</para><table frame="topbot" id="ovw-tbl-3"><title>Default Host Templates in Trusted Extensions</title><tgroup cols="3" colsep="0" rowsep="0"><colspec colname="column2" colwidth="113.62*"/><colspec colname="column3" colwidth="124.25*"/><colspec colname="column4" colwidth="295.14*"/><thead><row><entry colname="column2" rowsep="1"><para>Host Type</para>
</entry><entry colname="column3" rowsep="1"><para>Template Name</para>
</entry><entry colname="column4" rowsep="1"><para>Purpose</para>
</entry>
</row>
</thead><tbody><row><entry rowsep="1" valign="top"><para><literal>unlabeled</literal></para>
</entry><entry colname="column3" rowsep="1" valign="top"><para><literal>admin_low</literal></para>
</entry><entry colname="column4" rowsep="1" valign="bottom"><para>At initial boot, labels the global zone.</para><para>After initial boot, identifies hosts that send unlabeled packets.</para>
</entry>
</row><row><entry colname="column2" rowsep="0"><para><literal>cipso</literal></para>
</entry><entry colname="column3" rowsep="0"><para><literal>cipso</literal></para>
</entry><entry colname="column4" rowsep="0"><para>Identifies hosts or networks that send CIPSO packets. CIPSO packets
are labeled.</para>
</entry>
</row>
</tbody>
</tgroup>
</table><para>If your network can be reached by other networks, you need to specify
accessible domains and hosts. You also need to identify which Trusted Extensions hosts
are going to serve as gateways. You need to identify the label <olink targetptr="glossary-2" remap="internal">accreditation range</olink> for these gateways, and
the <olink targetptr="glossary-114" remap="internal">sensitivity label</olink> at which data
from other hosts can be viewed.</para><para>The <olink targetdoc="group-refman" targetptr="smtnrhtp-1m" remap="external"><citerefentry><refentrytitle>smtnrhtp</refentrytitle><manvolnum>1M</manvolnum></citerefentry></olink> man
page provides a complete description of each host type with several examples.</para>
</sect2><sect2 id="ovw-11"><title>Planning for Zones in Trusted Extensions</title><indexterm><primary>planning</primary><secondary>zones</secondary>
</indexterm><indexterm><primary>zones</primary><secondary>deciding creation method</secondary>
</indexterm><para>Trusted Extensions software is added to the Solaris OS in the global zone.
You then configure non-global zones that are labeled. You can create one labeled
zone for every unique label, though you do not need to create a zone for every
label.</para><itemizedlist><para>Part of zone configuration is configuring the network. Labeled zones
must be configured to communicate with the global zone and with other zones
on the network.</para><listitem><para>The X server that runs the desktop display is available only
from the global zone. In the Solaris Express Community Edition,
the loopback interface, <literal>lo0</literal>, can be used to communicate
with the global zone. Therefore, the desktop display is available to non-global
zones over <literal>lo0</literal>.</para>
</listitem><listitem><para>By default, non-global zones use the global zone to reach
the network.  In
the Solaris Express Community Edition, each non-global zone can be configured with a unique default
route that does not use the global zone.</para>
</listitem>
</itemizedlist><sect3 id="ovw-37"><title>Trusted Extensions Zones and Solaris Zones</title><para>Labeled zones differ from typical Solaris zones. Labeled zones
are primarily used to segregate data. In Trusted Extensions, regular users cannot
remotely log in to a labeled zone. The only interactive interface to a labeled
zone is by using the zone console. Only root can gain access to the zone console.</para>
</sect3><sect3 id="ovw-38"><title>Zone Creation in Trusted Extensions</title><para>To create a labeled zone involves copying the entire Solaris OS, and then
starting the services for the Solaris OS in every zone. The process can be time-consuming.
A faster process is to create one zone, then to copy that zone or clone the
contents of that zone. The following table describes your options for zone
creation in Trusted Extensions.</para><informaltable frame="topbot"><tgroup cols="3"><?PubTbl tgroup rth="1.00pt"?><colspec colname="col1" colwidth="32.92*"/><colspec colname="col2" colwidth="27.46*"/><colspec colname="col3" colwidth="46.37*"/><thead><row><entry colsep="0"><para>Zone Creation Method</para>
</entry><entry colsep="0"><para>Effort Required</para>
</entry><entry colsep="0"><para>Characteristics of This Method</para>
</entry>
</row>
</thead><tbody><row><entry colsep="0" rowsep="0"><para>Create each labeled zone from scratch.</para>
</entry><entry colsep="0" rowsep="0"><para>Configure, initialize, install, customize, and boot each labeled zone.</para>
</entry><entry colsep="0" rowsep="0"><itemizedlist><listitem><para>This method is supported, and is useful for creating one or
two additional zones. The zones can be upgraded.</para>
</listitem><listitem><para>This method is time-consuming.</para>
</listitem>
</itemizedlist>
</entry>
</row><row><entry colsep="0" rowsep="0"><para>Create additional labeled zones from a copy of the first labeled zone.</para>
</entry><entry colsep="0" rowsep="0"><para>Configure, initialize, install, and customize one zone. Use this zone
as a template for additional labeled zones.</para>
</entry><entry colsep="0" rowsep="0"><itemizedlist><listitem><para>This method is supported, and is faster than creating zones
from scratch. The zones can be upgraded. Use the Copy Zone method if you want
Sun Support to help you with any zone difficulties.</para>
</listitem><listitem><para>This method uses UFS. UFS does not offer the additional isolation
for zones that Solaris <trademark>ZFS</trademark> offers.</para>
</listitem>
</itemizedlist>
</entry>
</row><row><entry colsep="0" rowsep="0"><para><indexterm><primary>ZFS</primary><secondary>unsupported but fast zone creation method</secondary></indexterm>Create additional labeled zones from
a ZFS snapshot of the first labeled zone.</para>
</entry><entry colsep="0" rowsep="0"><para>Set up a ZFS pool from a partition that you set aside during Solaris installation.</para><para>Configure, initialize, install, and customize one zone. Use this zone
as a ZFS snapshot for additional labeled zones.</para>
</entry><entry colsep="0" rowsep="0"><itemizedlist><listitem><para>This method uses Solaris ZFS, and is the fastest method.
This method makes every zone a file system, and thus provides more isolation
than UFS. ZFS uses much less disk space.</para>
</listitem><listitem><para>If you are testing Trusted Extensions and can reinstall the zones
rather than upgrade, this method might be a good choice. This method can be
useful on systems whose contents are not volatile, because the system can
quickly be reinstalled to a usable state.</para>
</listitem><listitem><para>This method is <emphasis>not</emphasis> supported. Zones that
are created by using this method <emphasis>cannot be upgraded</emphasis> when
a later version of the OS is released.</para>
</listitem>
</itemizedlist>
</entry>
</row>
</tbody>
</tgroup>
</informaltable><itemizedlist><para>Solaris zones affect package installation and patching. For more
information, see the following references:</para><listitem><para><olink targetdoc="group-sa" targetptr="z.pkginst.ov-1" remap="external">Chapter 24, <citetitle remap="chapter">About Packages and Patches on a Solaris System With Zones Installed (Overview),</citetitle> in <citetitle remap="book">System Administration Guide:  Virtualization Using the Solaris Operating System</citetitle></olink></para>
</listitem><listitem><para><ulink url="http://www.opensolaris.org/os/community/zones/faq" type="text_url">Solaris Zones and Containers FAQ</ulink></para>
</listitem>
</itemizedlist>
</sect3>
</sect2><sect2 id="ovw-12"><title>Planning for Multilevel Access</title><indexterm><primary>multilevel server</primary><secondary>planning</secondary>
</indexterm><indexterm><primary>printing</primary><secondary>planning</secondary>
</indexterm><indexterm><primary>planning</primary><secondary>printing</secondary>
</indexterm><indexterm><primary>planning</primary><secondary>NFS server</secondary>
</indexterm><itemizedlist><para>Typically, printing and NFS are configured as multilevel services. To
access multilevel services, a properly configured system requires that every
zone be able to access one or more network addresses. The following configurations
provide multilevel services:</para><listitem><para>As in the Solaris OS, one IP address is assigned for every zone,
including the global zone. A refinement of this configuration is to assign
a separate network information card (NIC) to each zone. Such a configuration
is used to physically separate the single-label networks that are associated
with each NIC.</para>
</listitem><listitem><para>One <literal>all-zones</literal> address is assigned. One
or more zones can have zone-specific addresses.</para>
</listitem>
</itemizedlist><itemizedlist><para>A system that meets the following two conditions cannot provide multilevel
services:</para><listitem><para>One IP address is assigned that the global zone and the labeled
zones share.</para>
</listitem><listitem><para>No zone-specific addresses are assigned.</para>
</listitem>
</itemizedlist><para>If users in labeled zones are not supposed to have access to a local
multilevel printer, and you do not need NFS exports of home directories, then
you can assign one IP address to a system that you configure with Trusted Extensions.
On such a system, multilevel printing is not supported, and home directories
cannot be shared. A typical use of this configuration is on a laptop.</para>
</sect2><sect2 id="ovw-25"><title>Planning for the LDAP Naming Service in Trusted Extensions</title><indexterm><primary>LDAP</primary><secondary>planning</secondary>
</indexterm><indexterm><primary>planning</primary><secondary>LDAP naming service</secondary>
</indexterm><para>If you are not planning to install a network of labeled systems, then
you can skip this section.</para><para>If you plan to run Trusted Extensions on a network of systems, use LDAP
as the naming service. For Trusted Extensions. a populated Sun <trademark>Java</trademark> System Directory Server (LDAP server)
is required when you configure a network of systems. If your site has an existing
LDAP server, you can populate the server with Trusted Extensions databases. To
access the server, you set up an LDAP proxy on a Trusted Extensions system.</para><para>If your site does not have an existing LDAP server, you then plan to
create an LDAP server on a system that is running Trusted Extensions software.
The procedures are described in <olink targetptr="txldap-1" remap="internal">Chapter&nbsp;5,
Configuring LDAP for Trusted Extensions (Tasks)</olink>.</para>
</sect2><sect2 id="ovw-26"><title>Planning for Auditing in Trusted Extensions</title><indexterm><primary>audit planning</primary>
</indexterm><indexterm><primary>planning</primary><secondary>auditing</secondary>
</indexterm><para>By default, auditing is turned on when Trusted Extensions is installed.
Therefore, by default, <literal>root</literal> login and <literal>root</literal> logout
are audited. To audit the users who are configuring the system, you can create
roles early in the configuration process. For the procedure, see <olink targetptr="txconf-14" remap="internal">Creating Roles and Users in Trusted Extensions</olink>.</para><para><indexterm><primary>auditing</primary><secondary>planning</secondary></indexterm>Planning auditing in Trusted Extensions is the same as in the Solaris OS.
For details, see <olink targetdoc="group-sa" targetptr="audittm-1" remap="external">Part&nbsp;VII, <citetitle remap="chapter">Solaris Auditing,</citetitle> in <citetitle remap="book">System Administration Guide: Security Services</citetitle></olink>. While Trusted Extensions adds
classes, events, and audit tokens, the software does not change how auditing
is administered. For Trusted Extensions additions to auditing, see <olink targetptr="audtask-1" remap="internal">Chapter&nbsp;24, Trusted Extensions Auditing (Overview)</olink>.</para>
</sect2><sect2 id="ovw-18"><title>Planning User Security in Trusted Extensions</title><para><indexterm><primary>accounts</primary><secondary>planning</secondary></indexterm><indexterm><primary>planning</primary><secondary>account creation</secondary></indexterm>Trusted Extensions software provides reasonable security defaults
for users. These security defaults are listed in the <olink targetptr="ovw-tbl-4" remap="internal">Table&nbsp;1&ndash;2</olink>. Where two values are listed, the first value
is the default. The security administrator can modify these defaults to reflect
the site's security policy. After the security administrator sets the defaults,
the system administrator can create all the users, who inherit the established
defaults. For descriptions of the keywords and values for these defaults,
see the <olink targetdoc="group-refman" targetptr="label-encodings-4" remap="external"><citerefentry><refentrytitle>label_encodings</refentrytitle><manvolnum>4</manvolnum></citerefentry></olink> and <olink targetdoc="group-refman" targetptr="policy.conf-4" remap="external"><citerefentry><refentrytitle>policy.conf</refentrytitle><manvolnum>4</manvolnum></citerefentry></olink> man pages.</para><table frame="topbot" id="ovw-tbl-4"><title>Trusted Extensions Security Defaults
for User Accounts</title><tgroup cols="3" colsep="0" rowsep="0"><colspec colname="colspec0" colwidth="36.15*"/><colspec colname="colspec1" colwidth="33.81*"/><colspec colname="colspec2" colwidth="29.04*"/><thead><row rowsep="1"><entry><para>File name</para>
</entry><entry><para>Keyword</para>
</entry><entry><para>Value</para>
</entry>
</row>
</thead><tbody><row><entry><para><filename>/etc/security/policy.conf</filename></para>
</entry><entry><para><literal>IDLECMD</literal></para>
</entry><entry><para><literal>lock</literal> | <literal>logout</literal></para>
</entry>
</row><row><entry><para></para>
</entry><entry><para><literal>IDLETIME</literal></para>
</entry><entry><para><literal>30</literal></para>
</entry>
</row><row><entry><para></para>
</entry><entry><para><literal>LABELVIEW</literal></para>
</entry><entry><para><literal>showsl</literal> | <literal>hidesl</literal></para>
</entry>
</row><row><entry><para></para>
</entry><entry><para><literal>CRYPT_ALGORITHMS_ALLOW</literal></para>
</entry><entry><para><literal>1,2a,md5</literal></para>
</entry>
</row><row><entry><para></para>
</entry><entry><para><literal>CRYPT_DEFAULT</literal></para>
</entry><entry><para><literal>_unix_</literal></para>
</entry>
</row><row><entry><para></para>
</entry><entry><para><literal>LOCK_AFTER_RETRIES</literal></para>
</entry><entry><para><literal>no</literal> | <literal>yes</literal></para>
</entry>
</row><row><entry><para></para>
</entry><entry><para><literal>PRIV_DEFAULT</literal></para>
</entry><entry><para><literal>basic</literal></para>
</entry>
</row><row><entry><para></para>
</entry><entry><para><literal>PRIV_LIMIT</literal></para>
</entry><entry><para><literal>all</literal></para>
</entry>
</row><row><entry><para></para>
</entry><entry><para><literal>AUTHS_GRANTED</literal></para>
</entry><entry><para><literal>solaris.device.cdrw</literal></para>
</entry>
</row><row><entry rowsep="1"><para></para>
</entry><entry rowsep="1"><para><literal>PROFS_GRANTED</literal></para>
</entry><entry rowsep="1"><para><literal>Basic Solaris User</literal></para>
</entry>
</row><row><entry colname="colspec0" morerows="1"><para>LOCAL DEFINITIONS section of <filename>/etc/security/tsol/label_encodings</filename></para>
</entry><entry colname="colspec1"><para>Default User Clearance</para>
</entry><entry colname="colspec2"><para><literal>CNF NEED TO KNOW</literal></para>
</entry>
</row><row><entry colname="colspec1"><para>Default User Sensitivity Label</para>
</entry><entry colname="colspec2"><para><literal>PUBLIC</literal></para>
</entry>
</row>
</tbody>
</tgroup>
</table><para>The system administrator can set up a standard user template that sets
appropriate system defaults for every user. For example, by default. each
user's initial shell is a Bourne shell. The system administrator can set up
a template that gives each user a C shell. For more information, see the Solaris Management Console online
help for User Accounts.</para>
</sect2><sect2 id="ovw-27"><title>Devising a Configuration Strategy for Trusted Extensions</title><indexterm><primary>planning</primary><secondary>Trusted Extensions configuration strategy</secondary>
</indexterm><indexterm><primary>Trusted Extensions</primary><secondary>planning configuration strategy</secondary>
</indexterm><indexterm><primary>Trusted Extensions</primary><secondary>separation of duty</secondary>
</indexterm><indexterm><primary>separation of duty</primary><secondary>planning for</secondary>
</indexterm><itemizedlist><para>Allowing the <literal>root</literal> user to configure Trusted Extensions software
is not a secure strategy. The following describes the configuration strategy
from the most secure strategy to the least secure strategy:</para><listitem><para>A two-person team configures the software. The configuration
process is audited.</para><para>Two people are at the computer when the software
is enabled. Early in the configuration process, this team creates local users
and roles. The team also sets up auditing to audit events that are executed
by roles. After roles are assigned to users, and the computer is rebooted,
the software enforces task division by role. The audit trail provides a record
of the configuration process. For an illustration of a secure configuration
process, see <olink targetptr="startinst-14" remap="internal">Figure&nbsp;1&ndash;1</olink>.</para><note><para>If site security requires <olink targetptr="glossary-148" remap="internal">separation
of duty</olink>, a trusted administrator completes <olink targetptr="txconf-95" remap="internal">Create
Rights Profiles That Enforce Separation of Duty</olink> before creating users
or roles. In this customized configuration, one role manages security, including
users' security attributes. The other role manages the non-security attributes
of systems and users.</para>
</note>
</listitem><listitem><para>One person enables and configures the software by assuming
the appropriate role. The configuration process is audited.</para><para>Early
in the configuration process, the <literal>root</literal> user creates a local
user and roles. This user also sets up auditing to audit events that are executed
by roles. Once roles have been assigned to the local user, and the computer
is rebooted, the software enforces task division by role. The audit trail
provides a record of the configuration process.</para>
</listitem><listitem><para>One person enables and configures the software by assuming
the appropriate role. The configuration process is not audited.</para><para>By
using this strategy, no record is kept of the configuration process.</para>
</listitem><listitem><para>The <literal>root</literal> user enables and configures the
software. The configuration process is audited.</para><para>The team sets
up auditing to audit every event that <literal>root</literal> performs during
configuration. With this strategy, the team must determine which events to
audit. The audit trail does not include the name of the user who is acting
as <literal>root</literal>.</para>
</listitem><listitem><para>The <literal>root</literal> user enables and configures the
software.</para>
</listitem>
</itemizedlist><para><indexterm><primary>Trusted Extensions</primary><secondary>two-role configuration strategy</secondary></indexterm>Task division by role is shown in the following
figure. The security administrator sets up auditing, protects file systems,
sets device policy, determines which programs require privilege to run, and
protects users, among other tasks. The system administrator shares and mounts
file systems, installs software packages, and creates users, among other tasks.</para><figure id="startinst-14"><title>Administering a Trusted Extensions System: Task
Division by Role</title><mediaobject><imageobject><imagedata entityref="tworoles.eps"/>
</imageobject><textobject><simpara>Illustration shows the configuration team tasks, then
shows the tasks for the Security Administrator and the System Administrator.</simpara>
</textobject>
</mediaobject>
</figure>
</sect2><sect2 id="ovw-28"><title>Collecting Information Before Enabling&nbsp;Trusted Extensions</title><indexterm><primary>collecting information</primary><secondary>planning Trusted Extensions configuration</secondary>
</indexterm><para>As when configuring the Solaris OS, collect system, user, network, and
label information before configuring Trusted Extensions. For details, see <olink targetptr="startinst-12" remap="internal">Collect System Information Before Enabling Trusted
Extensions</olink>.</para>
</sect2><sect2 id="ovw-29"><title>Backing Up the System Before Enabling&nbsp;Trusted Extensions</title><indexterm><primary>planning</primary><secondary>data migration</secondary>
</indexterm><indexterm><primary>backing up</primary><secondary>previous system before installation</secondary>
</indexterm><para>If your system has files that must be saved, perform a backup before
enabling the Trusted Extensions software. The safest way to back up files is to
do a level 0 dump. If you do not have a backup procedure in place, see the
administrator's guide to your current operating system for instructions.</para><note><para>If you are migrating from a Trusted Solaris 8 release, you can restore
your data only if the Trusted Extensions labels are identical to the Trusted Solaris 8 labels.
Because Trusted Extensions does not create multilevel directories, each file and
directory on backup media is restored to a zone whose label is identical to
the file label in the backup. Backup <emphasis>must be completed</emphasis> before
you reboot the system with Trusted Extensions enabled.</para>
</note>
</sect2>
</sect1><sect1 id="ovw-41"><title>Results of Enabling Trusted Extensions From an Administrator's
Perspective</title><indexterm><primary>Trusted Extensions</primary><secondary>differences from Solaris administrator's perspective</secondary>
</indexterm><indexterm><primary>Trusted Extensions</primary><secondary>results before configuration</secondary>
</indexterm><itemizedlist><para>After the Trusted Extensions software is enabled and the system is rebooted,
the following security features are in place. Many features are configurable
by the security administrator.</para><listitem><para>Auditing is enabled.</para>
</listitem><listitem><para>A Sun <olink targetptr="glossary-69" remap="internal">label_encodings file</olink> is
installed and configured.</para>
</listitem><listitem><para>Two trusted desktops are added. Solaris Trusted Extensions (CDE) is the trusted version
of <olink targetptr="glossary-15" remap="internal">CDE</olink>. Solaris Trusted Extensions (JDS) is the trusted version
of the Sun Java Desktop System. Each windowing environment creates Trusted Path workspaces
in the global zone.</para>
</listitem><listitem><para>As in the Solaris OS, rights profiles for roles are defined.
As in the Solaris OS, roles are not defined.</para><para>To use roles to administer Trusted Extensions,
you must create the roles. During configuration, you create the Security Administrator
role.</para>
</listitem><listitem><para>Three Trusted Extensions network databases, <filename>tnrhdb</filename>, <filename>tnrhtp</filename>, and <filename>tnzonecfg</filename> are added. The databases
are administered by using the Security Templates tool and the Trusted Network
Zones tool in the Solaris Management Console.</para>
</listitem><listitem><para>Trusted Extensions provides GUIs to administer the system. Some
GUIs are extensions to a Solaris OS GUI.</para><itemizedlist><listitem><para>In Trusted CDE, administrative actions are provided in the Trusted_Extensions
folder. Some of these actions are used when you initially configure Trusted Extensions.
The tools are introduced in <olink targetptr="txtool-1" remap="internal">Chapter&nbsp;8, Trusted Extensions Administration Tools</olink>.</para>
</listitem><listitem><para>A  <olink targetptr="glossary-159" remap="internal">trusted editor</olink>   enables administrators to modify local administrative files.
In Trusted CDE, the Admin Editor action invokes a trusted editor.</para>
</listitem><listitem><para>The Device Allocation Manager manages attached devices.</para>
</listitem><listitem><para>The Solaris Management Console provides Java-based tools to manage local and network
administrative databases. The use of these tools is required for managing
the trusted network, zones, and users.</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</sect1>
</chapter><?Pub *0000040734 0?>