C H A P T E R 2 |
File Templates |
This chapter provides reference information about how to use, modify, and customize the file templates included in the Solaris Security Toolkit software. Also, this chapter describes how drivers process functions and other information that is stored in file templates.
This chapter contains the following topics:
File templates are an integral part of the Solaris Security Toolkit software. These files provide a mechanism for you to customize and distribute scripts easily through environment variables, OS version numbers, and client host names. You can leverage the contents of the Files directory in combination with finish scripts to isolate related changes, depending on the design of your security profile (driver).
This section provides instructions and recommendations for customizing file templates, including instructions for creating new files in the Files directory.
For information about customizing drivers, finish scripts, and audit scripts, see the following chapters:
|
Use the following steps to customize file templates (files) so that your custom versions are available and not overwritten if newer versions of software are released and installed on your systems.
1. Copy the files and any related files that you want to customize.
2. Rename the copies with names that identify the files as custom files.
For recommendations, refer to "Configuring and Customizing the Solaris Security Toolkit Software", Chapter 1, Solaris Security Toolkit 4.1 Administration Guide.
3. If applicable, modify your custom drivers to call the uniquely named files appropriately.
The following code sample shows a modification to the JASS_FILES environment variable that customizes which files are copied to a particular host.
In this case, a customized hardening driver called abccorp-starfire_ssp-hardening.driver uses a custom nddconfig file. Instead of modifying the nddconfig original file, which could be overwritten with an updated Solaris Security Toolkit software release, create a custom nddconfig script by appending the host name of the destination system to the file name in the Files directory. The following example shows a custom nddconfig script that has the host name of the destination system in the script file name
# pwd /opt/jass-n.n # find Files -name "*nddconfig*" Files/etc/init.d/nddconfig Files/etc/init.d/nddconfig.ssp-db-serv Files/etc/rc2.d/S70nddconfig -> ../init.d/nddconfig |
Files are copied automatically by the software from the JASS_HOME_DIR/Files directory based on the way you define the JASS_FILES and JASS_FILE_OS version environment variables. For information about these environment variables, see Chapter 6.
The Solaris Security Toolkit software differentiates between multiple files in the JASS_HOME_DIR/Files directory and the definitions in the JASS_FILES and JASS_FILE_OS version environment variables.
The files that are copied by the copy_files function are selected by the following criteria:
In this option, the software copies the object only if the name of the target platform matches the value specified by ${HOST}. This host environment variable uses the same naming format as the JASS_HOSTNAME environment variable.
For example: /etc/issue.jordan
If the software cannot find this file, the software continues to search for the general file (the option described next).
In this option, the software only copies the object if the OS revision of the target platform matches the value specified by ${OS}. The OS parameter uses the same naming format as the JASS_OS_REVISION environment variable. So, a file to be used only on the Solaris 8 OS is denoted as "filename+5.8".
If the software cannot find this file, the software looks for the file associated with the host name (the option described next).
In this option, the software copies the file to a target system.
Note - When the file length or size is zero, the file is not copied to the system. |
The order of precedence used to match a file is listed. For example, if a host-specific and general file both exist, the host-specific file is used if the name of a target system matches the host name defined by the host-specific file.
You can configure the Solaris Security Toolkit software by editing configuration files that reference environment variables. This feature allows you to use the Solaris Security Toolkit software drivers in different environments, without modifying finish or audit scripts directly.
All Solaris Security Toolkit environment variables are maintained in a set of configuration files. These configuration files are imported by drivers, which make the variables available to finish and audit scripts as they are called by the drivers.
The Solaris Security Toolkit software has three primary configuration files, all of which are stored in the Drivers directory:
This file contains environment variables that define aspects of the Solaris Security Toolkit software framework and overall operation.
Note - Do not alter the driver.init file, because it is overwritten when you upgrade to subsequent versions of the Solaris Security Toolkit software. |
Core environment variables such as JASS_VERSION and JASS_ROOT_DIR are in the driver.init script.
This script loads the user.init script, thereby incorporating any user variables or environment variable overrides. Also, this script loads the contents of the finish.init file to set any finish script variables that might not have been defined. This script serves as the public interface used by drivers to load all of the variables used by the Solaris Security Toolkit software. None of the other initialization functions are supposed to be directly accessed by any of the driver, finish, or audit scripts.
This file contains the following environment variables:
Each of these environment variables is described in Chapter 6.
This file contains environment variables that define the behavior of the individual finish scripts. The two factors that contribute to how a system is hardened are as follows:
Note - Do not alter the finish.init file, because it is overwritten when you upgrade to subsequent versions of the Solaris Security Toolkit software. |
This file contains the following environment variables:
Each of these environment variables is described in Chapter 6.
This file is for adding user-defined variables. You can override variables defined in the driver.init and finish.init files by defining the variables in the user.init file. This feature allows administrators to customize the Solaris Security Toolkit software to suit their site needs and requirements.
A user.init.SAMPLE is included to provide an example of what must be defined for the software to function properly. Copy and modify the copy of user.init.SAMPLE to fit your environment, then rename the file to user.init. Because a user.init file is not included with the software, you can create and customize it without it being overwritten during subsequent software upgrades.
The user.init file provides default values for the following environment variables:
The default values for these two variables are JumpStart-server-IP address/jumpstart/Packages and JumpStart-server-IP address/jumpstart/Patches, respectively. These are the recommendations made in Chapter 5, Solaris Security Toolkit 4.1 Administration Guide and in the Sun BluePrints book JumpStart Technology: Effective Use in the Solaris Operating Environment. If you follow the recommendations made in these other sources, then no changes are required in the user.init.SAMPLE file. Simply copy this file to user.init.
However, if you move the JumpStart environment from one site to another, verify these variables, as they can be modified to reference your JumpStart server and directory paths. Each of these environment variables is described in Chapter 6.
You can also make modifications to the JASS_SVCS_ENABLE and JASS_SVCS_DISABLE variables and other environment variables through the user.init file. However, because variables might already be used in specific drivers, care must be taken when modifying the behavior of the Solaris Security Toolkit software.
For example, the suncluster3x-secure.driver uses JASS_SVCS_ENABLE to leave certain services enabled in the /etc/inetd.conf file. If you want other services enabled, create and customize a version of the suncluster3x driver file, comment out the definition of JASS_SVCS_ENABLE, and add a new JASS_SVCS_ENABLE definition to the user.init file.
You can also add environment variables to the user.init and user.run scripts. To add a new variable, add the variable declaration with its default value and export it in the user.init file. This process provides a global, default value that you can subsequently change as needed by overriding it within a security profile (driver).
In the CODE EXAMPLE 2-1, the code adds a new variable JASS_ACCT_DISABLE to the user.init file to disable a list of user accounts. These accounts are disabled when finish scripts are run.
The software uses the Files directory with the JASS_FILES environment variable and the copy_files function. This directory stores file templates that are copied to a JumpStart client during a hardening run.
The following file templates are in the Files directory:
The following subsections describe each of these files.
This configuration file is provided as a sample. It provides some base-level configuration for csh users by setting some common csh variables such as file completion and history. In addition, it sets the kill and erase terminal options, as well as a command line prompt that includes the path to the current working directory. This file is not required for the software to function properly and can be modified or replaced as appropriate for your environment.
By default, this file is copied by the config.driver to the system being hardened.
This configuration file is provided as a sample. As distributed with the software, this configuration only defines a UMASK, the PATH, and MANPATH for any root sh started shells.
This file is not required for the software to function properly and can be modified or replaced as appropriate for your environment.
By default, this file is copied by the config.driver to the system being hardened.
With the release of Solaris 8 OS, a sendmail configuration file can be used to run sendmail in queue processing mode only. This file is copied only onto Solaris 8 OS systems being hardened by the disable-sendmail.fin script.
The disable-sendmail.fin script is OS-version aware and modifies the behavior of sendmail based on the OS being hardened. For more information, refer to the Sun BluePrints OnLine article titled "Solaris Operating Environment Security: Updated for Solaris 9 OE."
By default, this file is copied by the disable-sendmail.fin to the system being hardened.
This file disables all remote access, whether direct or broadcast, to any X server running on the system. Depending on the X support requirements and the environment the Solaris Security Toolkit software is used in, this file might not be appropriate.
By default, this file is copied by the hardening.driver to the system being hardened.
These two files are installed on Solaris 9 OS systems by the finish script enable-tcpwrappers.fin. After installing the hosts.allow and hosts.deny files, the finish script enables Transmission Control Protocol (TCP) wrappers by modifying the /etc/default/inetd configuration file.
The hosts.allow and hosts.deny files are samples to customize for your security profile based on local policies, procedures, and requirements. The default configuration of the hosts.allow defines permitted Solaris Secure Shell (SSH) access to be LOCAL, which means that SSH connections are only permitted from the subnet to which the system is connected. The default configuration of the hosts.deny file is to deny all connection attempts not permitted in the hosts.allow.
By default, this file is copied by the enable-tcpwrappers.fin to the system being hardened.
These files are used on Sun Fire High-End Systems domains to ensure that the misc/klmmod kernel module is loaded. For further information, refer to the Sun Blueprints OnLine article, "Securing the Sun Fire 12K and 15K Domains."
By default, these files are copied by the s15K-install-klmmod-loader.fin to the domain being hardened.
This file copies over the nddconfig startup script required to implement network settings, which improves security. For information about configuring network settings for security, refer to the Sun BluePrints OnLine article titled "Solaris Operating Environment Network Settings for Security: Updated for the Solaris 9 Operating Environment."
By default, this file is copied by the hardening.driver to the system being hardened.
This file sets the correct permissions on the /tmp and /var/tmp directories when a system is rebooted. If an inconsistency is found, it is displayed to standard output and logged via SYSLOG. This file is installed in /etc/rc2.d twice to permit this check to be performed both before and after the mountall command is run from S01MOUNTFSYS. This check helps ensure that both the mount point and the mounted file system have the correct permissions and ownership.
By default, this file is copied by the hardening.driver to the system being hardened.
This file, in combination with the /etc/rc2.d/S73sms_arpconfig, /etc/sms_domain_arp, and /etc/sms_sc_arp is for use on Sun Fire High-End Systems to implement static Address Resolution Protocol (ARP) on the internal IP-based management network for additional security. For information about how to use these capabilities, refer to the Sun BluePrints OnLine articles titled "Securing the Sun Fire 12K and 15K System Controllers" and "Securing the Sun Fire 12K and 15K Domains."
By default, this file is copied by the s15k-static-arp.fin to the system being hardened.
These files are based on United States (U.S.) government recommendations and provide legal notice that user activities could be monitored. If an organization has specific legal banners, they can be installed into these files.
These files are provided as default templates. Have your legal counsel provide or review notices that apply to your organization.
By default, this file is copied by the hardening.driver to the system being hardened.
This file disables IP forwarding between interfaces on a system by creating an /etc/notrouter file. The client no longer functions as a router regardless of the number of network interfaces.
By default, this file is copied by the hardening.driver to the system being hardened.
Note - These files are symbolic links to /etc/init.d/set-tmp-permissions. |
These files set the correct permissions on the /tmp and /var/tmp directories when a system is rebooted. If an inconsistency is found, it is displayed to standard output and logged via SYSLOG. These scripts are installed into /etc/rc2.d twice to permit this check to be performed both before and after the mountall command is run from S01MOUNTFSYS. This check helps ensure that both the mount point and the mounted file system have the correct permissions and ownership.
By default, these files are copied by the hardening.driver to the system being hardened.
Note - This file is a symbolic link to /etc/init.d/nddconfig. |
This file copies over the S70nddconfig startup script required to implement network settings, which improves security. Refer to the Sun BluePrints OnLine article titled "Solaris Operating Environment Network Settings for Security: Updated for Solaris 9 Operating Environment."
By default, this file is copied by the hardening.driver to the system being hardened.
Note - This file is a symbolic link to /etc/init.d/sms_arpconfig. |
This file in conjunction with the /etc/init.d/sms_arpconfig, /etc/sms_domain_arp, and /etc/sms_sc_arp files is for use on Sun Fire High-End Systems to implement static Address Resolution Protocol (ARP) on the internal IP-based management network for additional security. For information about how to use these capabilities, refer to the Sun BluePrints OnLine articles titled "Securing the Sun Fire 12K and 15K System Controllers" and "Securing the Sun Fire 12K and 15K Domains."
By default, this file is copied by the s15k-static-arp.fin to the system being hardened.
This file is installed when disable-nfs-client.fin runs. As disable-nfs-client.fin normally starts the swap space, this run control script is added by the Solaris Security Toolkit software to perform this task.
These are configuration files for the Solaris OS auditing subsystem, also referred to as the Solaris Basic Security Module, released in February 2001. If you add these three files to a Solaris 8 OS system, it configures the auditing subsystem.
These files are only installed by the Solaris Security Toolkit software on Solaris 8 OS systems. For more information, refer to the Sun BluePrints OnLine article titled "Auditing in the Solaris 8 Operating Environment."
By default, these files are copied by the enable-bsm.fin to the system being hardened.
These files in combination with the /etc/init.d/sms_arpconfig and /etc/S70sms_arpconfig files are for use on Sun Fire High-End Systems to implement static Address Resolution Protocol (ARP) on the internal IP-based management network for additional security. For information about how to use these capabilities, refer to the Sun BluePrints OnLine articles titled "Securing the Sun Fire 12K and 15K System Controllers" and "Securing the Sun Fire 12K and 15K Domains."
By default, these files are copied by the s15k-static-arp.fin to the system being hardened.
This file performs additional logging. It serves as a placeholder for organizations to add their own centralized log server (or servers) so that proactive log analysis can be done.
By default, this file is copied by the hardening.driver to the system being hardened.
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.