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 JASS (JumpStart Architecture and Security Scripts) 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, minimize, and audit the security of systems.

System installation and configuration should be as automated as possible (ideally, 100 percent). This guideline includes OS installation and configuration, network configuration, user accounts, applications, and security modifications. The security modification may include hardening and/or minimization, depending on the purpose of the system. 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 and minimizing Solaris OS systems in JumpStart software-based installations.

In addition, the Solaris Security Toolkit software has a standalone 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 initially to harden and minimize your systems. Then periodically use the Solaris Security Toolkit software to audit whether the security profile of secured systems is not accidently or maliciously modified.



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.




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.


In addition to these directories and subdirectories, the following files are in the top level of the Solaris Security Toolkit software structure, in /bin:

Directories

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

Each directory is described in this section. Where appropriate, 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.1 Reference Manual.

Documentation Directory

This directory contains text files with information for the user, such as a README file.

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 provided as a courtesy.

For more information about these man pages, refer to the man pages themselves or the Solaris Security Toolkit 4.1 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 product-specific drivers and some other drivers include three files for each driver:

These three files are indicated in brackets in the previous list, for example, sunfire_15k_sc-{config|hardening|secure}.driver. These files are listed for completeness. Use only the 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 three main configuration files, all of which are stored in the Drivers directory:

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 and audit scripts, see the respective chapters in this book.

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


FIGURE 1-2 Driver Control Flow

Diagram illustrating the driver flow of control.


All of the environment variables from the various .init files are imported first. Once this is complete, the driver moves on to part two, which defines JASS_FILES and JASS_SCRIPTS. The definition of these are optional; either a single environment can be defined, or both, or none. Part three of the driver calls driver.run to perform the tasks defined by the JASS_FILE and JASS_SCRIPTS environment variables.

CODE EXAMPLE 1-1 demonstrates driver control flow.


CODE EXAMPLE 1-1 Driver Control Flow
DIR="`/bin/dirname $0`"
 
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

This code example sets and exports the DIR environment variable so that the drivers recognize the starting directory. Next, the JASS_FILES environment variable is defined as containing those files that are copied from the JASS_HOME_DIR/Files directory onto the client. The JASS_SCRIPTS environment variable is then defined with the finish scripts that are run by the Solaris Security Toolkit software. Finally, the execution of the hardening run is started by calling the driver.run driver. Once called, 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. This directory stores 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 installation. 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.1 Reference Manual.

OS Directory

This directory contains only Solaris OS images. These are used by the JumpStart software installation process as the source of the client installation and to provide the add_install_client and rm_install_client scripts. The add_client script accepts these additional directory names.

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 8 Operating Environment CD, dated April 2001, would have a directory name of Solaris_8_2001-04. By separating updates and releases of the Solaris OS, very fine control can be maintained for testing and deployment purposes.

Trusted Solaris OS

Use the following directory naming standard for Trusted Solaris:

Trusted_Solaris_os version_4 digit year_2 digit month of CD release

For example, if the Trusted Solaris software release were dated February 2000, the directory name would be: Trusted_Solaris_8_2000-02.

Solaris OS Intel Platform Edition

Use the following directory naming for Solaris OS Intel Platform Edition:

Solaris_os version_4 digit year_2 digit month of CD release_ia

For example, if the Solaris OS Intel Platform Edition release were dated April 2001, the directory name would be: Solaris_8_2001-04_ia.

Packages Directory

This directory contains software packages that can be installed with a finish script. For example, the Sun Javatrademark System Web Server, formerly the Suntrademark ONE Web Server, and before that the iPlanettrademark Web Server, software package could be stored in the Packages directory so that the appropriate finish script installs the software as required.

Several finish scripts included in the Solaris Security Toolkit software perform software installation and basic configuration functions. The scripts that install 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 2.5.1_Recommended and 2.6_Recommended within the Patches directory.

Solaris Security Toolkit software supports Solaris OS Intel Platform Edition patch clusters. The supported naming convention for these patch clusters is the same as made available through SunSolve OnLineSM service.

The format is Solaris_<release>_x86_Recommended. The Solaris OS Intel Platform Edition patch cluster for Solaris 8 OS would be in a directory named Solaris_8_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, standalone) 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 9.

The sample sysidcfg files can be extended to other types such as per network, host, etc. 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

The data repository is an environment variable in the JASS_REPOSITORY directory that 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. The undo feature relies on the information stored in the data repository.


Maintaining Version Control

Maintaining version control for all files and scripts used by the Solaris Security Toolkit software is critical for two reasons. First, 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. Second, because these scripts are performing security functions--which is a critical process for many organizations--extreme caution must be exercised to ensure that only appropriate 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 may be able to bypass the version control system, they would not be able easily to 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.


Running Supported Solaris OS Versions

Sun support for Solaris Security Toolkit software is available only for its use in the Solaris 8 and Solaris 9 Operating Systems. While the software can be used in the Solaris 2.5.1, Solaris 2.6, and Solaris 7 Operating Systems, Sun support is not available for its use in those operating systems.

The Solaris Security Toolkit software automatically detects which version of the Solaris Operating System software is installed, then runs tasks appropriate for that operating system version.


Running Supported SMS Versions

If you are using System Management Services (SMS) to manage your system controller (SC), Sun support is available for Solaris Security Toolkit 4.1 software if you are using SMS versions 1.3 through 1.4.1.


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 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. Any changes may negatively impact supportability and upgrades. If code modifications are absolutely necessary for using the Solaris Security Toolkit software in your environment, copy the code to a unique file or function name, 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 where applicable in each chapter. Refer to the the Solaris Security Toolkit 4.1 Reference Manual to find information helpful about customizing the drivers. Customizing includes modifying and creating files or variables.

The following chapters provide examples for customizing the Solaris Security Toolkit software. 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.



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 occurs for any customer files that are added to the Solaris Security Toolkit directory structure and are not included in the distribution. The files in the Files directory included in the Solaris Security Toolkit distribution and sysidcfg files exist, and would therefore be removed.