Solaris Security Toolkit 4.2 Reference Manual

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.

---

Using Perl With Solaris Security Toolkit 4.2 Software

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.

---

SMF and Legacy Services on Solaris 10 OS

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.

• SMF-Ready Services - If you want to create lists of SMF-ready services under inetd control to enable or disable, use JASS_SVCS_ENABLE or JASS_SVCS_DISABLE. The JASS_SVCS_DISABLE script disables all services on the list that are SMF ready and that are installed on the system. TABLE 1-1 lists those Solaris Security Toolkit scripts that are SMF ready.

• Legacy Services - If you want to create lists of legacy, or unconverted, services under inetd control to enable or disable, you can use JASS_SVCS_ENABLE or JASS_SVCS_DISABLE in the same manner you have been using them in earlier versions of the toolkit. TABLE 1-2 lists those Solaris Security Toolkit scripts that are not converted and, therefore, SMF recognizes as legacy services. See JASS_SVCS_DISABLE and JASS_SVCS_ENABLE for more information.

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.

---

Scripts That Use the SMF-Ready Services Interface

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.

---

Scripts That SMF Recognizes as Legacy Services

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.

---

New Scripts for Solaris Security Toolkit 4.2 Release

Following are new scripts for the Solaris Security Toolkit 4.2 release:

• disable-apache2.{fin|aud}
• disable-appserv.{fin|aud}
• disable-IIim.{fin|aud}
• disable-routing.{fin|aud}
• enable-account-lockout.{fin|aud}
• enable-bart.{fin|aud}
• enable-ipfilter.{fin|aud}
• enable-password-history.{fin|aud}
• set-root-home-dir.{fin|aud}
• set-strict-password-checks.{fin|aud}

The functions of finish (.fin) scripts are explained in Chapter 5, and the functions of audit (.aud) scripts are explained in Chapter 6.

---

Scripts Not Used for Solaris 10

TABLE 1-3 lists the Solaris Security Toolkit Scripts that are not used when you are hardening the Solaris 10 Operating System.

---

Environment Variables Not Used for Solaris 10

The following environment variables are not used for the Solaris 10 Operating System:

• JASS_ISA_CAPABILITY (removed from Solaris Security Toolkit 4.2 software)
• JASS_DISABLE_MODE

---

Using Solaris 10 OS Zones

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.

Sequence Matters in Hardening Global and Non-Global Zones

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.

Harden a Non-Global Zone From Within That Zone

Caution - Because of security risks, you should neveraccess a non-global zone file system from outsidethat zone. A path that is not dangerous in a non-global zone can be dangerous in the global zone. For example, a non-global zone administrator can link the /etc/shadowfile to the ../../../shadowfile. Inside the non-global zone, this is harmless, but modifications to the file from the global zone, using the path /opt/testzone/etc/shadow, would edit the global zone's /etc/passwdfile. Again, a non-global zone should neverbe hardened, undone, cleaned, or even audited unless you are logged into that zone.

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 Scripts Are Not Relevant to Non-Global Zones

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.

Audits of Non-Global Zones Are Separate and Distinct From Audits of Global Zones

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.

Zone-Aware Finish and Audit Scripts

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 Zone-Aware Scripts Require Action Before Use in Non-Global Zones

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.

---

rpcbind Disabled or Enabled Based on Drivers

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:

• secure.driver: rpcbind disabled by default
• server-secure.driver: rpcbind enabled by default
• suncluster3x-secure.driver: rpcbind enabled by default
• sunfire_15k_sc-secure.driver: rpcbind disabled by default

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.

1. Unharden the system.

2. Verify that rpcbind is running by using the pgrep command.

# pgrep rpcbind

process-id

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.

# pgrep -z zone-name rpcbind

process-id

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.

7. Reboot the system.

Caution - After enabling the rpcbindservice, additional services may be started automatically and their corresponding ports opened. The Solaris Security Toolkit audit flags these additional services as failures.

---

Using TCP Wrappers

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.

TCP Wrappers Configuration for secure.driver

secure.driver: tcpwrappers enabled by default with the following:

        hosts.allow

               sshd:     LOCAL

               sendmail: localhost

        hosts.deny

                ALL:       ALL

                # rpcbind: ALL

TCP Wrappers Configuration for
server-secure.driver

server-secure.driver: tcpwrappers enabled by default with the following:

        hosts.allow

                ALL: localhost

               sshd: ALL

        hosts.deny

                ALL: ALL

TCP Wrappers Configuration for
suncluster3x-secure.driver

suncluster3x-secure.driver: tcpwrappers enabled by default with the following:

        hosts.allow

                <need to allow other cluster members access>

                ALL: localhost

               sshd: ALL

        hosts.deny

                ALL: ALL

        NOTE: need to warn if not configured properly by adding         entries to hosts.allow

TCP Wrappers Configuration for
sunfire_15k_sc-secure.driver

sunfire_15k_sc-secure.driver: tcpwrappers enabled by default with the following:

        hosts.allow

                <need to allow other SC sshd access>

                sendmail: localhost

        hosts.deny

                ALL: ALL

        NOTE: need to warn if not configured properly by adding         entries to hosts.allow

---

Defining Environment Variables

There is a change in the sequence in which driver-specific environment variables are set.

Earlier Solaris Security Toolkit Versions

In previous versions of Solaris Security Toolkit, the sequence in which environment variables were set was as follows:

1. <driver-name>.driver

2. driver.init

a. user.init

b. finish.init

3. <driver-name>.driver (after driver.init)

4. framework variables (driver files)

5. finish script variable definitions

Solaris Security Toolkit 4.2

In Solaris Security Toolkit 4.2 software, the sequence in which environment variables are set is as follows:

1. jass-execute calls

a. driver-init

b. user-init

c. finish.init

d. *secure*

i. driver.init

ii. user.init

iii. finish.init

iv. *config*

v. *hardening*

In step d, some variables could be set before step i or after step iii.

^{1 (TableFootnote) Solaris 10 only}

Solaris Security Toolkit 4.2 Reference Manual

819-1503-10

Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.