This chapter provides general information on installing, configuring, and using the Trusted Solaris 8 operating environment on the Sun EnterpriseTM 10000. It describes supported software configurations, differences between Solaris 8 and Trusted Solaris 8 features, and offers two illustrations of supported configurations.
The Trusted Solaris operating environment is based on the Solaris 8 Update 1 release.
The recommended configuration for Trusted Solaris 8 on a Sun Enterprise 10000 is to run the Trusted Solaris operating environment on the SSPs and on the domains. It is possible to run a heterogeneous environment, with both the Trusted Solaris environment and the Solaris environment on the SSPs and the domains.
The Trusted Solaris version of SSP 3.3 (referred to as Trusted Solaris SSP 3.3), is shipped on the Trusted Solaris 8 Supplement CD, as is the Trusted Solaris version of AP 2.3 (referred to as Trusted Solaris AP 2.3). If an SSP is to run the Trusted Solaris 8 operating environment, then the Trusted Solaris SSP 3.3 should be installed. If a domain is to run the Trusted Solaris 8 operating environment, then the Trusted Solaris AP 2.3 should be used for that domain.
If an SSP is to run Solaris 8 software, then the Solaris version of SSP 3.3 should be used for that SSP. If a domain is to run Solaris 8 software, then the Solaris version of AP 2.3 should be used for that domain.
For administrators familiar with Trusted Solaris installation, installing a Trusted Solaris SSP and a Trusted Solaris domain are extensions of installing the Trusted Solaris 8 operating environment with trusted packages. Administrators familiar with installing Solaris software on a Sun Enterprise 10000 should be aware of the differences between the Solaris and Trusted Solaris environments.
The Trusted Solaris environment does not have a superuser. Superuser tasks are divided among administrative roles. administrative roles run with a special shell, a profile shell (see the pfexec(1) man page). Roles do not directly log in; they are “assumed” by a user who is assigned the role by the security administrator. A role can only log in remotely from the same role on another Trusted Solaris workstation. For more information on roles, see “Assuming a Role and Working in a Role Workspace” in Trusted Solaris Administrator's Procedures.
The Solaris superuser (root) has been replaced by Trusted Solaris administrative roles, such as root and admin. For the Trusted Solaris SSP 3.3 and the Trusted Solaris AP 2.3, any commands that superuser runs in a Solaris environment are run by the admin role in a Trusted Solaris environment. The admin role runs with a profile shell (pfsh), and should not be changed to run with other shells.
Trusted Solaris access to the superuser on the SSP console is different from Solaris access due to Trusted Solaris role constraints.
On a Solaris SSP console, the superuser can directly log in, or can use the su(1M) command to become superuser. On a Trusted Solaris SSP console, an administrator who can assume the admin role first logs in as a user, then assumes the role.
To access the superuser remotely on a Solaris SSP, a user can rlogin(1) or telnet(1) to the SSP and then log in as the root user. A user can also CDE rlogin to the SSP, then CDE log in as the root user.
To access the admin role remotely on a Trusted Solaris SSP:
From another Trusted Solaris workstation, assume the admin role. In the admin role, rlogin(1) to the SSP.
From another Trusted Solaris workstation, perform a CDE remote login to the SSP. The SSP becomes the remote host on your local Trusted Solaris workstation. Then perform a CDE login to the SSP as a user who can assume the admin role, and assume the admin role.
The user ssp on Trusted Solaris SSP 3.3 runs with a profile shell (pfcsh(1))
and should not be changed to run with other shells. The home directory (/export/home/ssp) for the ssp user is created at installation as a multilevel directory (MLD). The ssp
user's setup files are installed in the ADMIN_LOW
SLD (single-level directory) and most are symbolically linked to SLDs at other labels.
Solaris and Trusted Solaris domains can be accessed from the SSP console or from other workstations.
A Solaris domain can be logged into from a netcon(1M) session. The Trusted Solaris environment does not support command line login, so a Trusted Solaris domain can not be logged into from a netcon session. The netcon window still receives the domain's console messages and can be used for OBP (OpenBoot PROM) commands.
To log in to a Trusted Solaris domain from an SSP console:
From a Solaris SSP console, you can rlogin(1) as a user to the Trusted Solaris domain. However, you cannot access the admin role on a Trusted Solaris domain from a Solaris SSP console.
From a user workspace on a Trusted Solaris SSP console, you can rlogin as a user to the Trusted Solaris domain. For performing administrative tasks, you assume an administrative role on the Trusted Solaris SSP console, and then rlogin to the domain as the same role.
You can rlogin to a Solaris domain from a Solaris workstation. You can rlogin(1) as a user to the Trusted Solaris domain from a Solaris workstation. You cannot perform administrative tasks in a Trusted Solaris domain from a Solaris workstation, because you do not have access to any administrative roles.
To log in to a Trusted Solaris domain from a Trusted Solaris workstation:
From a user workspace on a Trusted Solaris workstation, you can rlogin as a user to the Trusted Solaris domain. From an administrative role on a Trusted Solaris workstation (example: admin role), you can rlogin to the domain as the same role. This method enables access to a Trusted Solaris domain when the Trusted Solaris SSP is not available.
From another Trusted Solaris workstation, you can also perform a remote CDE login to the Trusted Solaris domain. The Trusted Solaris domain becomes the remote host on your local Trusted Solaris workstation. You can CDE login as a user to the domain and then assume roles. This method is useful when there is a spare Trusted Solaris workstation available. It is generally not desirable to do this using the Trusted Solaris SSP because it prevents the SSP from being used for SSP tasks.
Trusted Solaris 8 installation does not fully support the following options offered by Solaris 8 installation software:
SolarisTM Web Start. Trusted Solaris SSP 3.3 is installed from a CD-ROM.
Upgrade. You cannot upgrade from the Solaris operating environment to the Trusted Solaris 8 operating environment. You cannot upgrade to Trusted Solaris SSP 3.3 or to Trusted Solaris AP 2.3 from their Solaris versions.
SSP Backup. Like its Solaris version, Trusted Solaris SSP 3.3 can use the ssp_restore command to restore the SSP environment from a backup file created by the ssp_backup command on a Solaris SSP 3.2 or 3.3.
The Trusted Solaris 8 operating environment must be installed and configured on the SSP workstation before the Trusted Solaris SSP 3.3 software is installed on it.
Installing the Trusted Solaris 8 operating environment on the SSP is the same as installing Trusted Solaris 8 on a NIS+ client workstation or a NIS+ master server. Please see Trusted Solaris Installation and Configuration for details.
After Trusted Solaris SSP 3.3 is installed (see Chapter 3, Preparing for SSP 3.3 Installation and Chapter 4, Installing and Configuring the Trusted Solaris SSP 3.3), the Trusted Solaris version of AP 2.3 software can be installed, as described in Chapter 7, Trusted Solaris Alternate Pathing 2.3 on an E10000 Domain.
Installation of the Trusted Solaris operating environment on a domain can be done using the Trusted Solaris SSP as the net install server. See Chapter 5, Trusted Solaris 8 on an E10000 Domain for details.
After the Trusted Solaris operating environment is installed and configured on the domain, the Trusted Solaris version of AP 2.3 software can be installed. See Chapter 7, Trusted Solaris Alternate Pathing 2.3 on an E10000 Domain for details.
The following are examples of creating recommended Trusted Solaris 8 configurations on a Sun Enterprise 10000:
The examples are very high level. Each site should create a detailed plan that best fits the site and site security requirements.
On the SSPs, install the Trusted Solaris 8 operating environment and Trusted Solaris SSP 3.3.
Create each domain and install the Trusted Solaris 8 operating environment on each. If alternate pathing is required, install Trusted Solaris AP 2.3.
Back up the current SSP environment.
On the spare SSP, install the Trusted Solaris 8 operating environment and Trusted Solaris SSP 3.3. Restore the SSP environment on the spare SSP so that the spare is synchronized with the main SSP.
Switch the SSPs so that the spare SSP is now the main SSP. The main SSP is now running Trusted Solaris 8 and Trusted Solaris SSP 3.3
On the new spare SSP, install the Trusted Solaris 8 operating environment and Trusted Solaris SSP 3.3. Restore the spare SSP environment so it is synchronized with the main SSP.
To replace each Solaris domain with a Trusted Solaris domain, install the Trusted Solaris 8 operating environment on each domain. If alternate pathing is required, install Trusted Solaris AP 2.3.