C H A P T E R  1

Introduction

This chapter describes the design and purpose of the Solaris Security Toolkit software. It covers the key components, features, benefits, and supported platforms. This chapter provides guidelines for maintaining version control of modifications and deployments, and it sets forth important guidelines for customizing the Solaris Security Toolkit software.

This chapter contains the following topics:


Securing Systems With the Solaris Security Toolkit Software

The Solaris Security Toolkit software, informally known as the JumpStart Architecture and Security Scripts (JASS) toolkit, provides an automated, extensible, and scalable mechanism to build and maintain secure Solaris OS systems. Using the Solaris Security Toolkit software, you can harden and audit the security of systems.

Following are terms used in this guide that are important to understand:



Note - The term audit describes the Solaris Security Toolkit software's automated process of validating a security posture by comparing it with a predefined security profile. The use of this term in this publication does not represent a guarantee that a system is completely secure after using the audit option.



There are two modes of installing Solaris Security Toolkit software, which are described briefly in the latter part of this section:

Regardless of how a system is installed, you can use the Solaris Security Toolkit software to harden and minimize your systems. Then periodically use the Solaris Security Toolkit software to audit whether the security profile of secured systems has been accidently or maliciously modified.

JumpStart Mode

System installation and configuration should be as automated as possible (ideally, 100 percent). This includes OS installation and configuration, network configuration, user accounts, applications, and hardening. One technology available to automate Solaris OS installations is JumpStart software. The JumpStart software provides a mechanism to install systems over a network, with little or no human intervention required. The Solaris Security Toolkit software provides a framework and scripts to implement and automate most of the tasks associated with hardening Solaris OS systems in JumpStart software-based installations. To obtain the JumpStart Enterprise Toolkit (JET), which facilitates JumpStart-based installations and includes modules to support hardening with the Solaris Security Toolkit, go to the Sun Software Download site at:

http://www.sun.com/download/

For more information about JumpStart technology, refer to the Sun BluePrintstrademark book JumpStart Technology: Effective Use in the Solaris Operating Environment.

Stand-alone Mode

In addition, the Solaris Security Toolkit software has a stand-alone mode. This mode provides the ability to perform all the same hardening functionality as in JumpStart mode, but on deployed systems. In either mode, the security modifications made can, and should, be customized to match security requirements for your system.

Regardless of how a system is installed, you can use the Solaris Security Toolkit software to harden your systems. Then periodically use the Solaris Security Toolkit software to audit whether the configuration of secured systems have been accidently or maliciously modified.


Understanding the Software Components

This section provides an overview of the structure of the Solaris Security Toolkit software components. The Solaris Security Toolkit software is a collection of files and directories. FIGURE 1-1 shows an illustration of the structure.


FIGURE 1-1 Software Component Structure

Diagram illustrating the structure of software components.


The following program or command files are in the /bin directory:

Directories

The components of the Solaris Security Toolkit architecture are organized in the following directories:

Each directory is described in this section. Where relevant, each script, configuration file, or subdirectory is listed, and references to other chapters are provided for detailed information.

The Solaris Security Toolkit directory structure is based on the structure in the Sun BluePrints book JumpStart Technology: Effective Use in the Solaris Operating Environment.

Audit Directory

This directory contains the audit scripts that evaluate a system's compliance with a defined security profile or set of audit scripts. The scripts in this directory are organized into the following categories:

For detailed listings of the scripts in each of these categories and descriptions of each script, refer to the Solaris Security Toolkit 4.2 Reference Manual.

Documentation Directory

This directory contains text files with information for the user, such as README, EOL_NOTICE, and INSTALL files.

man Directory

This directory contains subdirectories for the sections of man pages for commands, functions, and drivers. This directory also contains the windex file, which is an index of the commands and is provided as a courtesy.

For more information about these man pages, refer to the actual man pages or to the Solaris Security Toolkit 4.2 Man Page Guide.

Drivers Directory

This directory contains files of configuration information specifying which files are executed and installed when you run the Solaris Security Toolkit software. This directory contains drivers, scripts, and configuration files.

The following is an example of the drivers and scripts in the Drivers directory:

All drivers included with the Solaris Security Toolkit have three files for each driver:

These three files are indicated in brackets in the previous lists, for example, sunfire_15k_sc-{config|hardening|secure}.driver. These files are listed for completeness. Use only the secure.driver or name-secure.driver when you want to execute a driver. That driver automatically calls the related drivers.

The Solaris Security Toolkit architecture includes configuration information to enable driver, finish, and audit scripts to be used in different environments, while not modifying the actual scripts themselves. All variables used in the finish and audit scripts are maintained in a set of configuration files. These configuration files are imported by drivers, which make the variables available to the finish and audit scripts as they are called by the drivers.

The Solaris Security Toolkit software has four main configuration files, all of which are stored in the Drivers directory:

The user.run file provides a location for you to write replacement or enhanced versions of Solaris Security Toolkit functions, which are automatically used if present.



caution icon

Caution - Onlychange variable definitions in the user.initconfiguration file, and neverin the driver.initand finish.initconfiguration files.



Finish scripts called by the drivers are located in the Finish directory. Audit scripts called by the drivers are located in the Audit directory. Files installed by the drivers are read from the Files directory. For more information about finish scripts, refer to Chapter 4 in the Solaris Security Toolkit 4.2 Reference Manual. For more information about audit scripts, refer to Chapter 5 in the Solaris Security Toolkit 4.2 Reference Manual.

FIGURE 1-2 is a flow chart of the driver control flow.


FIGURE 1-2 Driver Control Flow

Diagram illustrating the driver flow of control.


1. For non-JumpStart runs only, the driver runs the jass-execute command. JumpStart runs directly call the driver, instead of calling the jass-execute command.

2. The driver might explicitly set variables.

3. The driver imports all of the environment variables from the various .init files.

4. The driver defines the JASS_FILES and JASS_SCRIPTS environment variables. The definition of these are optional; either a single environment can be defined, or both, or none.

Refer to the Solaris Security Toolkit 4.2 Reference Manual, Chapter 7, for more information about defining the JASS_FILES and JASS_SCRIPTS environment variables.

5. The driver calls driver.run to perform the tasks defined by the JASS_FILE and JASS_SCRIPTS environment variables.

6. (Optional) The driver defines specific driver behavior, which can be used to override system defaults in finish.init or user.init. The driver in CODE EXAMPLE 1-1 explicitly sets JASS_PASS_HISTORY to 4.

CODE EXAMPLE 1-1 illustrates the driver control flow code.


CODE EXAMPLE 1-1 Driver Control Flow Code
DIR="`/bin/dirname $0`"
JASS_PASS_HISTORY="4"
export DIR
. ${DIR}/driver.init
 
JASS_FILES="
                         /etc/cron.d/cron.allow
                         /etc/default/ftpd
                         /etc/default/telnetd
"
 
JASS_SCRIPTS="
                         install-at-allow.fin
                         remove-unneeded-accounts.fin
"
. ${DIR}/driver.run

1. This code example sets and exports the DIR environment variable so that the drivers recognize the starting directory.

2. The driver explicitly sets the JASS_PASS_HISTORY environment variable to 4.

3. The driver reads the various .init files (starting with driver.init).

4. The JASS_FILES environment variable is defined as containing those files that are copied from the JASS_HOME_DIR/Files directory onto the client.

5. The JASS_SCRIPTS environment variable is defined with the finish scripts that are run by the Solaris Security Toolkit software.

6. The execution of the hardening run is started by calling the driver.run driver. The driver.run copies the files specified by JASS_FILES, and runs the scripts specified by JASS_SCRIPTS.

Files Directory

This directory is used by the JASS_FILES environment variable and the driver.run script to store files that are copied to the JumpStart client.

The following files are in this directory:

Finish Directory

This directory contains the finish scripts that perform system modifications and updates during execution. The scripts in this directory are organized into the following categories:

For detailed listings of the scripts in each of these categories and descriptions of each script, refer to the Solaris Security Toolkit 4.2 Reference Manual.

OS Directory

This directory contains only Solaris OS images. These are used by the JumpStart software installation process as the Solaris OS source for client installations. The add_client script accepts the Solaris OS versions contained in this directory as arguments if the directory names follow the Solaris Security Toolkit OS naming conventions that follow.

For more information about loading and modifying Solaris OS images, refer to the Sun BluePrints book JumpStart Technology: Effective Use in the Solaris Operating Environment.

The standard installation naming conventions follow.

Solaris OS

Use the following naming standard for Solaris OS:

Solaris_os version_4 digit year-2 digit month of CD release

For example, the Solaris 10 Operating Environment CD, dated March 2005, would have a directory name of Solaris_10_2005-03. By separating updates and releases of the Solaris OS, very fine control can be maintained for testing and deployment purposes.

Solaris OS for x86/x64 Platforms

Use the following directory naming for Solaris OS for x86/x64 platforms:

Solaris_os version_4 digit year-2 digit month of CD release_ia

For example, if the Solaris OS for x86/x64 platforms release were dated March 2005, the directory name would be: Solaris_10_2005-03_ia.

Packages Directory

This directory contains software packages that can be installed with a finish script and verified with an audit script. For example, the Open Secure Shell software package could be stored in the Packages directory so that the correct finish script installs the software as required.

Several finish and audit scripts included in the Solaris Security Toolkit software perform software installation, basic configuration, and verification functions. The scripts that install and verify software from the Packages directory include:

Patches Directory

This directory is for storing Recommended and Security Patch Clusters for the Solaris OS. Download and extract required patches into this directory.

By placing and extracting the patches in this directory, you streamline installation. When the patches are extracted into this directory, the Solaris Security Toolkit software's patch installation script automates installation so that you do not have to manually extract the patch clusters for each system installation.

Create subdirectories for each of the Solaris OS versions used. For example, you might have directories 9_Recommended and 10_Recommended within the Patches directory.

Solaris Security Toolkit software supports Solaris OS for x86/x64 Platforms patch clusters. The supported naming convention for these patch clusters is the same as made available through SunSolve OnLineSM service.

The format is <release>_x86_Recommended. The Solaris OS for x86/x64 Platforms patch cluster for Solaris 10 OS would be in a directory named 10_x86_Recommended.

Profiles Directory

This directory contains all JumpStart profiles. These profiles contain configuration information used by JumpStart software to determine Solaris OS clusters for installation (for example, Core, End User, Developer, or Entire Distribution), disk layout, and installation type (for example, stand-alone) to perform.

JumpStart profiles are listed and used in the rules file to define how specific systems or groups of systems are built.

Sysidcfg Directory

Similar to the Profiles directory, the Sysidcfg directory contains files that are only used during JumpStart mode installations. These files automate Solaris OS installations by providing the required installation information. A separate directory tree stores OS-specific information.

Each Solaris OS has a separate directory. For each release, there is a directory named
Solaris_OS Version. The Solaris Security Toolkit software includes sample sysidcfg files for Solaris OS versions 2.5.1 through 10.

The sample sysidcfg files can be extended to other types such as per network or host. The Solaris Security Toolkit software supports arbitrary sysidcfg files.

For additional information on sysidcfg files, refer to the Sun BluePrints book JumpStart Technology: Effective Use in the Solaris Operating Environment.

Data Repository

While not in the JASS_HOME_DIR directory structure, the data repository, or JASS_REPOSITORY, directory supports Solaris Security Toolkit undo runs, saves data on how each run is executed, maintains a manifest of files modified by the software, and saves data for the execution log. This directory is located in /var/opt/SUNWjass/runs/timestamp.

Maintaining Version Control

Maintaining version control for all files and scripts used by the Solaris Security Toolkit software is critical for two reasons:

1. One of the goals of this environment is to be able to recreate a system installation. This goal would be impossible without a snapshot of all file versions used during an installation.

2. Because these scripts are performing security functions, which are critical processes for many organizations, extreme caution must be exercised to ensure that only necessary and tested changes are implemented.

A Source Code Control System (SCCS) version control package is provided in the Solaris OS SUNWsprot package. You can use other version control software available from freeware and commercial vendors to manage version information. Whichever version control product you use, put a process in place to manage updates and capture version information for future system re-creation.

Use an integrity management solution in addition to version control to determine whether the contents of files were modified. Although privileged users of a system might be able to bypass the version control system, they would not be able to easily bypass an integrity management system, which maintains its integrity database on a remote system. Integrity management solutions work best when centralized, because locally stored databases could be maliciously modified.


Configuring and Customizing the Solaris Security Toolkit Software

The Solaris Security Toolkit software contains default values for scripts, framework functions, and variables that implement all security guidelines in the Sun BluePrints book titled Enterprise Security: Solaris Operating Environment Security Journal, Solaris Operating Environment Versions 2.5.1, 2.6, 7, and 8 and Sun BluePrints OnLine articles about security. These settings are not appropriate for all systems, so you must customize the Solaris Security Toolkit software to meet the security requirements for your systems.

One of the most significant characteristics of the Solaris Security Toolkit software is that you can easily customize it to fit your environment, systems, and security requirements. To customize the Solaris Security Toolkit software, adjust its actions through drivers, finish scripts, audit scripts, framework functions, environment variables, and file templates.

Most users do not need to modify the Solaris Security Toolkit code. If code modifications are absolutely necessary for using the Solaris Security Toolkit software in your environment, copy the code to an unique function name in user.run, so that you can easily track changes, as in Guidelines.

Throughout this guide, guidelines and instructions for customizing the Solaris Security Toolkit software are provided. Refer to the Solaris Security Toolkit 4.2 Reference Manual to find helpful information about customizing the drivers. Customizing includes modifying and creating files or variables.

This guide also provide examples for customizing the Solaris Security Toolkit software throughout. The examples highlight some ways that you can customize the Solaris Security Toolkit software; however, there are many possibilities.

The following sections present information that must be clearly understood before attempting to customize the Solaris Security Toolkit software. The information is based on shared experiences collected from many deployments, so that you can avoid common pitfalls.

Policies and Requirements

When customizing and deploying the Solaris Security Toolkit software, proper planning ensures that the resulting platform configuration is correct and in line with your organization's expectations.

In your planning phase, be sure to obtain input from a variety of sources, including security policies and standards, industry regulations and guidelines, and vendor-supplied preferred practices.

In addition to this information, it is essential that you consider application and operational requirements to ensure that the resulting configuration does not impact a platform's ability to serve its intended business function.

Guidelines

When customizing the Solaris Security Toolkit software, consider the following guidelines. Understanding and observing these guidelines help make the process of sustaining a deployment much simpler and more effective.

To customize any of the files, first make a copy, then modify the copy, leaving the original intact. Only one exception exist to this guideline:



Note - Be aware that if SUNWjass is removed using the pkgrm command, the user.init and user.run files, if created, are not removed. This behavior also occurs for any customer files that are added to the Solaris Security Toolkit directory structure and are not included in the original software distribution.





Note - The Solaris Security Toolkit 4.2 software provides a new enhancement to the pkgrm command. With this release, the first step in the pkgrm command checks the integrity of all files included in the distribution. If any files are different, the pkgrm command exits with an error message that tells the system administrator either to put the correct file in place or to remove the modified file.