- Determining Business Case
- Obtaining Support
- Creating a Build Specification
- Building a Work Space
- Installing the Solaris Security Toolkit
- Customizing the Solaris Security Toolkit
- Building a Customized, Bootable Installation
- About the Author
- Acknowledgements
- Related Resources
- Web Sites
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Customizing the Solaris Security Toolkit
The Solaris Security Toolkit software runs a specified set of finish scripts during the build of the Solaris OE. This section describes how to customize the Solaris Security Toolkit software and a JumpStart profile based upon the build specification created earlier.
To Customize the Solaris Security Toolkit
For detailed information about creating and customizing the Solaris Security Toolkit software and JumpStart profiles, refer to the following Sun BluePrint books:
Securing Systems with the Solaris™ Security Toolkit
JumpStart™ Technology: Effective Use in the Solaris™ Operating Environment
Create your own profile, based upon your build specifications, requirements, and disk space.
Create and modify a user.run file.
Modify the Solaris Security Toolkit user.init file as shown in CODE EXAMPLE-7.
The toolkit.profile gives the system information as to how the file system is to be built. Additionally, the rules file calls JumpStart finish scripts. The rules file provides instructions for which profile and/or driver should run during installation. CODE EXAMPLE-4 shows how to customize a sample toolkit.profile, created for this exercise.
CODE EXAMPLE-4 Customizing a JumpStart Profile
# cat toolkit.profile install_type initial_install system_type server # # Assume 4Gb minimum rootdisk # 1.5Gb root filesys, and 500Mb var # Swap based on physical memory # partitioning explicit filesys rootdisk.s0 1500 / filesys rootdisk.s1 auto swap filesys rootdisk.s3 500 /var cluster SUNWCreq
The following is an example of the rules file used for this exercise.
# more /export/core/s0/.install_config/rules probe network any - - Profiles/toolkit.profile Drivers/secure.driver
Additionally, when the Solaris OE is installed, the sysidcfg is read for any configuration information regarding time zone settings, language, and Internet protocol settings (IP). CODE EXAMPLE-5 is a sample sysidcfg file that is included with the Solaris Security Toolkit software distribution. During this exercise, we do not customize the sysidcfg.
CODE EXAMPLE-5 Sample sysidcfg File
# more sysidcfg
#
# Copyright (c) 2000-2002 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)sysidcfg 2.5 02/02/21 SMI"
#
system_locale=en_US
timezone=US/Eastern
network_interface=primary {netmask=255.255.255.0
protocol_ipv6=no}
terminal=vt100
security_policy=NONE
name_service=NONE
timeserver=localhost
Drivers are a collection of shell scripts that automate processes for installation options. Drivers call finish scripts, which perform tasks for installation and security hardening of a system. These custom-made drivers manipulate any files and/or security hardening requirements necessary for this build as designated by Solaris Security Toolkit software.
The first top-level driver that is called is the secure.driver. The secure.driver is a wrapper used to assist the automation of the finish scripts for system hardening. This driver calls additional drivers for system variable settings and specific, customized finish scripts.
The driver.init file sets variables necessary for the Solaris Security Toolkit software during the build of the Solaris OE and is not customized for this exercise. In case you want to review it, the driver.init file is located in the .install_config directory.
After the secure.driver sets all the necessary variables for it to perform its function, it calls the config.driver file. The config.driver captures configuration information about the system and is not intended to perform any security functions. The config.driver automates the installation of the patch cluster from the Patches directory located inside the .install_config directory. It is necessary to apply the security patches before any hardening takes place on a system. Patches have a history of enabling services that might have been previously disabled. Therefore, the config.driver patches the system before any hardening is applied to a system.
A sample user.run.SAMPLE file is included in the .install_config directory and is used for this exercise. The user.run file tries to mount an NFS file system to install the patch cluster. Because we are building a Solaris OE from CD, we need to tell the Solaris Security Toolkit software to find the patch cluster locally. Therefore, we replace NFS with LOFS (shown in bold) in the user.run file. LOFS tells the software that the patch cluster is on the loopback file system, as opposed to being remotely accessed using NFS. The change is shown in CODE EXAMPLE-6.
CODE EXAMPLE-6 Modifying the user.run File
#
# cat user.run
# !/bin/sh
#
# Copyright (c) 2002 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)user.run.SAMPLE 3.2 02/08/30 SMI"
#
# This file is to be used to override or specify user functions that
# will be used by this programs using this toolkit. Note that this
# script is called within the "driver.run" and so will override any
# of the default functions supplied by this toolkit. In general,
# this script should be modified as it will not be replaced during
# upgrades.
mount_fs()
{
# This is a "helper" function for mount filesystems. This generally
# will not be called directly.
# Parameters to this function are:
# $1 = Server and fully qualified path to mount.
# $2 = Name of the mount point.
cd /
if [ "${1}" = "" ]; then
logError "The server and path to be mounted were not specified."
return
fi
if [ "${2}" = "" ]; then
logError "The mount point was not specified."
return
fi
if [ ! -d ${2} ]; then
mkdir -p ${2}
fi
#
echo "NOTICE: Mounting ${1} on ${2}."
mount -F lofs ${1} ${2}
}
.
.
.
Now when the config.driver is run, the hardening.driver is used to harden the Solaris OE. The hardening.driver is built to the specifications necessary to function in the environment and is not modified for this exercise.
CODE EXAMPLE-7 Modifying the user.init File
#
# !/bin/sh
# Copyright (c) 2002 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)user.init.SAMPLE 3.2 02/08/30 SMI"
#
# This file is to be used to override or specify user variables that will
# be used by the scripts in this toolkit. Note that this script is
# called before both "driver.init" and "finish.init" so any changes made
# in this file will not be overwritten.
#
# In general, this script should be modified as it should not be
# replaced during upgrades.
#
# For more information on how to extend or enhance variables used by the
# Finish scripts, refer to the "finish.init" script.
#
# *****************************************************************************
JASS_SERVER="´df -k /cdrom | tail -1 | awk -F: '{ print $1 }'´"
export JASS_SERVER
JASS_PACKAGE_MOUNT=/tmp/install_config/Packages
JASS_PATCH_MOUNT=/tmp/install_config/Patches
#
if [ "${JASS_PACKAGE_MOUNT}" = "" ]; then
JASS_PACKAGE_MOUNT="${JASS_SERVER}:/jumpstart/Packages"
# echo "JASS_PACKAGE_MOUNT is set to ${JASS_PACKAGE_MOUNT}."
fi
export JASS_PACKAGE_MOUNT
.
.
.
During the build of the system, the installation expects to be explicitly told where the JASS_PACKAGE_MOUNT and JASS_PATCH_MOUNT are exported. This modification is necessary for this exercise because the Solaris Security Toolkit software mounts the Packages and Patches from /jumpstart/Packages or /jumpstart/Patches, respectively. The file should be in the Drivers directory within the .install_config directory. A sample user.init file is included with the Solaris Security Toolkit software distribution.