Planning for Security in Trusted Extensions
Planning System Hardware and Capacity for Trusted Extensions
Resolving Additional Issues Before Enabling Trusted Extensions
This section describes the planning that is required before enabling and configuring Trusted Extensions software.
For a checklist of Trusted Extensions configuration tasks, see 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
Capabilities that in most UNIX® environments are assigned to root are handled by several administrative roles.
The ability to override security policy can be assigned to specific users and applications.
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:
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.
Planning Who Will Configure Trusted Extensions
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.
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:
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
As part of your administration strategy, you need to decide the following:
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.
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 as a user, 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 Oracle Solaris, as described in Automatically Installing Oracle Solaris 11.4 Systems and the Installation section of the Release Notes.
Trusted Extensions features can add to those recommendations:
Memory beyond the suggested minimum is required on the following servers:
Servers that run at more than one sensitivity label
Servers that are used by users who can assume an administrative role
More disk space is required on the following servers:
Servers that store files at more than one label
Servers whose users can assume an administrative role
Planning Your Trusted Network
For assistance in planning network hardware, see Planning for Network Deployment in Oracle Solaris 11.4.
Trusted Extensions software recognizes four host types. Each host type has a default security template, as shown in Figure 1, Table 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 labeling of hosts, gateways, and networks is explained in Managing Networks in Trusted Extensions. Assigning labels to remote systems is performed after initial setup.
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 or more labeled zones for every unique label, though you do not need to create a zone for every label in your label_encodings file. A provided script enables you to easily create two labeled zones for the default user label and the default user clearance in your label_encodings file.
In Trusted Extensions, the local transport to connect to the X server is UNIX domain sockets. By default, the X server does not listen for TCP connections.
By default, non-global zones cannot communicate with untrusted hosts. You must specify the explicit remote host IP addresses or network masks that can be reached by each zone.
After labeled zones are created, regular users can use the configured system, but these users cannot reach other systems. To further isolate services that run at the same label, you can create secondary zones. For more information, see Primary and Secondary Labeled Zones.
Trusted Extensions Zones and Oracle Solaris Zones
Trusted Extensions zones, that is, labeled zones, are a brand of Oracle Solaris Zones. Labeled zones are primarily used to segregate data. In Trusted Extensions, regular users cannot remotely log in to a labeled zone except from an equally labeled zone on another trusted system. Authorized administrators can access a labeled zone from the global zone. For more about zone brands, see the brands(7) man page.
Zone Creation in Trusted Extensions
Zone creation in Trusted Extensions is similar to zone creation in Oracle Solaris. Trusted Extensions provides the txzonemgr script to step you through the process. The script has several command line options to automate the creation of labeled zones. For more information, see the txzonemgr(8) man page.
Access to Labeled Zones
all-zones interface – One all-zones address is assigned. In this default configuration, only one IP address, also called a shared-IP address, is required. Every zone, global and labeled, can communicate with identically labeled zones on remote systems over this shared address.
A refinement of this configuration is to create a second IP instance for the global zone to use exclusively. This second instance would not share its IP address so would not be an all-zones address. The IP instance could be used to host a multilevel service or to provide a route to a private subnet.
Exclusive IP stack – As in Oracle Solaris, one IP address is assigned to every zone, including the global zone. A virtual network interface card (VNIC) is created for each labeled zone.
A refinement of this configuration is to create each VNIC over a separate network interface. Such a configuration is used to physically separate the single-label networks that are associated with each NIC. Zones that are configured with an exclusive IP stack cannot use the all-zones interface.
On a properly configured system, every zone must be able to use a network address to communicate with other zones that share the same label. The following configurations provide labeled zone access to other labeled zones:
Applications That Are Restricted to a Labeled Zone
By default, labeled zones share the global zone's name service, and have read-only copies of the global zone's configuration files, including the /etc/passwd and /etc/shadow files. If you plan to install applications in a labeled zone from the labeled zone, and the package adds users to the zone, you will need writable copies of these files in the zone.
Packages such as pkg:/service/network/ftp create user accounts. To install this package by running the pkg command inside a labeled zone requires that a separate nscd daemon be running in the zone, and that the zone be assigned an exclusive IP address. For more information, see How to Configure a Separate Name Service for Each Labeled Zone.
Note - If you are in a labeled zone where the nscd daemon is running at the label of the zone, you can have the account-policy service enabled for that zone. If the service is enabled and the config/etc_default_login and config/etc_default_passwd properties are enabled, security policy for logins and passwords is determined by the values of the SMF properties rather than by /etc file entries. For examples of viewing and changing account-policy properties, see the procedures in Modifying Rights System-Wide As SMF Properties in Securing Users and Processes in Oracle Solaris 11.4. See also the account-policy(8S) man page.
Planning for Multilevel Services
By default, Trusted Extensions does not provide multilevel services. Most services are easily configured as zone-to-zone services, that is, as single-label services. For example, each labeled zone can connect to the NFS server that runs at the label of the labeled zone.
If your site requires multilevel services, these services are best configured on a system with at least two IP addresses. The multilevel ports that a multilevel service requires can be assigned to the IP address that is associated with the global zone. An all-zones address can be used by the labeled zones to reach the services.
Tip - If users in labeled zones must not have access to multilevel services, then you can assign one IP address to the system. A typical use of this Trusted Extensions configuration is on a laptop.
Planning for the LDAP Naming Service in Trusted Extensions
If you are not planning to install a network of labeled servers, then you can skip this section. If you are planning to use LDAP, your servers must be configured as LDAP clients before you add the first labeled zone.
LDAP is the naming service for a network of Trusted Extensions systems. A populated LDAP server that includes Trusted Extensions databases is required when you configure a network of servers. If your site has an existing LDAP server, you can populate that 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 a Trusted Extensions LDAP server. The procedures are described in Configuring LDAP for Trusted Extensions.
Planning for Auditing in Trusted Extensions
By default, auditing is enabled. 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 Managing Auditing in Oracle Solaris 11.4. Trusted Extensions software does not change how auditing is administered, but recommends now auditing should be administered. See Trusted Extensions and Auditing.
Planning User Security in Trusted Extensions
Trusted Extensions software provides reasonable security defaults for users. The defaults are identical to Oracle Solaris defaults except for the keywords listed in Figure 2, Table 2, Trusted Extensions Security Defaults for User Accounts. After the security administrator sets the security defaults to the values that reflect the site's security policy, new users will inherit these values unless the administrator overrides the values on the command line. For descriptions of the keywords and values, see the label_encodings(5) and policy.conf(5) man pages.
Note - Where two values are listed in the following table, the first value is the default.
|
Note - The IDLECMD and IDLETIME variables apply to the login user's session. If the login user assumes a role, the user's IDLECMD and IDLETIME values are in effect for that role.
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 bash shell. The system administrator can set up a template that gives each user a pfbash shell.
Forming an Install Team for Trusted Extensions
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 administrative roles, and trusted 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 users log in and assume an administrative role. 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 Administering a Trusted Extensions System: Task Division by Role.
One person enables and configures the software by assuming the appropriate role. The configuration process is audited.
Early in the configuration process, the root role creates additional roles. The root role also sets up auditing to audit events that are executed by roles. Once these additional roles have been assigned to the initial user, and the computer is rebooted, the user logs in and assume the appropriate role for the current task. The audit trail provides a record of the configuration process.
One person enables and configures the software by assuming the root role. The configuration process is not audited.
By using this strategy, no record is kept of the configuration process.
The initial setup team changes the root role into a user.
No record is kept in the software of the name of the user who is acting as root. This setup might be required for remote administration of a headless system.
The following describes the configuration strategy from the most secure strategy to the least secure strategy:
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 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 servers, decide which labels to attach to zones, and resolve other security issues. For the steps, see Resolving Security Issues Before Installing 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.