Planning for Security in Trusted Extensions

This section outlines the planning that is required before enabling and configuring Trusted Extensions software.

• Understanding Trusted Extensions

• Understanding Your Site's Security Policy

• Planning Who Will Configure Trusted Extensions

• Devising a Label Strategy

• Planning System Hardware and Capacity for Trusted Extensions

• Planning Your Trusted Network

• Planning Your Labeled 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 a Configuration Strategy for Trusted Extensions

• Resolving Additional Issues Before Enabling Trusted Extensions

• Backing Up the System Before Enabling Trusted Extensions

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.

Understanding Trusted Extensions

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 two Oracle Solaris features:

• Capabilities that in most UNIX environments are assigned to superuser are handled by discrete administrative roles.

• The ability to override security policy can be assigned to specific users and applications.

In Trusted Extensions, 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. These labels supply mandatory access control (MAC), in addition to UNIX permissions, or discretionary access control (DAC).

Understanding Your Site's Security Policy

Trusted Extensions effectively enables you to integrate your site's security policy with the Oracle Solaris OS. Thus, you need to have a good understanding of the scope of your policy and how Trusted Extensions software can implement 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 public files in the /usr directory.

For more information, see the Common Criteria web site.

Planning Who Will Configure Trusted Extensions

The root role or the System Administrator role is responsible for enabling Trusted Extensions. 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.

• 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 administrative 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

Devising a Label Strategy

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 with Trusted Extensions software. 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 Oracle-specific local extensions, at least the COLOR NAMES section.

---

Caution - If you are supplying a label_encodings file, best practice is to have the final version of the file before the labels are verified by the system. Labels are verified during the first boot after the Trusted Extensions service is enabled.

---

Planning labels also involves planning the label configuration. After enabling the Trusted Extensions service, you need to decide if the system must allow logins at multiple labels, or if the system can be configured with one user label only. For example, an LDAP server is a good candidate to have one labeled zone. For local administration of the server, you would create a zone at the minimum label. To administer the system, the administrator logs in, and from the user workspace assumes the appropriate role.

For more information, see Trusted Extensions Label Administration. You can also refer to Compartmented Mode Workstation Labeling: Encodings Format.

For International Customers of Trusted Extensions

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.

Planning System Hardware and Capacity for Trusted Extensions

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 an Oracle Solaris release, as described in the installation guide for this release and the Installation section of the Release Notes for this release.

• Trusted Extensions features can add to those recommendations:

  • 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

Planning Your Trusted Network

For assistance in planning network hardware, see Chapter 2, Planning Your TCP/IP Network (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 10 5/09 Installation Guide: Custom JumpStart and Advanced Installations.

Trusted Extensions software recognizes two host types, cipso and unlabeled. Each host type has a default security template, as shown in Table 1-1.

Table 1-1 Default Host Templates in Trusted Extensions

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 smtnrhtp(1M) man page provides a complete description of each host type with several examples.

Planning Your Labeled Zones in Trusted Extensions

Trusted Extensions software is added to Oracle Solaris 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 in your label_encodings file.

Part of zone configuration is configuring the network. By default, labeled zones are configured to communicate with the global zone. Additionally, you can configure the zones on the system to communicate with other zones on the network.

• The X server that runs the desktop display is available only from the global zone. Starting in the Solaris 10 10/08 release, the loopback interface, lo0, can be used to communicate with the global zone. Therefore, the desktop display is available to non-global zones over lo0.

• By default, non-global zones cannot communicate with untrusted hosts. Starting in the Solaris 10 10/08 release, you can configure each non-global zone with a unique default route that does not use the global zone.

Trusted Extensions Zones and Oracle Solaris Zones

Labeled zones differ from typical Oracle 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.

Zone Creation in Trusted Extensions

To create a labeled zone involves copying the entire Oracle Solaris OS, and then starting the services for the Oracle 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.

Oracle Solaris zones affect package installation and patching. For more information, see the following references:

• Chapter 25, About Packages and Patches on a Solaris System With Zones Installed (Overview), in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones

• Solaris Zones and Containers FAQ

Planning for Multilevel Access

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:

• Exclusive IP stack – As in the Oracle Solaris OS, one IP address is assigned for every zone, including the global zone. By default, a Virtual Network Information Card (VNIC) is created for each labeled 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.

• Shared IP stack – One all-zones address is assigned. In this configuration, the system cannot be a multilevel NFS server. 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.

Planning for the LDAP Naming Service in Trusted Extensions

If you are not planning to install a network of labeled systems, then you can skip this section.

If you plan to run Trusted Extensions on a network of systems, use LDAP as the naming service. For Trusted Extensions. 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 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).

Planning for Auditing in Trusted Extensions

By default, auditing is enabled when Trusted Extensions is installed. Therefore, by default, root login, screenlock, and logout are audited. To audit the users who are configuring the system, you can create roles early in the configuration process. When these roles configure the system, the audit records include the login user who assumes the role. See Creating Roles and Users in Trusted Extensions.

Planning auditing in Trusted Extensions is the same as in the Oracle Solaris OS. For details, see Part VII, Auditing in Oracle Solaris, 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 Trusted Extensions Administrator’s Procedures.

Planning User Security in Trusted Extensions

Trusted Extensions software provides reasonable security defaults for users. These security defaults are listed in 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_encodings(4) and policy.conf(4) man pages.

Table 1-2 Trusted Extensions Security Defaults for User Accounts

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 pfbash shell. For more information, see the Solaris Management Console online help for User Accounts.

Devising a Configuration Strategy for Trusted Extensions

Allowing the root 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:

• A two-person team configures the software. The configuration process is audited.

  Two people are at the computer when the software is enabled. Early in the configuration process, this team creates roles, and local users who can assume those 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.

  ---

  Note - If site security requires separation of duty, a trusted administrator completes Create Rights Profiles That Enforce Separation of Duty 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.

  ---

• One person enables 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 enables 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 enables and configures the software. The configuration process is audited.

  The 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 enables and configures the software.

Task division by role is shown in the following figure. The security administrator configures 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.

Figure 1-1 Administering a Trusted Extensions System: Task Division by Role

Resolving Additional Issues Before Enabling Trusted Extensions

Before configuring Trusted Extensions, you must physically protect your systems, decide which labels to attach to zones, and resolve other security issues. For the procedures, see Collecting Information and Making Decisions Before Enabling Trusted Extensions.

Backing Up the System Before Enabling Trusted Extensions

If your system has files that must be saved, perform a backup before enabling the Trusted Extensions service. 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.