| Solaris Security Toolkit 4.2 Reference Manual |    
|
| Solaris Security Toolkit 4.2 Reference Manual |
|
| C H A P T E R 4 |
|
Drivers |
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 secure.driver is the driver most commonly used as a starting point for developing a secured system configuration using the Solaris Security Toolkit software. The secure.driver disables all services, including network services, not required for the OS to function, with the exception of the Solaris Secure Shell (SSH) software. 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:
The core processing for hardening and audit runs is 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
These functionality files are all stored in the JASS_HOME_DIR/Drivers directory.
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 is described in detail in the following subsections.
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. Any scripts that are executed can take advantage of the common functions. The functionality files loaded during this task are the following:
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:
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.
In JumpStart mode, the driver.run script calls an internal subroutine called mount_filesystems. This routine mounts the following directories onto the JumpStart client:
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 stand-alone mode runs.
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_xx OS-version environment variable (for example, JASS_FILES_5_10 for Solaris 10 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 7, 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 match those on the target system.
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_xx OS-version environment variable (for example, JASS_SCRIPTS_5_10 for Solaris 10 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 7, 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:
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.
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.
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 disabled by the selected driver, 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 selected driver disables them, override the selected driver's configuration before executing the selected 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:
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 7 for detailed information about using variables, and see Customizing and Assigning Variables in Chapter 7.
|
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:
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 being customized.
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:
For more information, refer to "Configuring and Customizing the Solaris Security Toolkit Software", Chapter 1, Solaris Security Toolkit 4.2 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 7.
The following code example is an excerpt 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.
a. To change the contents of either of these files, modify 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 (_).
|
Note - In step c, you can also define and append other criteria in addition to the Solaris OS version. See the discussion in copy_files of all the various criteria you can use. |
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 10 OS would be specified
5. To add or remove scripts from a driver, modify the JASS_SCRIPTS variable.
For detailed information about this variable, see Chapter 7.
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 4-1 is an excerpt 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 4-1).
DIR="`/bin/dirname $0`" export DIR . ${DIR}/driver.init . ${DIR}/config.driver . ${DIR}/hardening.driver |
CODE EXAMPLE 4-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.
|
Note - CODE EXAMPLE 4-2 shows a sample of how you can nest drivers to provide various levels of functionality and coverage. The /etc/named.conf and configure-dns.fin references are for example purposes only. Those files are not supplied by default with the Solaris Security Toolkit software. |
7. When finished customizing your driver, save it in the Drivers directory.
8. Test the driver to ensure that it functions properly.
This section describes the following drivers, which are supplied by default in the Drivers directory:
In addition to these standard drivers, other drivers are also included with the Solaris Security Toolkit distribution. For a list of product-specific drivers, see Using Product-Specific Drivers.
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 4-3 shows an exempt 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 |
The config.driver performs several tasks:
1. Calls the driver.init file to initialize the Solaris Security Toolkit framework and to configure its runtime environment.
2. Sets both the JASS_FILES and JASS_SCRIPTS environment variables.
These variables define the actual configuration changes that are undertaken by this driver.
3. Calls the driver.run script. The driver.run script completes the installation of the files and executes all configuration-specific scripts.
In CODE EXAMPLE 4-3, 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 target system.
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:
In addition, the following scripts are listed in the hardening.driver, but are commented out:
For descriptions of these scripts, see Chapter 5.
The secure.driver is the driver most commonly included in the sample rules listed in the rules.SAMPLE file used 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 to configure the system and perform all the hardening tasks.
CODE EXAMPLE 4-4 lists the contents of the secure.driver.
DIR="`/bin/dirname $0`" export DIR . ${DIR}/driver.init . ${DIR}/config.driver . ${DIR}/hardening.driver |
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 4-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 might offer new and revised drivers.
|
Server systems[1] |
|
This driver is provided as an example, based on the secure.driver, to highlight what changes might be necessary to secure a system other than a Sun Fire high-end systems system controller. This script is a guide; therefore, you might need to customize it, depending on your environment. The differences between this and the secure.driver are as follows:
This driver provides a baseline configuration for hardening 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."
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."
|
Caution - After you have applied the suncluster3x-secure.driver, you need to add the fully qualified domain names of the cluster nodes to the hosts.allow-sunclusterfile. |
| Solaris Security Toolkit 4.2 Reference Manual | 819-1503-10 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.
To Customize a Driver