Solaris Security Toolkit 4.1 Reference Manual Table Of ContentsPrevious ChapterNext ChapterBook Index


C H A P T E R  1
Framework Functions

This chapter provides reference information on using, adding, modifying, and removing framework functions. Framework functions provide flexibility for you to change the behavior of the Solaris Security Toolkit software without modifying source code.

Use framework functions to limit the amount of coding that is needed to develop new finish and audit scripts, and to keep common functionality consistent. For example, by using the common logging functions, you can configure the reporting mechanism without needing to develop or alter any additional source code. Similarly, by using this modular code for common functions, bugs and enhancements can be more systematically addressed.

In addition, framework functions support the undo option. For example, using the framework function backup_file in place of a cp or mv command allows that operation to be reversed during an undo run.

This chapter contains the following topics:

Customizing Framework Functions

The Solaris Security Toolkit software is based on a modular framework that you can combine in various ways to suit your organization's needs. Sometimes, however, the standard features provided by the Solaris Security Toolkit software might not meet your site's needs. You can supplement the standard features by customizing framework functions to enhance and extend the functionality provided by the Solaris Security Toolkit software. The framework functions configure how the Solaris Security Toolkit software runs, define the functions that it uses, and initialize environment variables.

In most cases, you can easily copy standard framework function files and scripts, and then customize the functionality for your use. For example, using the user.run file, you can add, modify, replace, or extend the standard framework functions. The user.run file is similar in purpose to the user.init file, except that you use the user.init file to add or modify environment variables.

In some cases, you might need to develop new framework functions. In this case, use similar framework functions as a guide or template for coding, and be sure to follow the recommendations provided in this book. Development should only be undertaken by users who are familiar with the Solaris Security Toolkit software's design and implementation.


caution icon

Caution - Take extreme care when developing your own framework functions. Incorrect programming might compromise the Solaris Security Toolkit software's ability to properly implement or undo changes or to audit a system's configuration. Furthermore, changes made to the software could adversely impact the target platform on which the software is run.


CODE EXAMPLE 1-1 show how Solaris Security Toolkit functionality can be extended by customizing the standard framework. In this example, the mount_filesystems function is modified to enable the developer to mount additional file systems during a JumpStart installation. The mount_filesystems function is copied directly from the driver.funcs script into the user.run file. The modifications to it are in line numbers 8 and 9.


CODE EXAMPLE 1-1 Extending Functionality by Customizing the Framework 
1   mount_filesystems()

2   {

3      if [ "${JASS_STANDALONE}" = "0" ]; then

4         mount_fs ${JASS_PACKAGE_MOUNT} ${JASS_ROOT_DIR} \

5            ${JASS_PACKAGE_DIR}

6         mount_fs ${JASS_PATCH_MOUNT} ${JASS_ROOT_DIR} \

7            ${JASS_PATCH_DIR}

8         mount_fs 192.168.0.1:/apps01/oracle \

9            ${JASS_ROOT_DIR}/tmp/apps-oracle

10     fi

11  }

For the sake of simplicity, the variable used to mount the new file system is not converted to Solaris Security Toolkit environment variables. To aid in portability and flexibility, abstract the actual values using environment variables. This approach allows changes to be made consistently, because the software is deployed into environments with different requirements, such as production, quality assurance, and development.


Note - You could implement the same functionality within a finish script that uses this mount point, so that the mounting, use, and unmounting of the file system is self-contained within the script. However, it might be more effective and efficient to mount the file system using mount_filesystems when a single file system is used by more than one script.



caution icon

Caution - A disadvantage to modifying mount_filesystemsis that when you install updates of the Solaris Security Toolkit software, you might need to modify the mount_filesystemsagain.


Using Common Log Functions

These functions control all logging and reporting functions and are located in the Drivers directory in a file called common_log.funcs. The logging and reporting functions are used in all of the Solaris Security Toolkit software's operational modes; therefore, they are considered common functions. For example, common functions such as logWarning and logError are in this file.

This section describes the following common log functions.

logBanner

This function displays banner messages. These messages typically precede driver, finish, or audit script run output. Also, banner messages are used at the start and end of a run and are only displayed if the logging verbosity is at least 3. For more information on verbosity levels, see Chapter 6.

Banner messages take two forms. If you pass an empty string to this function, then a single line separator is displayed. This line is often used to force a "break" in the displayed output. If you enter a single string value, then the output is displayed between a pair of single line separators. CODE EXAMPLE 1-2 shows a sample of a banner message.


CODE EXAMPLE 1-2 Sample Banner Message 
================================================================

Solaris Security Toolkit Version: 4.1

Node name:                        imbulu

Host ID:                          8085816e

Host address:                     192.168.0.1

MAC address:                      0:0:80:85:81:6e

OS version:                       5.9

Date:                             Wed Jan  1 22:27:15 EST 2003

================================================================

You can control banner messages through the JASS_LOG_BANNER environment variable. For more information on this environment variable, see Chapter 6.

logDebug

This function displays debugging messages. This function accepts a single string argument to be displayed as a debugging message. By default, no debugging messages are displayed by the Solaris Security Toolkit software. This functionality is for future use and for you to add debugging log messages to your code. Debugging messages are only displayed if the verbosity is at least 4. For more information about verbosity levels, see Chapter 6.

logError

This function displays error messages. This function accepts a single string value that is displayed as an error message. Error messages are those that contain the string [ERR ].

Example usage: 


logError "getScore: Score value is not defined."

Example output: 


[ERR ] getScore: Score value is not defined.

You can control error messages through the JASS_LOG_ERROR environment variable. For more information on this environment variable, see Chapter 6.

logFailure

This function displays failure messages. This function accepts a single string value that is displayed as a failure message. Failure messages are those that contain the string [FAIL].

Example usage: 


logFailure "Package SUNWatfsr is installed."

Example output: 


[FAIL] Package SUNWatfsr is installed.

You can control failure messages through the JASS_LOG_FAILURE environment variable. For more information on this environment variable, see Chapter 6.

logFileContentsExist and
logFileContentsNotExist

Use these functions to log messages associated with the success or failure of checks. These functions together report on the results of a file content check. These functions are used primarily with the check_fileContentsExist and check_fileContentsNotExist functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logFileContentsExist /etc/default/inetinit "TCP_STRONG_ISS=2" 0

Example output: 


[PASS] File /etc/default/inetinit has content matching

TCP_STRONG_ISS=2.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logFileExists and
logFileNotExists

Use these functions to log messages associated with the success or failure of a check. These functions together report on the results of a file check. These functions are primarily used with the check_fileExists and check_fileNotExists functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

If this argument is passed a null string value, then this function reports the result in the form of a notice using the logNotice function. Otherwise, it reports the result as a failure using the logFailure function.

Example usage: 


logFileExists /etc/issue

Example output: 


[NOTE] File /etc/issue was found.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logFileGroupMatch and
logFileGroupNoMatch

Use these functions to log messages associated with the success or failure of a check. These functions together report on the results of a file group membership check. These functions are used primarily with the check_fileGroupMatch and check_fileGroupNoMatch functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logFileGroupMatch /etc/motd sys 0

Example output: 


[PASS] File /etc/motd has group sys.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logFileModeMatch and
logFileModeNoMatch

Use these functions to log messages associated with the success or failure of a check. These functions together report on the results of a file permissions check. These functions are used primarily with the check_fileModeMatch and check_fileModeNoMatch functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logFileModeMatch /etc/motd 0644 0

Example output: 


[PASS] File /etc/motd has mode 0644.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logFileNotFound

This function is used by the software to display file not found messages. This function is used throughout the Solaris Security Toolkit code in both hardening and audit runs to provide a standard message when a designated file was not found on the system.

You can supply the following arguments to this function:

If this argument is passed a null string value, then this function reports the result in the form of a notice using the logNotice function. Otherwise, it reports the result as a failure using the logFailure function.

Example usage: 


logFileNotFound /etc/motd

Example output: 


[NOTE] File /etc/issue was not found.

You can control notice and failure messages through the JASS_LOG_NOTICE and JASS_LOG_FAILURE environment variables, respectively. For more information on this environment variable, see Chapter 6.

logFileOwnerMatch and
logFileOwnerNoMatch

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a file ownership check. These functions are used primarily with the check_fileOwnerMatch and check_fileOwnerNoMatch functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logFileOwnerMatch /etc/motd root 0

Example output: 


[PASS] File /etc/motd has owner root.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logFileTypeMatch and
logFileTypeNoMatch

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a file type check. These functions are used primarily with the check_fileTypeMatch and check_fileTypeNoMatch functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

TABLE 1-1 lists the types detected by the software:


TABLE 1-1 File Types Detected by Using the check_fileTemplate Function

File Type

Description

b

Block special file

c

Character special file

d

Directory

D

Door

f

Regular file

l

Symbolic link

p

Named pipe (fifo)

s

Socket


Example usage: 


logFileTypeMatch /etc/motd f 0

Example output: 


[PASS] File /etc/motd is a regular file.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logFinding

This function displays audit finding messages. This function accepts a single string argument to be displayed as a message. The input for this function is processed by the printPrettyPath function prior to display. In addition, if the verbosity level is equal to 2, then optional tags are prepended to the message. The following are the optional tags that you can prepend by this function:


Note - If the finding occurs outside of an audit script, such as within the flow of the driver.run script, then the name of the current driver is used.


You can use all three output tags collectively or independently. The order of the position in the resulting output line is as they are listed. For more information on this function and verbosity levels, see Chapter 6.

Example usage: 


logFinding "/etc/motd"

Example output: 


test-script /etc/motd

logFormattedMessage

Use this function to generate formatted audit script headers that display information such as the script name, purpose, and rationale for the check. This function accepts a single string value and formats the message that is passed to the function.

These messages are reformatted as follows:

Formatted messages are displayed only when the verbosity level is at least 3. For more information on this function and verbosity levels, see Chapter 6.

Example usage: 


logFormattedMessage "Check system controller secure shell configuration."

Example output: 


# Check system controller secure shell configuration.

logInvalidDisableMode

Use this function to display an error message when the JASS_DISABLE_MODE environment variable is set to an invalid value. This utility function reports on the state of the JASS_DISABLE_MODE environment variable. This function takes no arguments and generates the following output: 


[ERR ] The JASS_DISABLE_MODE parameter has an invalid value: [...]

[ERR ] value must either be "script" or "conf".

For more information on this environment variable, see Chapter 6.

logInvalidOSRevision

Use this function when either the check_os_revision or check_os_min_revision functions fail their checks. This utility function reports when a function is being called on a version of the Solaris OS for which it does not apply. For example, use this function when there is an attempt to use a Solaris 8 OS script with the Solaris 2.6 OS.

Example usage: 


logInvalidOSRevision "5.9"

Example output: 


[NOTE] This script is only applicable for Solaris version

5.9.

To specify multiple versions, enter a hyphen (-) between versions, for example, "5.6-5.8."

This function displays notice messages. You can control messages through the JASS_LOG_NOTICE environment variable. For more information on this environment variable, see Chapter 6.

logMessage

Use this function to display any message that you want to display to users. Use this function for messages that do not have any tags associated with them. Similar to the logFormattedMessage function, this function displays an unformatted message. This function accepts a single string value that is displayed as is, with no modification.

Unformatted messages are only displayed if the verbosity level is at least 3. For more information on this function and verbosity levels, see Chapter 6.

Example usage: 


logMessage "Verify system controller static ARP configuration."

Example output: 


Verify system controller static ARP configuration.

logNotice

Use this function to display notice messages. This function accepts a single string value that is displayed as a notice message. Notice messages are those that contain the string [NOTE].

Example usage: 


logNotice "Service ${svc} does not exist in ${INETD}."

Example output: 


[NOTE] Service telnet does not exist in /etc/inetd.conf.

You can control notice messages through the JASS_LOG_NOTICE environment variable. For more information on this environment variable, see Chapter 6.

logPackageExists and
logPackageNotExists

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a check that determines if a software package is installed. These functions are used primarily with the check_packageExists and check_packageNotExists functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logPackageExists SUNWcsr 0

Example output: 


[PASS] Package SUNWcsr is installed.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logPatchExists and
logPatchNotExists

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a check that determines if a software patch is installed. These functions are used primarily with the check_patchExists and check_patchNotExists functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logPatchExists 123456-01 0

Example output: 


[PASS] Patch ID 123456-01 or higher is installed.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logProcessArgsMatch and
logProcessArgsNoMatch

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a check for runtime process arguments. These functions are used primarily with the check_processArgsMatch and check_processArgsNoMatch functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logProcessArgsMatch inetd "-t" 0

Example output: 


[PASS] Process inetd found with argument -t.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logProcessExists and
logProcessNotExists

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a check for a process. These functions are used primarily with the check_processExists and check_processNotExists functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logProcessExists nfsd 0

Example output: 


[PASS] Process nfsd was found.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logProcessNotFound

Use this function to log a FAIL message for any process that is not found. This function displays "process not found" messages. This function provides a standard message when a designated process cannot be found on a system.

You can supply the following arguments to this function:

Example usage: 


logProcessNotFound inetd

Example output: 


[FAIL] Process inetd was not found.

You can control these messages through the JASS_LOG_FAILURE environment variable. For more information on these environment variables, see Chapter 6.

logServiceConfigExists and
logServiceConfigNotExists

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a check that determines if a configuration file exists. These functions are used primarily with the check_serviceConfigExists and check_serviceConfigNotExists functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logServiceConfigExists /etc/apache/httpd.conf 0

Example output: 


[PASS] Service Config File /etc/apache/httpd.conf was found.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logStartScriptExists and
logStartScriptNotExists

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a check that determines if a run-control start script exists. These functions are used primarily with the check_startScriptExists and check_startScriptNotExists functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logStartScriptExists /etc/rc3.d/S89sshd 0

Example output: 


[PASS] Start Script /etc/rc3.d/S89sshd was found.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logStopScriptExists and
logStopScriptNotExists

Use these functions to log the messages associated with the success or failure of a check. These functions report on the results of a check that determines if a run-control stop script exists. These functions are used primarily with the check_stopScriptExists and check_stopScriptNotExists functions, although they can be used independently if necessary.

You can supply the following arguments to this function:

Example usage: 


logStopScriptExists /etc/rc2.d/K03sshd 0

Example output: 


[PASS] Stop Script /etc/rc2.d/K03sshd was found.

These functions display either success or failure messages. You can control these messages through the JASS_LOG_FAILURE and JASS_LOG_SUCCESS environment variables. For more information on these environment variables, see Chapter 6.

logSuccess

Use this function to display success messages. This function accepts a single string value that is displayed as an audit success message. Success messages are those that contain the string "[PASS]."

Example usage: 


logSuccess "Package SUNWsshdr is installed."

Example output: 


[PASS] Package SUNWsshdr is installed.

You can control success messages through the JASS_LOG_SUCCESS environment variable. For more information on this environment variable, see Chapter 6.

logWarning

Use this function to display warning messages. This function accepts a single sting value that is displayed as a warning message. Warning messages are those that contain the string "[WARN]."

Example usage: 


logWarning "User ${acct} is not listed in ${JASS_PASSWD}."

Example output: 


[WARN] User abc is not listed in /etc/passwd.

You can control warning messages through the JASS_LOG_WARNING environment variable. For more information on this environment variable, see Chapter 6.

Using Common Miscellaneous Functions

These functions are for common miscellaneous functions that are used within several areas of the Solaris Security Toolkit software and are not specific to functionality provided by other framework functions (files ending with a .func suffix). These functions are in the Drivers directory in a file called common_misc.funcs. Common utility functions such as isNumeric and printPretty are in this file.

This section describes the common miscellaneous functions.

isNumeric

Use this function to determine if input arguments are positive numbers. It is used throughout the software by helper functions whenever input must be validated to ensure that it consists of a single, positive integer. This function accepts a single string argument and determines if the value is a positive integer. If the value is a positive integer, this function displays a value of 0, otherwise it displays a value of 1.

invalidVulnVal

Use this function to determine if input arguments are positive numbers. This function accepts a single string argument and determines if the value is a positive integer. It logs an error message for each failure. This function is necessary to determine where there may be invalid arguments supplied to a function as a vulnerability value. In all other aspects, this function behaves like its isNumeric counterpart. This function applies only to audit operations.

checkLogStatus

Use this function to determine if a given input string is set to LOG. This function accepts a single string argument and determines whether the calling function should log its results. If the string evaluated is the string LOG, then this function echoes a value of 1, indicating that the calling function should log its results. If the input string contains any other value, this function echoes a value of 0, indicating that no output is logged by the calling function. This function applies only to audit operations.

adjustScore

Use this function to adjust the score outside of the methods provided by the functions defined in the audit_public.funcs file. This function accepts a positive integer argument representing the value that is added to the current score for an audit script. For example, there might be times when only the audit script can determine a failure. In those cases, use this function to adjust the score, accounting for the failure. If one is not supplied, it logs an error message and does not adjust the score. This function applies only to audit runs.

printPretty

Use this function to format printed output so that it is easier to read. This function accepts an unformatted input string and processes it. The resulting string is wrapped at 72 characters with each line of output indented by three characters.

printPrettyPath

Use this function to format path names. This function accepts as input an unformatted path name. This function strips any redundant forward slashes from the input string, then displays the result. If the string is empty, then the keyword "<No Value>" is displayed in its place.

extractComments

Use this function to remove comments from a file or script. This function accepts as input a list of tokens (script names, file names, and so on) and removes any text that is commented out. This function defines a comment as any substring of text that begins with a "#" (number) symbol and continues to the end of the line.

clean_path

Use this function to remove redundant "/" (forward slash) characters from a file name. This function accepts as input a single string argument and returns the same value after any duplicate forward slash characters (/) have been removed from the string. This function is used to clean up path names before they are displayed to the user or before they are placed in logs.

strip_path

Use this function to remove the JASS_ROOT_DIR prefix from the file name. This function accepts as input a single string argument and returns the same value after removing the JASS_ROOT_DIR prefix and replacing it with a single "/" (forward slash) character. This function is used with the add_to_manifest function when storing path names in the JASS manifest file.

Using Driver Functions

These functions are for driver functionality. These functions are in the driver.funcs file, located in the Drivers directory. Functions such as add_pkg and copy_a_file are in this file.

When customizing or creating scripts, use the following functions to perform standard operations.

add_patch

Use this function to add Solaris OS patches to the system. By default, this function expects that the patches installed are located in the JASS_PATCH_DIR directory. TABLE 1-2 lists the options for this function.


TABLE 1-2 Options for add_patch Finish Script Function

Option

Description

-o options

Options to be passed on

-M patchdir

The fully qualified path to the source directory

patchlist

List of patches or name of file containing a list of patches to apply


Example usage: 


add_patch 123456-01


add_patch -M ${JASS_PATCH_DIR}/OtherPatches patch_list.txt

 

add_pkg

Use this function to add Solaris OS packages to the system. By default, this function expects that the packages are located in the JASS_PACKAGE_DIR directory and that these packages are in one of the standard Sun formats, spooled directories or package stream files. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run. During an undo run, packages added using this function are removed from the system. TABLE 1-3 lists the options for this function.


TABLE 1-3 Options for add_pkg Function

Option

Description

-a ask_file

The pkgadd ask file name. By default, the pkgadd ask file, noask_pkgadd, is used if no other file is specified.

-d src_loc

The fully qualified path to the source package (streams or directory) to be installed

-o options

The pkgadd command options

package

The package to be installed


Example usage: 


add_pkg ABCtest


add_pkg -d ${JASS_ROOT_DIR}/${JASS_PACKAGE_DIR}/SUNWjass.pkg SUNWjass

 

add_to_manifest

Use this function to manually insert entries into a manifest file during hardening runs without calling one of the helper functions. This approach is most often done when a command must be executed for the undo operation to complete. Use this option with care to protect the integrity of the system and the Solaris Security Toolkit repository.


caution icon

Caution - Exercise extreme caution when using the Xmanifest option. The commands specified by this operation are executed during an undo run of the Solaris Security Toolkit as the rootuser. If you are not careful, you could cause data loss or render a target system unstable. For example, an Xmanifest entry of rm-rf/would delete the system's root partition during an undo run.


The add_to_manifest command uses the following syntax: 


add_to_manifest operation src dst args

This command puts an entry in the JASS_RUN_MANIFEST file in JASS_REPOSITORY/jass-manifest.txt, which is critical to the ability to undo the changes made by a finish script.


Note - Not all of the operations used by the Solaris Security Toolkit support each of these arguments. Also, the meaning of the options for src, dst, and args can differ based on the operation selected, as discussed in TABLE 1-4.


The operations supported by the add_to_manifest function are listed in TABLE 1-4. This table includes a sample resulting manifest entry after each option.


TABLE 1-4 add_to_manifest Options and Sample Manifest Entries

Option

Description

C

Indicates a file was copied. In this case, the src and dst parameters represent the original and copied file names, respectively. No other arguments are used.

install-templates.fin /etc/syslog.conf /etc/ \
syslog.conf.JASS.20020823230626

D

Indicates a directory was created. In this case, the src parameter represents the name of the newly created directory. No other arguments are used.

disable-lp.fin /var/spool/cron/crontabs.JASS

J

Indicates a new file was created on the system. This operation is used only when the file specified by the src parameter does not exist on the system. During an undo run, files tagged with this operation code are removed. This operation uses both the src and dst parameters to represent the original name of the file and its saved file name (which must include the JASS_SUFFIX).

disable-power-mgmt.fin /noautoshutdown \
/noautoshutdown.JASS.20020823230629

M

Indicates a file was moved. In this case, the src and dst parameters represent the original and moved file names, respectively. No other arguments are used.

disable-ldap-client.fin /etc/rcS.d/K41ldap.client \
/etc/rcS.d/_K41ldap.client.JASS.20020823230628

R

Indicates a file was removed from the system. In this case, the src parameter represents the name of the file that was removed. Files marked with this operation code cannot be restored using the Solaris Security Toolkit undo command.

S

Indicates a symbolic link was created. In this case, the src and dst parameters represent the source and target file names, respectively. During an undo run, the symbolic links for files tagged with this operation are removed from the system.

install-templates.fin ../init.d/nddconfig /etc/rc2.d/ \
S70nddconfig

X

Indicates a command was defined that should be run when the Solaris Security Toolkit processes a manifest entry that has this operation code. A special operation, this one is most often used to execute complex commands that go beyond the standard operations. For example, in the install-fix-modes.fin finish script, the following manifest entry is added to instruct the software to undo changes made by the Fix Modes program:

/opt/FixModes/fix-modes -u

This command instructs the software to run the fix-modes program with the
-u option. Note that all commands processed by this operation code should be specified using an absolute path to the program.


backup_file

Use this function to back up an existing file system object. This function backs up the original file using a standard naming convention. The convention appends JASS_SUFFIX to the original file name. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

The JASS_SAVE_BACKUP variable specifies if the Solaris Security Toolkit software saves or does not save backup copies of files modified during a run. If this environment variable is set to 0, then this function does not save backup files on the system. If files are not saved, then the run cannot be reversed by using the undo command.

Example usage: 


backup_file /etc/motd

check_os_min_version

Use this function to detect functionality that exists in multiple releases of the Solaris OS. This function takes only one argument, indicating the minimal OS release version. If the actual release of the OS on the target platform is greater than or equal to the argument, then the function returns 0, otherwise this function returns 1. If an error is encountered, then this function returns 255.

For example, this function can be used as shown in CODE EXAMPLE 1-3.


CODE EXAMPLE 1-3 Detecting Functionality That Exists in Multiple OS Releases 
if check_os_min_revision 5.6 ; then

   if [ "${JASS_KILL_SCRIPT_DISABLE}" = "1" ]; then

      disable_rc_file ${JASS_ROOT_DIR}/etc/rcS.d K10dtlogin

      disable_rc_file ${JASS_ROOT_DIR}/etc/rc0.d K10dtlogin

      disable_rc_file ${JASS_ROOT_DIR}/etc/rc1.d K10dtlogin

   fi

   disable_rc_file ${JASS_ROOT_DIR}/etc/rc2.d S99dtlogin

else

   logInvalidOSRevision "5.6 and later"

fi

In this example, the Common Desktop Environment (CDE) was not included in the Solaris OS until version 2.6, and this script checks to ensure that the version is at least 5.6, before attempting to disable the run-control scripts listed.

check_os_revision

Use this function to check for a specific OS revision or range of values. This function can take either one or two arguments. If one argument is supplied, then the script returns 0 only if the target operating system revision is the same as the argument, otherwise it returns 1.

Similarly, if two arguments are provided, the target operating system revision must be between the two values inclusively for the result to be 0. In either case, if an error is encountered, this function returns a value of 255.

For example, this function can be used as shown in CODE EXAMPLE 1-4.


CODE EXAMPLE 1-4 Checking for a Specific OS Revision or Range 
if check_os_revision 5.5.1 5.8; then

   if [ "${JASS_DISABLE_MODE}" = "conf" ]; then

      disable_conf_file ${JASS_ROOT_DIR}/etc asppp.cf

   elif [ "${JASS_DISABLE_MODE}" = "script" ]; then

      if [ "${JASS_KILL_SCRIPT_DISABLE}" = "1" ]; then

         disable_rc_file ${JASS_ROOT_DIR}/etc/rcS.d K50asppp

         disable_rc_file ${JASS_ROOT_DIR}/etc/rc0.d K47asppp

         disable_rc_file ${JASS_ROOT_DIR}/etc/rc0.d K50asppp

         disable_rc_file ${JASS_ROOT_DIR}/etc/rc1.d K47asppp

         disable_rc_file ${JASS_ROOT_DIR}/etc/rc1.d K50asppp

      fi

      disable_rc_file ${JASS_ROOT_DIR}/etc/rc2.d S47asppp

   fi

else

   logInvalidOSRevision "5.5.1-5.8"

fi

In this example, the script disables only its scripts or configuration files, based on the value of JASS_DISABLE_MODE, when the target OS revision is or falls between Solaris OS versions 2.5.1 and 8 inclusively.

checksum

Use this function to calculate the checksum for a file. This function takes a single string value that represents the file for which the checksum is being calculated. This function, which uses the Solaris cksum program to calculate the checksum, outputs a value in the format checksum:number of octets.


CODE EXAMPLE 1-5 Calculating the Checksum 
checksum foobar

12345:23

copy_a_dir

Use this function to recursively copy the contents of a directory. This function takes two arguments, a source directory name and a destination directory name. This function copies the contents of the source directory to the directory specified by the destination parameter. This function creates the new directory if it does not already exist. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

Example usage: 


copy_a_dir /tmp/test1 /tmp/test2

copy_a_file

Use this function to copy exactly one regular file. This function takes two arguments: a source file name and a destination file name. This function copies the contents of the source file to the file name specified by the destination parameter. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

Example usage: 


copy_a_file /tmp/test-file-a /tmp/test-file-b

copy_a_symlink

Use this function to copy a symbolic link to the target platform. This function takes two arguments: a source link name and a destination file name. This function creates a new symbolic link based on the source link specified using the new file name passed as the destination parameter. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

Example usage: 


copy_a_symlink /tmp/test-link-a /tmp/test-link-b

copy_files

Use this function to copy a set of file system objects from the JASS_HOME_DIR/Files directory tree to a target system. This function uses the appropriate copy functions listed previously to ensure that the changes made can be reversed during an undo run. This function is capable of copying regular files, directories, and symbolic links.

Example usage: 


copy_files /etc/init.d/nddconfig


copy_files "/etc/init.d/nddconfig /etc/motd /etc/issue"

 

This function extends capability by permitting the selective copy of objects based on tags appended to their file names.

The files that are copied by this 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 tag 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 tag 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".

For example: /etc/issue+5.10

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.

For example: /etc/issue


Note - When the file length/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.


Note - The copy_files function silently ignores any objects listed that are not found in the JASS_HOME_DIR/Files directory tree.


create_a_file

Use this function to create an empty file on a target system. This function uses a combination of the touch, chown, and chmod commands to create an empty file with a specific owner, group, and set of permissions.


Note - This function does not adjust permissions or ownerships on a file that exists.


This function creates a file with specific permissions.

Example usage: 


create_a_file -o guppy:staff -m 750 /usr/local/testing

In this example, a file called testing is created in the /usr/local directory, owned by guppy and group of staff, with permissions 750. This function accepts the options listed in TABLE 1-5.


TABLE 1-5 create_a_file Command Options

Option

Valid Input

[-o user[:group]]

Follows syntax of chown(1) and accepts user and user:group

[-m perms]

Follows syntax of chmod(1) and accepts perms

/some/fully/qualified/path/file

The fully qualified path to the file


Example usage: 


create_a_file /usr/local/testing


create_a_file -o root /usr/local/testing


create_a_file -o root:sys /usr/local/testing


create_a_file -o root -m 0750 /usr/local/testing

   

create_file_timestamp

Use this function to create a unique timestamp value for a given file and for all file backup operations. This function is useful for creating a backup of an already backed-up file when a unique suffix value is needed. The timestamp value created is in the same format as JASS_TIMESTAMP. The resulting timestamp value created by this function is stored in the JASS_SUFFIX environment variable. For more information, see Chapter 6, JASS_TIMESTAMP.

Example usage: 


create_file_timestamp /usr/local/testing

disable_conf_file

Use this function to disable service configuration files. This function accepts two string values representing the directory name in which the file is located and the service configuration file name. This function disables the service configuration file by prepending a prefix of "_" (underscore) to the file name, thereby preventing its execution.

Example usage: 


disable_conf_file /etc/dfs dfstab

This example renames a file from /etc/dfs/dfstab to /etc/dfs/_dfstab.JASS.<timestamp>. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

disable_file

Use this function to disable files that cannot be stored in their original directory. For example, the /var/spool/cron/crontabs directory contains individual user crontab files. If a disabled or backed-up copy of a crontab file were stored in the crontabs directory, then the cron service would indicate an error, because there would be no user name that matched the names of the disabled or backed-up files.

To address this issue, this function creates a mirror directory with a .JASS suffix within which to store any of the disabled files. For example, if the file to be disabled is located in the /var/spool/cron/crontabs directory, this function creates a /var/spool/cron/crontabs.JASS directory into which the disabled file is moved.

The file to be disabled, as with the other disable functions, has a suffix of .JASS.<timestamp>. The difference with this function is that the disabled file is not stored in the same directory as the original file.

Example usage: 


disable_file /var/spool/cron/crontabs/uucp

In this example, the file /var/spool/cron/crontabs/uucp is moved to the
/var/spool/cron/crontabs.JASS directory and renamed as uucp.JASS.<timestamp>. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

disable_rc_file

Use this function to disable the execution of a run-control file. This function accepts two string values representing the directory name in which the script is located and the run-control script name. This function disables the script by prepending a prefix of "_" (underscore) to the file name, thereby preventing its execution by run-control framework. To be executed, a script name must begin with either an S or a K depending on its purpose as a start or kill run-control script. In addition, a suffix of .JASS.<timestamp> is appended to the disabled file.

Example usage: 


disable_rc_file /etc/rc2.d S71rpc

This example renames a file from /etc/rc2.d/S71rpc to /etc/rc2.d/_S71rpc.JASS.<timestamp>. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

is_patch_applied and is_patch_not_applied

Use these functions to determine if a patch is or is not applied to a system. These functions accept a single string value representing the patch number to check.

This value can be specified in one of two ways:

Example usage: 


is_patch_applied 123456

Example usage: 


is_patch_applied 123456-02

mkdir_dashp

Use this function to create a new directory on a target system. This function accepts a single string value representing the name of the directory to create. This function uses the -p option to mkdir so that no error is reported if the target directory exists. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

Example usage: 


mkdir_dashp /usr/local

move_a_file

Use this function to move a file from one name to another. This function requires two entries: a source file name and a destination file name. This function moves, or renames, the source file to the file name specified by the destination parameter. This function automatically adds the necessary manifest entries to permit this operation to be reversed during an undo run.

Example usage: 


move_a_file /tmp/test-file-a /tmp/test-file-b

rm_pkg

Use this function to remove Solaris OS packages from a system. The operations performed by this function are final and cannot be reversed during an undo run. The options for this function are listed in TABLE 1-6.


TABLE 1-6 rm_pkg Function Options

Option

Description

-a ask_file

The pkgrm ask file name. By default, the pkgrm ask file, noask_pkgrm, is used if no other file is specified.

-o options

The pkgrm command options

package

The package to be removed


Example usage: 


rm_pkg SUNWadmr

Using Audit Functions

Two types of audit functions are in the software: private and public. The functions defined in the audit_private.funcs file are private and not for public use. Never use the private scripts defined in this file. Only use the public scripts defined in the audit_public.funcs file.

The public functions define audit functions used in audit scripts, which are located in JASS_AUDIT_DIR. Functions defined in this file are public and can be freely used in both standard and custom audit scripts. Note that in many cases, the functions defined in this file are stubs that call functions defined in the audit_private.funcs file. These stubs were implemented to allow users to code their scripts to these public interfaces without needing to care if the underlying code will be modified or enhanced in newer releases.

Use these functions as part of audit scripts to assess components of the system's stored and runtime configurations. The following functions are public interfaces to the Solaris Security Toolkit software's audit framework.

When customizing or creating audit scripts, use the following functions to perform standard operations.

check_fileContentsExist and
check_fileContentsNotExist

Use these functions to determine if a designated file has content matching a supplied search string. These functions search a designated file to match its content with a search string. The search string can be in the form of a regular expression. These functions display a 0 for success, 1 for failure, and 255 for error condition.

You can supply the following arguments to this function:

Example usage: 


check_fileContentsExist /etc/default/inetinit "TCP_STRONG_ISS=2" 1 LOG

check_fileExists and
check_fileNotExists

Use these functions to determine if a file exists on a target system. These functions display a status of 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_fileExists /etc/inet/inetd.conf 1 LOG

check_fileGroupMatch and
check_fileGroupNoMatch

Use these functions to determine if a file belongs to a group on a target system. These functions display a status of 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_fileGroupMatch /etc/passwd sys 1 LOG

check_fileGroupMatch /etc/passwd 3 1 LOG

check_fileModeMatch and
check_fileModeNoMatch

Use these functions to determine if a file has the permissions specified on a target system. These functions display a status of 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_fileModeMatch /etc/passwd "0444" 1 LOG

check_fileModeMatch /etc/passwd "ugo=r" 1 LOG

check_fileOwnerMatch and
check_fileOwnerNoMatch

Use these functions to determine if a file belongs to a specific user on a target system. These functions display a status of 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_fileOwnerMatch /etc/passwd root 1 LOG

check_fileOwnerMatch /etc/passwd 0 1 LOG

check_fileTemplate

Use this function to determine if a file template defined by the Solaris Security Toolkit software matches its counterpart installed on a target system. For example, if you were to use this function to check the file template /etc/motd, this function would compare the contents of JASS_FILES_DIR/etc/motd with /etc/motd to determine if they were the same. If they were identical, this function would display 0 for success, 1 for failure, or 255 for any error condition. If you specify more than one file, they all must pass to get a display code of 0.

You can supply the following arguments to this function:

Example usage: 


check_fileTemplate /etc/motd 1 LOG

check_fileTypeMatch and
check_fileTypeNoMatch

Use these functions to determine if a file system object is a specific object type on a target system. These functions display a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

TABLE 1-7 lists the types detected by the software:


TABLE 1-7 File Types Detected by Using the check_fileTemplate Function

File Type

Description

b

Block special file

c

Character special file

d

Directory

D

Door

f

Regular file

l

Symbolic link

p

Named pipe (fifo)

s

Socket


Example usage: 


check_fileTypeMatch /etc/passwd f 1 LOG

check_fileTypeMatch /etc d 1 LOG

check_minimized

Use this function when a package check should only be performed on a minimized platform. This function is similar to the check_packagesNotExist function, except that its behavior is controlled by the JASS_CHECK_MINIMIZED environment variable. If a target system is not minimized, then the JASS_CHECK_MINIMIZED environment variable should be set to 0. In this case, this function does not perform any of its checks and simply displays a value of 0 with a notice indicating that a check was not run. Otherwise, this function behaves exactly as the check_packageNotExists function and displays a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_minimized SUNWatfsu 1 LOG

check_packageExists and
check_packageNotExists

Use these functions to determine if a software package is installed on a target system. These functions display a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_packageExists SUNWsshdu 1 LOG

check_patchExists and
check_patchNotExists

Use these functions to determine if a software patch is installed on a target system. These functions display a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_patchExists 123456 1 LOG

check_patchExists 123456-01 1 LOG


Note - You can specify a patch revision. If you do, then any installed revision must be equal to or greater than the revision specified. If you do not specify a revision, then this function indicates success if any version of the patch is installed.


check_processArgsMatch and
check_processArgsNoMatch

Use these functions to determine if a process is running on the system with specific runtime arguments. These functions display a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_processArgsMatch /usr/sbin/syslogd "-t" 1 LOG

check_processExists and
check_processNotExists

Use these functions to determine if a process is running on a target system. These functions display a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_processExists sshd 1 LOG

check_serviceConfigExists and
check_serviceConfigNotExists

Use these functions to determine if a service configuration file exists on a target system. These functions display a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_serviceConfigExists /etc/ssh/sshd_config 1 LOG

check_startScriptExists and
check_startScriptNotExists

Use these functions to determine if a run-control start script exists on a target system. These functions display a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_startScriptExists /etc/rc3.d/S89sshd 1 LOG

check_stopScriptExists and
check_stopScriptNotExists

Use these functions to determine if a run-control stop script exists on a target system. These functions display a 0 for success, 1 for failure, and 255 for any error condition.

You can supply the following arguments to this function:

Example usage: 


check_stopScriptExists /etc/rc2.d/K03sshd 1 LOG

finish_audit

Use this function to signal that a check script has completed all of its processing and that a score for the script must be computed. This function is typically the last entry in a check script. If you want to display a message indicating a script's termination, then pass a single string argument to this function.

Example usage: 


finish_audit


finish_audit "End of script"

 

start_audit

Use this function to call an audit script. This function is typically the first instruction in an audit script, not including comments or variable declaration. This function defines the name of the script, displays the banners, and resets the score to 0.

You can supply the following arguments to this function:

Example usage: 


start_audit disable-apache.aud "Apache" "Description of Check"

Example output: 


#--------------------------------------------------------------

# Apache

#

# Description of Check

#--------------------------------------------------------------



  Solaris Security Toolkit 4.1 Reference Manual 817-7750-10 Table Of ContentsPrevious ChapterNext ChapterBook Index


Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.