This section outlines the planning required before installing and configuring the Trusted Solaris operating environment.
Installation and configuration of the Trusted Solaris environment involves more than loading executable files, entering your site's data, and setting configuration variables. It requires considerable background. Trusted Solaris provides a unique environment based on the following concepts:
Superuser has been eliminated. No one can log in as or su to root.
Capabilities formerly assigned to superuser are available to discrete administrative roles to be assigned to a limited number of users.
Users are limited to those applications necessary for performing their jobs.
In addition to UNIX permissions, access to data is controlled by special security tags called sensitivity labels which are assigned to users and objects (such as data files and directories).
The ability to override security policy can be assigned to specific users and applications.
To familiarize yourself with the Trusted Solaris environment, you should at a minimum read the Trusted Solaris User's Guide and Trusted Solaris Administration Overview. You should also be familiar with the rest of the documentation set, which is described in the Trusted Solaris Documentation Roadmap.
Through its configurability, the Trusted Solaris environment effectively lets you integrate your site's security policy with the operating environment. Thus, you need to have a good feel for the scope of your policy and the ability of Trusted Solaris software to accommodate it. A good configuration should provide a balance between consistency with your site security policy and convenience for those working in the environment.
The Trusted Solaris operating environment is configured by default to conform with the ITSEC evaluation certificate FB1 (and FC2 which is less stringent). To meet these evaluated levels, you must:
Select NIS+ as the naming service.
Select multiple-label environment operation for the FB1 level. The FC2 level permits single- or multiple-label operation.
Note that your configuration may no longer conform with the ITSEC security levels if you do any of the following:
Change the kernel switch settings in the /etc/system file, other than those switches and their values documented in this manual.
Provide security-relevant execution profiles to non-administrative users.
Change the default entries in these configurable files:
/usr/openwin/server/tsol/*
/usr/dt/app-defaults/C/Sel_Mgr
/usr/dt/bin/Xsession
/usr/dt/bin/Xtsolusersession
/usr/dt/config/sel_config
/usr/dt/app-defaults/C/Dtwm
/usr/dt/app-defaults/C/Dt
/usr/dt/config/C/sys.dtwmrc
The root role is mainly responsible for installing the Trusted Solaris 8 CD-ROM. After the initial Trusted Solaris installation, the root role is mostly not useful. In place of root or superuser, the Trusted Solaris environment suggests creating three or four administrative roles for managing the environment:
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 things when the security and system administrators do not have the power.
A less trusted role called "oper" for operator is responsible for backing up files.
As part of your administration strategy, you need to decide:
Which users will be handling which administration responsibilities.
Which non-administrative users will be allowed to run trusted applications, that is, will be permitted to override security policy when necessary.
Which users will have access to which groups of data.
Planning labels requires setting up a hierarchy of sensitivity levels and a categorization of information in your environment. The label encodings file contains this type of information for your organization. You can use one of the label_encodings files supplied on the Trusted Solaris CD-ROM, modify one of the supplied files, or create a new label encodings file specific to your site. The file should include the SUN-specific local extensions (at least the COLOR NAMES section) when used in the Trusted Solaris environment.
The default label_encodings(4) file is useful for demos, but it is not a good choice for use by a customer site.
IMPORTANT: you must have the final version of the label encodings file ready prior to configuring the first workstation.
To learn more about the label encodings file, see Trusted Solaris Label Administration. You can also refer to Compartmented Mode Workstation Labeling: Encodings Format.
Planning labels also involves planning label configuration. After installation, you need to make the following decisions regarding the use of labels:
Single- or multiple-label environment -- If all of your non-administrative users can operate at the same security label, select a single-label system. Multiple-label environments are required for the FB1 level. If you want a no-label system, select single-label, and then hide the labels for all users.
Hide or display upgraded names in directories -- If you want to prevent a user (or intruder) from viewing the names of files or directories at higher levels than the current sensitivity label, choose this option.
After installation, you can make the following label configuration display changes using User Accounts:
Display administrative label names -- You can show the actual administrative label names, or show substitute names for the labels.
Hide or display labels -- You can hide or display labels on a per-user basis.
When localizing a label_encodings file, international customers should localize the label names only. The administrative label names, ADMIN_HIGH and ADMIN_LOW, must not be localized. All labeled workstations that you contact, from any vendor, must have label names that match the label names in the Trusted Solaris label_encodings file.
Each site should replace the label_encodings file provided on the Trusted Solaris CD with their own. Their file should have appropriate values for the label encodings keywords.
The software ships with reasonable security defaults for users, in two files listed in Table 1-1. 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 has set the defaults, the system administrator can create all the users, who will inherit the established defaults. See the label_encodings(4) and policy.conf(4) man pages for a description of the keywords and values.
The system administrator can set up a standard user template that will set appropriate system defaults for users. 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 by default. See the Solaris Management Console online help for User Accounts for more information.
Table 1-1 Trusted Solaris Security Defaults for User Accounts
File name |
Keyword |
Value |
---|---|---|
/etc/security/policy.conf |
IDLECMD |
lock | logout |
|
IDLETIME |
30 |
|
LABELVIEW |
showsl | hidesl |
|
LOCK_AFTER_RETRIES |
yes | no |
|
PASSWORD |
manual | auto |
|
PROFS_GRANTED |
Basic Solaris User |
LOCAL DEFINITIONS section of /etc/security/tsol/label_encodings |
Default User Clearance |
c |
Default User Sensitivity Label |
u |
|
|
Admin Low Name |
ADMIN_LOW |
|
Admin HIgh Name |
ADMIN_HIGH |
|
Default Label View |
External | Internal |
Workstation hardware includes the workstation itself and its attached devices (tape drives, microphones, CD drives, and disk packs). Its capacity includes its memory, its network interfaces, and its disk space.
Consult the Solaris 8 Sun Hardware Platform Guide for a list of hardware that supports the Trusted Solaris environment. Any exceptions are noted in Trusted Solaris 8 Release Notes.
Peripheral hardware and capacity required for initial installation on a SPARC include:
64 MB minimum memory -- 256 MB memory recommended to handle Solaris Management Console requests
Local CD-ROM drive
Memory over the minimum is required on Trusted Solaris workstations that:
Are used as servers: name servers, file servers, audit servers, boot servers
Run graphics or other large applications
Run compilers
Run number-crunching applications
Run at more than one sensitivity label
Are used by users who can assume an administrative role
Similarly, disk space requirements are greater for some workstations. See "Disk Space Planning" in Solaris 8 Advanced Installation Guide for a list of factors that affect disk space. Particular Trusted Solaris features that require more disk space include:
Disks with files stored at more than one label
Disks whose users can assume administrative roles
For each Trusted Solaris workstation, you need to determine the following:
Name and IP address
Ethernet address (for network installations)
Sun architecture (for network installations)
Root password
PROM security level: maintenance password only, or boot password
PROM password (for Intel Architecture: BIOS protection)
What devices may be attached to the workstation
Which users may use the workstation
Which printers at what labels are accessible from the workstation
If you are installing a non-networked workstation, you can skip this step.
For help in planning network hardware, see "Planning Your TCP/IP Network" in System Administration Guide, Volume 3.
As in any client-server network, you need to identify hosts by their function (server or client) and configure the software appropriately. The following table lists servers you may need to create and their function. For more information, see System Administration Guide: Basic Administration.
Table 1-2 Possible Servers in a Trusted Solaris Environment
Create ... |
If You Plan to ... |
---|---|
Audit data server |
Enable auditing |
Audit administration server |
Analyze the audit trail |
File server |
Centrally locate files for general use |
Install server |
Install over the network or use Custom JumpStart scripts |
DNS server |
Resolve internet names and addresses outside your local network |
Home directory server |
Enable remote mounting of users' home directories. Required in a name service environment. |
Mail server |
Funnel mail to end user workstations from a central location |
Network gateway |
Operate an Failed Cross Reference Format |
Name Service Servers |
Establish a NIS or NIS+ domain |
Print server |
Print hard copy |
To plan the system administration aspects of servers, see the administration guides in the Solaris 8 System Administrator Collection including:
System Administration Guide, Volume 1
System Administration Guide, Volume 2
If your network is open to other networks, you need to specify accessible domains and workstations, and identify which Trusted Solaris hosts will serve as gateways to access them. You need to identify the Trusted Solaris accreditation range for these gateways, and the sensitivity label at which data from other hosts may be viewed. Trusted Solaris software recognizes four labeled host types, including Trusted Solaris (sun_tsol), and provides eleven templates by default, as shown in Table 1-3. The unlabeled template names correspond to the label names in the demo label_encodings(4) file installed from the Trusted Solaris CD.
Table 1-3 Templates Provided with Trusted Solaris Network Software
Host Type |
Template Name |
Purpose |
|
---|---|---|---|
|
Unlabeled |
admin_low |
For initial boot, before the host is configured with Trusted Solaris software. |
|
|
unclassified |
For hosts or networks that send unlabeled packets, for example, SUN workstations running Solaris software. |
|
|
confidential |
|
|
|
secret |
|
|
|
top_secret |
|
Labeled |
|
|
|
|
Trusted Solaris (sun_tsol) |
tsol |
For Trusted Solaris 2.5.1, 7, and 8 hosts or networks. |
|
tsol_ripso |
For Trusted Solaris 2.5.1, 7, and 8 hosts or networks that label packets with the RIPSO security option. |
|
|
|
tsol_cipso |
For Trusted Solaris 2.5.1, 7, and 8 hosts or networks that label packets with the CIPSO security option. |
|
TSIX |
tsix |
For TSIX(RE1.1) hosts or networks. |
|
CIPSO |
cipso |
For hosts or networks that send CIPSO packets. |
|
RIPSO |
ripso_top_secret |
For hosts or networks that send RIPSO Top Secret packets. |
The tnrhtp(4) man page gives complete descriptions of each host type with several examples.
Auditing requires the storage and analysis of potentially a huge amount of data. Before you set up auditing, you need to:
Decide which classes of activity you need to audit. It is good practice to keep these to a minimum.
Plan how you are going to handle the storage and administration of the auditing data.
Each host should have a disk dedicated to audit data collection with a primary partition and a second partition for overflow records.
If you are auditing a network, you should dedicate at least one server to data collection and another server to data administration and analysis. Ideally, you should have your primary and secondary data collection areas on different hosts. In addition, it is recommended that you reserve a fallback partition on the local hosts in case the network goes down.
Read Trusted Solaris Audit Administration for step by step assistance.
The Trusted Solaris software is initially loaded by root. Since root cannot log into the Trusted Solaris environment, a local user named "install" has been provided for the first part of the configuration process. Subsequent configuration is a two-person process (by default) using the security administrator and the system administrator roles. Once the roles have been assigned to users, and the workstation is rebooted, the software enforces task division by role.
If two-person installation is not a site security requirement, assigning the two administrative roles to one person enables that person to configure both security and system information.
In a name service environment, you should install and configure workstations in the order:
Name service master
Home directory server
Install server
Other name service servers
Other servers
End user workstations
Each role needs to gather the information for the tasks particular to the role. Concrete examples are in Appendix B, Checklists for Configuring and Installing Trusted Solaris.
If your workstation has any files on it that you want to save, make sure you perform a backup. 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 Trusted Solaris 2.5, Trusted Solaris 2.5.1, or Trusted Solaris 7 to the Trusted Solaris 8 release, and you want to retain some profile and user information, be sure to convert the tsoluser and tsolprof databases to their Trusted Solaris 8 formats before installing Trusted Solaris 8. See the tsolconvert man page on the Trusted Solaris web site, http://www.sun.com/software/solaris/trustedsolaris/ts_tech_faq/. Backup and conversion must be completed before Trusted Solaris 8 is installed.
Installing Trusted Solaris can be done interactively using CD-ROMs, over the network, or with Custom JumpStartTM scripts. The first three workstations, the name service master (NIS or NIS+) , the home directory server, and the install server (if you wish to do network or Custom JumpStart installs), must be installed from the CD-ROM. Subsequent workstations can be installed using the server.
Installing over the network requires network setup. The installation program prompts the install team for needed information. Using Custom JumpStart requires some knowledge of Bourne shell scripting to automate installation. However, you can write scripts where no human interaction with the installation program is required.
For security reasons, the installation program does not offer some of the options that are available for Solaris 8 software. See "Differences from Solaris 8 Installation and Configuration" for details.
After the installation image is installed, the install team logs in as the user "install" and assumes the root role to configure initial security, network, and administrative role information, as shown in the following figure.
Once users who can assume the administrative roles are created, the install team reboots the workstation. Further configuration tasks are then partitioned by the software to a particular role.
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.