C H A P T E R 1 |
Introduction to Solaris 10 Operating System Support |
One of the main purposes of the Solaris Security Toolkit 4.2 software release is to provide support for the Solaris 10 Operating System. The Solaris Security Toolkit 4.2 software provides support for new Solaris 10 OS security features, such as the Service Management Facility (SMF), TCP Wrappers, IP Filter, and other features. Refer to the Solaris Security Toolkit 4.2 Release Notes for a complete list of new features.
Using the Solaris Security Toolkit 4.2 software, you can harden and audit the security of systems in a similar manner as earlier versions. You can also use this release of software either in JumpStart or standalone mode, as in earlier versions.
The Practical Extraction and Report Language (Perl) is delivered with the Solaris 10 OS. If you are creating scripts for use with the Solaris 10 OS, you can use Perl in your scripts, even in JumpStart mode. Versions of the Solaris OS earlier than 10 might not have Perl available during JumpStart or included in the Solaris OS distribution. Ensure that Perl is available in your target environment before you write a script which requires it. Many security-conscious users do remove Perl from their systems, so you also should be aware of that possibility.
The Solaris Security Toolkit attempts to use Perl if is installed on the system during the audit performed by the set-flexible-crypt.aud script (see set-flexible-crypt.aud). If Perl is not installed on the system, the script issues an error.
Some of the services under the Internet services daemon (inetd) control that you might want to put in a list to enable or disable are converted to the Service Management Facility and use Fault Management Resource Identifiers (FMRIs), and some services under inetd control are not converted.
Note - The lists of SMF-ready services are valid only for the Solaris 10 Operating System. |
If you are using the Solaris 10 Operating System, the JASS_SVCS_DISABLE script disables all services listed on the JASS_SVCS_DISABLE list if they are in the inetd.conf file. Therefore, if a service was valid for the Solaris 9 Operating System under inetd, but no longer uses the inetd.conf file for the Solaris 10 Operating System, modifying the JASS_SVCS_DISABLE environment variable makes no changes to that service.
The Solaris Security Toolkit issues a warning message if either the JASS_SVCS_ENABLE or JASS_SVCS_DISABLE environment variable contains either an FMRI or an inetd service name which does not exist on the system.
TABLE 1-1 lists the Solaris Security Toolkit scripts that use the SMF-ready services interface, their Fault Management Resource Identifiers (FMRIs), and the start or stop scripts used for the Solaris 9 OS.
disable-apache2[1] |
||
svc:/application/print/server:
|
||
svc:/network/nfs/client:default |
||
TABLE 1-2 lists the Solaris Security Toolkit scripts that are not SMF ready, but that SMF recognizes as legacy services. Although the legacy services can be represented in FMRI format, SMF does not have the ability to enable or disable them.
Following are new scripts for the Solaris Security Toolkit 4.2 release:
The functions of finish (.fin) scripts are explained in Chapter 5, and the functions of audit (.aud) scripts are explained in Chapter 6.
TABLE 1-3 lists the Solaris Security Toolkit Scripts that are not used when you are hardening the Solaris 10 Operating System.
The following environment variables are not used for the Solaris 10 Operating System:
The Solaris Security Toolkit 4.2 software can be used to harden a zone, or Sun Network One (N1) grid container, for systems using the Solaris 10 OS. All Solaris Security Toolkit profiles (hardening, audit, and undo) function in Solaris 10 zones in the same manner as in non-zoned systems for the most part. Any differences are noted in this section.
If the global zone has been hardened before the non-global zone (NGZ) is installed, certain modifications made by the Solaris Security Toolkit 4.2 software are carried into the new zone, but many others are not. To ensure that a newly created zone is properly secured, the Solaris Security Toolkit 4.2 software should be applied in both hardening and audit modes immediately after the zone's installation. Once a non-global zone is installed, hardening and unhardening in the global zone does not effect the NGZ, and vice versa.
If your Solaris Security Toolkit 4.2 installation is in the standard /opt/SUNWjass directory, you can harden a zone by using the Solaris 10 OS zlogin(1) command to log in to, or enter, that zone to run the Solaris Security Toolkit.
# zlogin myzone /opt/SUNWjass/bin/jass-execute -d my.driver |
The variable myzone is your non-global zone, and the variable my.driver is the name of the driver you are using.
Some of the Solaris Security Toolkit scripts are not relevant to a non-global zone; for example, those that modify kernel parameters using /etc/system. When these scripts are run in a non-global zone, the scripts log the fact that they are not required for a non-global zone as a [NOTE].
If you are writing your own script, you might want to use the logNotGlobalZone function (see logNotGlobalZone) to issue such a message in a standard way. To test whether or not you are in a non-global zone in a Solaris Security Toolkit script, you can check the Solaris Security Toolkit 4.2 environment variable JASS_ZONE_NAME to see if it contains global. This variable is set to global in OS versions prior to the Solaris 10 OS. For more information about the variable, see JASS_ZONE_NAME.
Running processes, installed software, and the configurations of non-global zones are audited separately from those of the global zone. For example, an audit of an NGZ, which detected an unauthorized process running, would trigger an NGZ audit failure, not a global zone audit failure. Similarly, when a global zone is audited, any security violations detected would generate global zone security violations, not NGZ violations.
The only overlap between a global and non-global zone audit occurs during a BART review of the global zone. File systems of the NGZ are mounted on the global zone and might be reviewed by the BART manifest files included in the Solaris Security Toolkit. When reviewing these NGZ file systems from the global zone, security violations relevant to the NGZ might be reported on the global zone. To avoid this situation, ensure that any NGZ file systems mounted on the global zone are excluded from the BART manifest file.
Toolkit scripts that are not to be run in a zone because of insufficient privileges for operation, check to see if they are in the global zone using the environment variable JASS_ZONE_NAME (see JASS_ZONE_NAME). If the Solaris Security Toolkit scripts are not running in the global zone, the scripts log that information with the logNotGlobalZone function and finish.
TABLE 1-4 lists the Finish and Audit scripts that are zone aware.
Some Solaris Security Toolkit scripts that are zone aware, such as enable-bsm.fin, might require actions to be taken in the global zone prior to their full use in a non-global zone. If you run such scripts without taking these actions, you are prompted and given instructions to take the required actions to make full use of these capabilities. In other words, some actions require a kernel module to work. In this case, you need to load the module from the global zone, and then you can use it in the non-global zone. Until you do that, the actions are not performed.
In the Solaris 10 Operating System, there are services which depend on rpcbind such as the Fault Manager Daemon (FMD), Network Information Services (NIS), the Network File System (NFS), and window managers, such as Common Desktop Environment (CDE) and GNU Network Object Model Environment (GNOME). The Solaris Security Toolkit 4.2 software either disables or enables rpcbind based on the driver as follows:
You might need to configure rpcbind to start manually, depending on your system's configuration. Refer to the Solaris 10 OS Administration documentation for details on how to use SMF.
rpcbind in the Solaris 10 OS uses TCP Wrappers and the uses of both are closely related. See Using TCP Wrappers for details on how each of the drivers auto-configure TCP Wrappers.
To Enable rpcbind |
2. Verify that rpcbind is running by using the pgrep command.
Use the following form of the pgrep command for systems running the Solaris 10 OS where you have a global zone with child zones, so that you do not receive child zone processes.
If you receive a process-id you know that rpcbind is running.
3. Copy and rename the secure.driver and hardening.driver to new-secure.driver and new-hardening.driver.
4. Edit new-secure.driver to replace the reference to hardening.driver with new-hardening.driver.
5. Comment out the disable-rpc.fin script from new-hardening.driver.
6. Re-run hardening with your customized copy drivers by running the Solaris Security Toolkit with new-secure.driver.
For the Solaris 10 OS, the following TCP Wrappers configurations are used for the following drivers. The configuration information is in the /etc/hosts.allow and /etc/hosts.deny files.
Note - The arguments for these configurations are case-sensitive. For example, in CODE EXAMPLE 1-2, LOCAL and ALL must be entered in all capital letters, and localhost must be entered in lower-case letters. |
There is a change in the sequence in which driver-specific environment variables are set.
In previous versions of Solaris Security Toolkit, the sequence in which environment variables were set was as follows:
3. <driver-name>.driver (after driver.init)
4. framework variables (driver files)
5. finish script variable definitions
In Solaris Security Toolkit 4.2 software, the sequence in which environment variables are set is as follows:
In step d, some variables could be set before step i or after step iii.
Note - In spite of a change in sequence in which driver-specific variables are set in Solaris Security Toolkit 4.2, your ability to use user.init to override is unchanged from previous versions. |