Solaris Security Toolkit 4.1 Reference Manual

This chapter provides reference information about using, adding, modifying, and removing drivers. This chapter describes the drivers used by the Solaris Security Toolkit software to harden, minimize, and audit Solaris OS systems. A series of drivers and related files make up a security profile.

The default driver (secure.driver) in the Solaris Security Toolkit software disables all services, including network services, not required for the OS to function. This action might not be appropriate for your environment. Evaluate which security modifications are required for your system, then make adjustments by using the information in this chapter and related chapters.

This chapter contains the following topics:

• Understanding Driver Functions and Processes
• Customizing Drivers
• Using Standard Drivers
• Using Product-Specific Drivers

---

Understanding Driver Functions and Processes

The core processing for hardening and audit runs are defined by the functions in the driver.run script. During these operations, the driver in use calls the driver.run script after the security profile is configured. That is, after the driver.init file is called and the JASS_FILES and JASS_SCRIPTS environment variables are defined, the driver calls the driver.run script functions. This script processes each of the entries contained in the JASS_FILES and JASS_SCRIPTS environment variables in both the hardening and audit operations.

The high-level processing flow of this script is as follows:

1. Load functionality (.funcs) files

2. Perform basic checks

3. Load user functionality overrides

4. Mount file systems to JumpStart client (JumpStart mode only)

5. Copy or audit files specified by the JASS_FILES environment variable (optional)

6. Execute scripts specified by the JASS_SCRIPTS environment variable (optional)

7. Compute total score for the run (audit operation only)

8. Unmount file systems from JumpStart client (JumpStart mode only)

Each of these functions are described in detail in the following subsections.

Load Functionality Files

The first task of the driver.run script is to load the functionality files. Loading these files at this stage allows the driver.run script to take advantage of the functionality in each of the files. Also, any scripts that are executed can take advantage of the common functions. The functionality files loaded during this task are the following:

• common_misc.funcs
• common_log.funcs
• driver.funcs
• audit_public.funcs

Perform Basic Checks

The Solaris Security Toolkit software checks to determine if core environment variables are set. This check ensures that the software is properly executed. If any of the checks fail, the software reports an error and exits. The software checks to ensure the following:

• The JASS_OS_REVISION environment variable is defined. If this environment variable was not defined, it is possible that either the driver.init script was not called or the environment variable was improperly modified.
• For JumpStart mode, the JASS_PACKAGE_MOUNT environment variable is defined. If this environment variable is not properly defined, then the software might not be able to locate the Packages directory during a JumpStart installation.
• For JumpStart mode, the JASS_PATCH_MOUNT environment variable is defined. If this environment variable is not properly defined, then the software might not be able to locate the Patches directory during a JumpStart installation.

Load User Functionality Overrides

Before continuing to process the current profile, the Solaris Security Toolkit software loads the user.run file, if it exists. This file stores all site or organization-specific functions, including those that override any Solaris Security Toolkit software default functions. By default, this file does not exist and must be manually created by the user if this functionality is needed.

This capability allows you to extend or enhance the functionality of the software by implementing new functions or customizing existing ones to better suit your environment. This file is similar to the user.init, except that this file is for functions, whereas the user.init file is for environment variables.

Mount File Systems to JumpStart Client

In JumpStart mode, the driver.run script calls an internal subroutine called mount_filesystems. This routine mounts the following directories onto the JumpStart client:

• JASS_PACKAGE_MOUNT, which is mounted onto JASS_PACKAGE_DIR
• JASS_PATCH_MOUNT, which is mounted onto JASS_PATCH_DIR

If other file system mount points are required, use the user.run script to implement them. This routine is JumpStart mode specific and is not executed during standalone mode runs.

Copy or Audit Files

After the software establishes its foundation by loading common functions, initializing environment variables, and mounting file systems (if needed), it is ready to begin its work. Whether performing a hardening or audit operation, the software assembles a complete list of file templates to be copied to or verified on a target system. The software does this task by concatenating the entries found in the JASS_FILES global environment variable with entries found in the JASS_FILES_x_x OS-version environment variable (for example, JASS_FILES_5_8 for Solaris 8 OS). Note that both the global and OS environment variables are optional, and either or none can be defined. The combined list is stored in the JASS_FILES environment variable. For more information about this variable, see Chapter 6, JASS_FILES.

If the resulting list has at least one entry, the software prepends the JASS_SCRIPTS list with a special finish script called install-templates.fin. In hardening runs, this script takes the contents of the resulting list and copies it to a target system before other finish scripts are run. In audit runs, the install-templates.aud script verifies that the files were successfully copied to a target system.

Execute Scripts

The software executes the scripts defined by the JASS_SCRIPTS environment variable. Whether performing a hardening or audit operation, the software assembles a complete list of file templates to be copied to or verified on a target system. The software does this task by concatenating the entries found in the JASS_SCRIPTS global environment variable with entries found in the JASS_SCRIPTS_x_x OS-version environment variable (for example, JASS_SCRIPTS_5_8 for Solaris 8 OS). Note that both the global and OS environment variables are optional, and either or none can be defined. The combined list is stored in the JASS_SCRIPTS environment variable. For more information about this variable, see Chapter 6, JASS_FINISH_DIR.

In hardening runs, each finish script is executed in turn. The finish scripts are stored in the JASS_FINISH_DIR directory.

In audit runs, some additional processing must be done first. Before a script defined by JASS_SCRIPTS executes, it must first be transformed from its finish script name to its audit script counterpart. The Solaris Security Toolkit software automatically changes the file name extension from .fin to .aud. In addition, the software expects the audit script to be in the JASS_AUDIT_DIR. After this alteration is made, the software executes each audit script in turn.

The output of the scripts is processed in one or more of the following ways:

• Logged to the file specified by the jass-execute -o option. If a file is not specified, the output is directed to standard output. This option is only available in standalone mode.
• Logged into the /var/sadm/system/logs/finish.log file on the JumpStart client during JumpStart installations. The /var/sadm/system/logs/finish.log is the standard log file used by any JumpStart command run on the client. This option is only available in JumpStart mode.
• Logged to the file JASS_REPOSITORY/timestamp/jass-install-log.txt or jass-audit-log.txt. The timestamp is a fully qualified time parameter of the form YYYYMMDDHHMMSS. This value is constant for each run of the Solaris Security Toolkit software and represents the time at which the run was started. For example, a run started at 1:30 p.m. on April 1, 2003 would be represented by the value 20030401013000. These log files are generated during every run. In hardening runs, the software creates the jass-install-log.txt file. In audit runs, the software creates the jass-audit-log.txt file. Do not modify the contents of these files.

Compute Total Score for the Run

In audit runs, after all of operations are completed for a driver, the software calculates the driver's total score. This score denotes the status of the driver and is part of the grand total if multiple drivers are called. If only one driver is used, then this total and the grand total are the same value. The score is zero if all of the checks passed. If any checks fail, the score is a number representing how many checks or subchecks fail.

Unmount File Systems From JumpStart Client

When operating in JumpStart mode, after all operations are completed for a driver, the software unmounts those file systems mounted during the process Mount File Systems to JumpStart Client. This functionality typically marks the end of a JumpStart client's installation. At this point, control returns to the calling driver. The driver can either exit and end the run or it can call other drivers and start new processing.

---

Customizing Drivers

Modifying the Solaris Security Toolkit drivers is one of the tasks done most often because each organization's policies, standards, and application requirements differ, even if only slightly. For this reason, the Solaris Security Toolkit software supports the ability to customize tasks undertaken by a driver.

If your system or application requires some of the services and daemons that are automatically disabled by the Solaris Security Toolkit software, or if you want to enable any of the inactive scripts, do so before executing the Solaris Security Toolkit software.

Similarly, if there are services that must remain enabled, and the Solaris Security Toolkit software automatically disables them, override the defaults before executing the applicable driver in the Solaris Security Toolkit software. Review the configuration of the software and make all necessary customization before changing the system's configuration. This approach is more effective than discovering that changes must be reversed and reapplied using a different configuration.

There are two primary ways in which services can be disabled using the Solaris Security Toolkit software. The first way involves modifying drivers to comment out or remove any finish scripts defined by the JASS_SCRIPTS parameter that should not be run. This approach is one of the most common ways to customize drivers.

For example, if your environment requires NFS-based services, you can leave them enabled. Comment out the disable-nfs-server.fin and disable-rpc.fin scripts by prepending a # sign before them in your local copy of the hardening.driver. Alternatively, you can remove them entirely from the file. As a general rule, it is recommended that any entries that are commented out or removed should be documented in the file header, including information such as:

• Name of the script that is disabled
• Name of the person who disabled the script
• Timestamp indicating when the change was made
• Brief description for why this change was necessary

Including this information can be very helpful in maintaining drivers over time, particularly when they must be updated for newer versions of the software.

The other method for disabling services is to customize environment variables. This approach is typically done in either the driver or the user.init file. Make changes in the user.init file only if the changes are global in nature and used by all of the drivers. Otherwise, localize the change to just the drivers requiring the change.

For example, to enable or disable services started by the inetd daemon, use the JASS_SVCS_ENABLE and JASS_SVCS_DISABLE environment variables. See Chapter 6 for detailed information about using variables. Also, see Customizing and Assigning Variables in Chapter 6.

Use the following steps to customize a driver so that newer versions of the original files do not overwrite your customized versions. Furthermore, this step should be taken to help ensure that customized files are not accidentally deleted during software upgrades or removal.

1. Copy the driver and any related files that you want to customize.

For example, if you want to create a secure.driver specific to your organization, copy the following drivers located in the Drivers directory:

• secure.driver
• config.driver
• hardening.driver

The config.driver and hardening.driver must be copied because they are called by the secure.driver. If the driver you are customizing does not call or use other drivers, copy only the driver.

2. Rename the copies with names that identify the files as custom drivers.

For example, using your company's name, your files would look like:

• abccorp-secure.driver
• abccorp-config.driver
• abccorp-hardening.driver

For more information, refer to "Configuring and Customizing the Solaris Security Toolkit Software", Chapter 1, Solaris Security Toolkit 4.1 Administration Guide.

3. Modify your custom prefix-secure.driver to call the new related prefix-config.driver and prefix-hardening.driver files accordingly.

This step is necessary to prevent the new prefix-secure.driver from calling the original config.driver and hardening.driver. This step is not necessary if the drivers being customized do not call or use other drivers.

4. To copy, add, or remove files from a driver, modify the JASS_FILES environment variable.

For detailed information about this variable, see Chapter 6.

The following code example is taken from the Drivers/config.driver file. This security profile performs basic configuration tasks on a platform. The security profile provides clear samples of how both file templates and finish scripts are used.

In the following example, the driver is configured to copy the /.cshrc and /.profile files from the JASS_HOME_DIR/Files/ directory onto the target platform when the driver.run function is called.

JASS_FILES="/.cshrc/.profile"

a. To change the contents of either of these files, modify the copies of the files located in the JASS_HOME_DIR/Files/ directory.

b. If you only need to add or remove file templates, adjust the JASS_FILES variable accordingly.

c. If you want to define the Solaris OS version, append the major and minor operating system version to the end of the JASS_FILES variable, separated by underscores.

The Solaris Security Toolkit software supports operating system-version specific file lists. These file lists are added to the contents of the general file list only when the Solaris Security Toolkit software is run on a defined version of the Solaris OS. For example, Solaris 9 OS would be specified

JASS_FILES_5_9

5. To add or remove scripts from a driver, modify the JASS_SCRIPTS variable.

For detailed information about this variable, see Chapter 6.

6. To call other drivers, create a nested or hierarchical security profile.

This technique is often useful when attempting to enforce standards across the majority of platforms while still providing for platform or application-specific differences.

CODE EXAMPLE 3-1 comes from the secure.driver file. This file is used as a wrapper to call both configuration and hardening drivers that, in this case, implement the actual functionality of the security profile. Although this is often the model used, it should be noted that this need not be the case. In fact, each driver supports the JASS_FILES and JASS_SCRIPTS convention, even if it is not always used (as is the case in CODE EXAMPLE 3-1).

DIR="`/bin/dirname $0`"

export DIR

. ${DIR}/driver.init

. ${DIR}/config.driver

. ${DIR}/hardening.driver

CODE EXAMPLE 3-2 illustrates a slightly more complex configuration where the driver not only calls other foundational drivers, but also implements its own functionality. In this case, this new security profile installs the /etc/named.conf file and runs the configure-dns.fin script after it runs the config.driver and hardening.driver drivers.

DIR="`/bin/dirname $0`"

export DIR

. ${DIR}/driver.init

. ${DIR}/config.driver

. ${DIR}//hardening.driver

JASS_FILES="

/etc/named.conf

"

JASS_SCRIPTS="

configure-dns.fin

"

. ${DIR}/driver.run

7. When finished customizing your driver, save it in the Drivers directory.

8. Test the driver to ensure that it functions properly.

---

Using Standard Drivers

This section describes the following drivers, which are supplied by default in the Drivers directory:

• config.driver
• hardening.driver
• secure.driver
• undo.driver

In addition to these standard drivers, product-specific drivers are also included with the Solaris Security Toolkit distribution. For a list of product-specific drivers, see Using Product-Specific Drivers.

config.driver

This driver is called by the secure.driver and is responsible for implementing tasks associated with that driver set. By grouping related functions into a single driver, you can create common functions and use them as building blocks to assemble more complex configurations. In the following example, machines with different security requirements can share the same base Solaris OS configuration driver because similar tasks are separated into their own driver.

CODE EXAMPLE 3-3 shows sample output from the config.driver.

DIR="`/bin/dirname $0`"

export DIR

. ${DIR}/driver.init

JASS_FILES="

/.cshrc

"

JASS_SCRIPTS="

set-root-password.fin

set-term-type.fin

"

. ${DIR}/driver.run

This driver performs several tasks. It calls the driver.init to initialize the Solaris Security Toolkit framework and to configure its runtime environment. Then, it sets both the JASS_FILES and JASS_SCRIPTS environment variables. These variables define the actual configuration changes that are undertaken by this driver. After these variables are set, the driver.run script is called. The driver.run script completes the installation of the files and executes all configuration-specific scripts.

In the example, the .cshrc file contained in JASS_HOME_DIR/Files directory is copied to /.cshrc and the finish scripts (set-root-password.fin and set-term-type.fin) are run on the system.

hardening.driver

Most of the security-specific scripts included in the Solaris Security Toolkit software are listed in the hardening.driver. This driver builds upon those changes by implementing additional security enhancements that are not included in the hardening.driver. This driver, similar to the config.driver, defines scripts to be run by the driver.run script.

The following scripts are listed in this driver:

• disable-ab2.fin
• disable-apache.fin
• disable-asppp.fin
• disable-automount.fin
• disable-dhcpd.fin
• disable-directory.fin
• disable-dmi.fin
• disable-dtlogin.fin
• disable-ipv6.fin
• disable-kdc.fin
• disable-keyserv-uid-nobody.fin
• disable-ldap-client.fin
• disable-lp.fin
• disable-mipagent.fin
• disable-named.fin
• disable-nfs-client.fin
• disable-nfs-server.fin
• disable-nscd-caching.fin
• disable-ppp.fin
• disable-preserve.fin
• disable-power-mgmt.fin
• disable-remote-root-login.fin
• disable-rhosts.fin
• disable-rpc.fin
• disable-samba.fin
• disable-sendmail.fin
• disable-ssh-root-login.fin
• disable-slp.fin
• disable-sma.fin
• disable-snmp.fin
• disable-spc.fin
• disable-syslogd-listen.fin
• disable-system-accounts.fin
• disable-uucp.fin
• disable-vold.fin
• disable-xserver-listen.fin
• disable-wbem.fin
• enable-coreadm.fin
• enable-ftpaccess.fin
• enable-ftp-syslog.fin
• enable-inetd-syslog.fin
• enable-priv-nfs-ports.fin
• enable-process-accounting.fin
• enable-rfc1948.fin
• enable-stack-protection.fin
• install-at-allow.fin
• install-ftpusers.fin
• install-loginlog.fin
• install-newaliases.fin
• install-sadmind-options.fin
• install-security-mode.fin
• install-shells.fin
• install-sulog.fin
• remove-unneeded-accounts.fin
• set-banner-dtlogin.fin
• set-banner-ftpd.fin
• set-banner-sendmail.fin
• set-banner-sshd.fin
• set-banner-telnetd.fin
• set-ftpd-umask.fin
• set-login-retries.fin
• set-power-restrictions.fin
• set-root-group.fin
• set-rmmount-nosuid.fin
• set-sys-suspend-restrictions.fin
• set-system-umask.fin
• set-tmpfs-limit.fin
• set-user-password-reqs.fin
• set-user-umask.fin
• update-at-deny.fin
• update-cron-allow.fin
• update-cron-deny.fin
• update-cron-log-size.fin
• update-inetd-conf.fin
• install-md5.fin
• install-fix-modes.fin

In addition, the following scripts are listed in the hardening.driver, but are commented out by default:

• disable-autoinst.fin
• disable-keyboard-abort.fin
• disable-picld.fin
• enable-tcpwrappers.fin
• enable-bsm.fin
• install-strong-permissions.fin

For descriptions of these scripts, see Chapter 4.

secure.driver

The secure.driver is the default driver used in the rules file for client installation. This driver is a ready-to-use driver that implements all the hardening functionality in the Solaris Security Toolkit software. This driver performs the initialization tasks required, then calls the config.driver and hardening.driver drivers to configure the system and perform all the hardening tasks.

CODE EXAMPLE 3-4 lists the contents of the secure.driver.

DIR="`/bin/dirname $0`"

export DIR

. ${DIR}/driver.init

. ${DIR}/config.driver

. ${DIR}/hardening.driver

undo.driver

Caution - Never call or modify this driver directly.

This driver provides the undo functionality during an undo run. This driver is called when you invoke the jass-execute command with the -u option. This driver is quite straightforward and contains the contents listed in CODE EXAMPLE 3-5.

DIR="`/bin/dirname $0`"

export DIR

. ${DIR}/driver.init

. ${DIR}/undo.run

When called by ./jass-execute -u, this driver initializes itself much the same way as any other driver by calling driver.init, then passing control to a different driver, undo.driver in this case.

---

Using Product-Specific Drivers

This section lists product-specific drivers, which are used to harden specific Sun products or configurations. These drivers are included with the Solaris Security Toolkit in the Drivers directory. TABLE 3-1 lists product specific drivers.

New drivers are released periodically to harden new and updated Sun products. Newer versions of the Solaris Security Toolkit software may offer new and revised drivers.

desktop-secure.driver

This driver is provided as an example, based on the secure.driver, to highlight what changes may be necessary to secure a desktop system. This script is a guide; therefore, you may need to customize it, depending on your environment. The differences between this and the secure.driver are as follows:

• The following inetd services are not disabled: Telnet, FTP, dtspc (CDE subprocess control service), rstatd (Kernel statistics server), and rpc.smserverd (used for volume management in Solaris OS 9).
• The following file templates are not used: /etc/dt/config/Xaccess, and /etc/syslog.conf.
• The following finish scripts are not used: disable-dtlogin.fin, disable-automount.fin, disable-lp.fin, disable-nfs-client.fin, disable-rpc.fin, disable-vold.fin, and disable-xserver-listen.fin.

install-Sun_ONE-WS.driver

Applicable only to JumpStart mode, this driver calls the minimize-Sun_ONE-WS.fin script so that the Solaris Security Toolkit software can install the Sun Java^TM System Web Server (formerly Sun ONE Web Server and before that iPlanet^TM Web Server) software. The script removes all Solaris OS packages not required to successfully install and run the Sun Java System Web Server software. In addition, this driver calls the hardening.driver to harden the platform after it is minimized.

CODE EXAMPLE 3-6 lists the contents of the install-Sun_ONE-WS.driver.

DIR="`/bin/dirname $0`"

export DIR

. ${DIR}/driver.init

. ${DIR}/config.driver

JASS_SCRIPTS="

minimize-Sun_ONE-WS.fin

install-Sun_ONE-WS.fin

"

. ${DIR}/driver.run

. ${DIR}/hardening.driver

If you build a JumpStart client using this driver, then you must include this driver in the rules file list. This driver performs all the actions specified by the config.driver and hardening.driver, in addition to the functionality in the minimize-Sun_ONE-WS.fin and install-Sun_ONE-WS.fin scripts.

For more information about this driver, refer to the Sun BluePrints OnLine article titled "Minimizing the Solaris Operating Environment."

jumpstart-secure.driver

This driver is provided as an example, based on the secure.driver, to highlight what changes might be necessary to secure a JumpStart server. This driver is a guide, and you might need to customize it, depending on your environment. The differences between this and the secure.driver are as follows:

• Trivial FTP (tftp) inetd service is not disabled
• Following finish scripts are not used: disable-nfs-server.fin and disable-rpc.fin

suncluster3x-secure.driver

This driver provides a baseline configuration for hardening SunPlex, formerly Sun Cluster 3.x, software releases. You can modify the driver to remove Solaris OS functionality being disabled; however, do not alter enabled services that are required for the Sun Cluster software to work properly. For more information, refer to the Sun BluePrints OnLine article titled "Securing the Sun Cluster 3.x Software."

sunfire_mf_msp-secure.driver

This driver is for hardening the midframe service processor (MSP) when building secured Sun Fire midframe environments. This driver automates and simplifies building a secure MSP, but one that still has all of the required services enabled. For more information, refer to the Sun BluePrints OnLine article titled "Securing the Sun Fire Midframe System Controller."

starfire_ssp-secure.driver

This driver is for creating supported and hardened Sun Enterprise 10000 system service processors (SSP). It is strongly recommended that the SSPs always be hardened, due to their ability to impact the reliability, availability, and serviceability of Sun Enterprise 10000 systems. For more information, refer to the Sun BluePrints OnLine article titled "Securing the Sun Enterprise 10000 System Service Processors."

sunfire_15k_domain-secure.driver

This driver provides a baseline for developing hardened Sun Fire High-End Systems domains. The configuration implemented by this driver disables all services not required by Sun Fire High-End Systems, while enabling optional Solaris OS security features disabled in default configurations. For more information, refer to the Sun BluePrints OnLine article titled "Securing Sun Fire 12K and 15K Domains."

sunfire_15k_sc-secure.driver

This driver is the only supported mechanism by which Sun Fire High-End Systems system controllers (SC) can be secured. All services not required by the SC are disabled by this driver. If some of the disabled services are required, you can modify the driver to not disable them. For more information, refer to the Sun BluePrints OnLine article titled "Securing the Sun Fire 12K and 15K System Controllers."

^{1 (TableFootnote) Sun Java System servers were formerly referred to as Sun ONE servers and before that as iPlanet servers.}

Solaris Security Toolkit 4.1 Reference Manual

817-7750-10

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