Solaris 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.Planning for Security in Trusted Extensions Results of Installing Trusted Extensions From an Administrator's Perspective This section outlines the planning that is required before installing and configuring Trusted Extensions software.Understanding Trusted Extensions Understanding Your Site's Security Policy Devising an Administration Strategy for Trusted Extensions Devising a Label Strategy Planning System Hardware and Capacity for Trusted Extensions Planning Your Trusted Network Planning for Zones in Trusted Extensions Planning for Multilevel Access Planning for the LDAP Naming Service in Trusted Extensions Planning for Auditing in Trusted Extensions Planning User Security in Trusted Extensions Devising an Installation and Configuration Strategy for Trusted Extensions Collecting Information Before Installing Trusted Extensions Backing Up the System Before Installing Trusted Extensions Installing Solaris Trusted Extensions Software For a checklist of Trusted Extensions configuration tasks, see Appendix C, Configuration Checklist for Trusted Extensions. If you are interested in localizing your site, see For International Customers of Trusted Extensions. If you are interested in running an evaluated configuration, see Understanding Your Site's Security Policy.The installation 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:Capabilities that in most UNIX environments are assigned to superuser are available to discrete administrative roles. In addition to UNIX permissions, access to data is controlled by special security tags. These tags are called labels. Labels are assigned to users, processes, and objects, such as data files and directories. The ability to override security policy can be assigned to specific users and applications. 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.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:Labeled Security Protection Profile Controlled Access Protection Profile Role-Based Access Control Protection Profile 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:Change the kernel switch settings in the /etc/system file. Turn off auditing or device allocation. Change the default entries in the following configurable files:/usr/openwin/server/etc/* /usr/dt/app-defaults/C/Dt /usr/dt/app-defaults/C/Dtwm /usr/dt/app-defaults/C/SelectionManager /usr/dt/bin/Xsession /usr/dt/bin/Xtsolsession /usr/dt/bin/Xtsolusersession /usr/dt/config/sel_config /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy For more information, see the Common Criteria web site. The root user or the System Administrator role is responsible for loading the packages from the Solaris Trusted Extensions installation media. You can create roles to divide administrative responsibilities among several functional areas:The security administrator is responsible for security-related tasks, such as setting up and assigning sensitivity labels, configuring auditing, and setting password policy. The system administrator is responsible for the non-security aspects of setup, maintenance, and general administration. The primary administrator is responsible for creating rights profile for the security administrator, and for fixing problems when the security and system administrators do not have sufficient privilege. More limited roles can be configured. For example, an operator could be responsible for backing up files. As part of your administration strategy, you need to decide the following:Which users are handling which administration responsibilities Which non-administrative users are allowed to run trusted applications, meaning which users are permitted to override security policy, when necessary Which users have access to which groups of data 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 label_encodings files that are supplied on the Solaris Trusted Extensions installation media. You could also modify one of the supplied files, or create a new label_encodings file that is specific to your site. The file must include the Sun-specific local extensions, at least the COLOR NAMES section.If you are supplying a label_encodings file, you must have the final version of the file ready for use before adding the Solaris Trusted Extensions packages. The file is added before you reboot the system for configuration. The file should be on removable media. Planning labels also involves planning the label configuration. After adding the Trusted Extensions packages to a system, 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.You can also configure whether labels display and which label name format is displayed. For more information, see Solaris Trusted Extensions Label Administration. You can also refer to Compartmented Mode Workstation Labeling: Encodings Format.When localizing a label_encodings file, international customers must localize the label names only. The administrative label names, ADMIN_HIGH and ADMIN_LOW, must not be localized. All labeled hosts that you contact, from any vendor, must have label names that match the label names in the label_encodings file.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. 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.Follow the recommendations for installing a Solaris release, as described in System Requirements and Recommendations in Solaris Express Installation Guide: Basic Installations. Trusted Extensions features can add to those requirements:Memory beyond the suggested minimum is required on the following systems:Systems that run the Solaris Management Console, a required administrative GUI Systems that run at more than one sensitivity label Systems that are used by users who can assume an administrative role More disk space is required on the following systems:Systems that store files at more than one label Systems whose users can assume an administrative role For assistance in planning network hardware, see Chapter 2, Planning an IPv4 Addressing Scheme (Tasks, in System Administration Guide: IP Services.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 Solaris Express Installation Guide: Custom JumpStart and Advanced Installations.Trusted Extensions software recognizes two host types, labeled and unlabeled. Each host type has a default security template, as shown in Table 1–1.Host Type Template Name Purpose unlabeled admin_low At initial boot, labels the global zone.After initial boot, identifies hosts that send unlabeled packets. cipso cipso Identifies hosts or networks that send CIPSO packets. CIPSO packets are labeled. 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 accreditation range for these gateways, and the sensitivity label at which data from other hosts can be viewed.The tnrhtp4 man page provides a complete description of each host type with several examples. 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.Labeled zones differ from typical Solaris 10 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. 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.Zone Creation Method Effort Required Characteristics of This Method Create each labeled zone from scratch. Configure, initialize, install, customize, and boot each labeled zone. This method is supported, and is useful for creating one or two additional zones. The zones can be upgraded. This method is time-consuming. Create additional labeled zones from a copy of the first labeled zone. Configure, initialize, install, and customize one zone. Use this zone as a template for additional labeled zones. 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. This method uses UFS. UFS does not offer the additional isolation for zones that Solaris ZFS offers. Create additional labeled zones from a ZFS snapshot of the first labeled zone. Set up a ZFS pool from a partition that you set aside during Solaris installation.Configure, initialize, install, and customize one zone. Use this zone as a ZFS snapshot for additional labeled zones. 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. 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. This method is not supported. Zones that are created by using this method cannot be upgraded when a later version of the OS is released. Solaris zones affect package installation and patching. For more information, see the following references:Solaris 10 Release Notes Chapter 24, About Packages and Patches on a Solaris System With Zones Installed (Overview), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones Solaris Zones and Containers FAQ 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: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. One all-zones address is assigned. One or more zones can have zone-specific addresses. A system that meets the following two conditions cannot provide multilevel services:One IP address is assigned that the global zone and the labeled zones share. No zone-specific addresses are assigned. 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. If you are not planning to install a network of labeled systems, then you can skip this section.If you are installing a network of systems, LDAP is used by Trusted Extensions as the naming service. A populated Sun Java 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.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 Chapter 5, Configuring LDAP for Trusted Extensions (Tasks). By default, auditing is turned on when Trusted Extensions is installed. Therefore, by default, root login and root 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 Creating Roles and Users in Trusted Extensions.Planning auditing in Trusted Extensions is the same as in the Solaris OS. For details, see Part VII, Solaris Auditing, in System Administration Guide: Security Services. 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 Chapter 18, Trusted Extensions Auditing (Overview), in Solaris Trusted Extensions Administrator’s Procedures. Trusted Extensions software provides reasonable security defaults for users. These security defaults are listed in the Table 1–2. 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 label_encodings4 and policy.conf4 man pages.File name Keyword Value /etc/security/policy.conf IDLECMD lock | logout IDLETIME 30 LABELVIEW showsl | hidesl CRYPT_ALGORITHMS_ALLOW 1,2a,md5 CRYPT_DEFAULT _unix_ LOCK_AFTER_RETRIES no | yes PRIV_DEFAULT basic PRIV_LIMIT all AUTHS_GRANTED solaris.device.cdrw PROFS_GRANTED Basic Solaris User LOCAL DEFINITIONS section of /etc/security/tsol/label_encodings Default User Clearance CNF NEED TO KNOW Default User Sensitivity Label PUBLIC 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. As in the Solaris OS, Trusted Extensions software is initially installed by the root user. However, allowing the root user to configure the software is not a secure strategy. The following describes the installation and configuration strategies from the most secure strategy to the least secure strategy:A two-person installation team installs and configures the software. The configuration process is audited.Two people are at the computer when the software is installed. 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 Figure 1–1. One person installs and configures the software by assuming the appropriate role. The configuration process is audited.Early in the configuration process, the root 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. One person installs and configures the software by assuming the appropriate role. The configuration process is not audited.By using this strategy, no record is kept of the configuration process. The root user installs and configures the software. The configuration process is audited.The install team sets up auditing to audit every event that root 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 root. The root user installs and configures the software. 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.

Illustration shows the install team tasks, then shows the tasks for the Security Administrator and the System Administrator.

As when configuring the Solaris OS, collect system, user, network, and label information before configuring Trusted Extensions. For details, see Collect System Information Before Installing Trusted Extensions. If your system has files that must be saved, perform a backup before installing 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.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 must be completed before you install the Trusted Extensions release. Installing Trusted Extensions software means installing packages on a Solaris system. For security reasons, some of the options that are available for Solaris installation must not be chosen. For details, see Installing or Upgrading the Solaris OS for Trusted Extensions. After the Trusted Extensions software is installed, the following security features are in place. Many features are configurable by the security administrator.Auditing is enabled. A Sun label_encodings file is installed and configured. Two trusted desktops are added. Solaris Trusted Extensions (CDE) is the trusted version of CDE. 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. As in the Solaris OS, rights profiles for roles are defined. As in the Solaris OS, roles are not defined.To use roles to administer Trusted Extensions, you must create the roles. During configuration, you create the Security Administrator role. Three Trusted Extensions network databases, tnrhdb, tnrhtp, and tnzonecfg are installed. The databases are administered by using the Security Templates tool and the Trusted Network Zones tool in the Solaris Management Console. Trusted Extensions provides GUIs to administer the system. Some GUIs are extensions to a Solaris OS GUI.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 Chapter 2, Trusted Extensions Administration Tools, in Solaris Trusted Extensions Administrator’s Procedures. A trusted editor enables administrators to modify local administrative files. In Trusted CDE, the Admin Editor action invokes a trusted editor. The Device Allocation Manager manages attached devices. 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.