| Solaris Security Toolkit 4.2 Reference Manual |    
|
| Solaris Security Toolkit 4.2 Reference Manual |
|
| C H A P T E R 7 |
|
Environment Variables |
This chapter provides reference information about using environment variables. This chapter describes all of the variables used by the Solaris Security Toolkit software and provides tips and techniques for customizing their values.
This chapter contains the following topics:
The Solaris Security Toolkit software contains environment variables that provide a simple and easy way to customize and direct the behavior of its drivers and scripts. Because they are simply Bourne shell variables, all of the rules that apply to shell variables apply to Solaris Security Toolkit variables. This section provides information and recommendations for customizing and assigning variables.
Within the Solaris Security Toolkit software, there are four categories of environment variables:
|
Note - All of the categories listed can be assigned or customized. |
Before customizing variables, it is important that you understand the role of each variable type and its purpose within the Solaris Security Toolkit software. Setting and customizing variables are key to configuring the Solaris Security Toolkit software to suit your system, environment, and security policies. For detailed information about using variables, see Using Environment Variables.
In some cases, you might find that customizing the standard variables, drivers, and scripts does not address your specific needs. In these cases, you might want to develop variables, drivers, and scripts for your environment. For more information about developing variables, see Creating Environment Variables.
This section contains the following topics:
Static variables are those that are assigned a fixed or static value. This value is set before the Solaris Security Toolkit run is initiated and, unless its value is changed by the external factors, remains constant throughout the run. The value of these variables does not change depending on the context or environment in which the software is run.
Static variables are helpful when a policy setting is not dependent on external factors such as the system's type, network settings, or applications installed. For example, password aging is usually defined by a corporate or divisional policy. Assigning a static variable would apply a setting to all systems and devices within the corporation or division. Because password aging is not dependent on external factors, system administrators usually set it as a static variable.
The following is an example of assigning a static variable.
In this case, user passwords are configured to expire eight weeks after their most recent change. Furthermore, the second variable, also defined as a static variable, restricts user password changes to one per week maximum.
Dynamic variables are those that generally require greater flexibility and whose values are based on the output of commands or the contents of files. In this way, the variable is more aware of the environment in which it is run and is able to adapt to the environment more effectively. The following is an example of assigning a dynamic variable.
In this case, each of the users defined in the JASS_PASSWD (for example, JASS_ROOT_DIR/etc/passwd) file is added to the variable JASS_AT_DENY. The list of users varies depending on the system on which the Solaris Security Toolkit software is run. In this way, the software is more responsive to its environment. Similar constructions can be made to include all users except for some predefined exceptions. The following example illustrates such a case where every user on the system is added to the JASS_CRON_DENY variable with the exception of the root and ORACLE® accounts.
Taking the assigning methods a step further is the notion of complex substitution. Using this technique, more sophisticated values can be assigned to a variable based perhaps on policy, file content, or other mechanisms.
An example of how this is achieved combines assigning both static and dynamic variables. In this example, the JASS_FTPUSERS is assigned a value based both on a static list and the output of the JASS_ROOT_DIR/etc/passwd file.
In this example, the guest account is always added to the JASS_FTPUSERS variable. In addition, each user listed in JASS_PASSWD whose login name does not begin with the prefix ftp is also added to the JASS_FTPUSERS variable. Using combinations of these techniques, almost any configuration can be achieved capable of meeting the needs of most organizations.
Another sophisticated technique is to define a substitution policy based on a shell script or function. For such an example, refer to the declaration of the JASS_SHELLS variable in the Drivers/finish.init file (CODE EXAMPLE 7-1). In this case, the variable assignment is dependent on the version of the OS.
This type of functionality can be useful on minimized systems where some of the shells are not available, such as /usr/bin/bash or /usr/bin/tcsh, which exist in the SUNWbash and SUNWtcsh packages respectively. This technique helps to reduce the number of notice and warning messages generated by the software due to improper assignment of variables.
Global variables can be assigned to override the default values of many of the Solaris Security Toolkit variables. Customize the user.init file to define and assign variables for which default values are to be overridden during each Solaris Security Toolkit software run. This file is read by the driver.init program whenever a software run is initiated.
You can also assign profile-based variables to override default values. This override occurs within the profile itself, after the call to the driver.init file. Assigning variables within a profile allows variables to be updated, extended, and overridden for specific profiles rather than for all of them. For example, the file server-secure.driver contains the following profile-based variable override:
In this case, the JASS_SVCS_ENABLE variable is assigned to include entries for Telnet, FTP, dtspc, rstatd, and rpc.smserverd (100155) services. This assignment instructs the software to leave these services enabled (or to enable them if they were disabled). Normally, the default behavior of the software is to disable those services, per the JASS_SVCS_DISABLE variable.
Although, typically, the standard Solaris Security Toolkit variables provide what you need and can be customized for your system and environment, occasionally, you might need to develop new variables. Often this requirement occurs when you develop your own scripts. You can create new variables and assign them to support your site-specific or custom scripts. Creating new variables enables you to take advantage of the software's framework and modularity.
To quickly and easily build new functionality or implement additional customization, leverage the existing capabilities of the software. Use the standard variables as samples from which to develop new variables. Whenever possible, customize the standard variables rather than developing new ones. By using the software's framework in this way, you can develop and support less-customized code.
To simplify portability and configuration issues, the environment variables defined in the various .init scripts are used throughout the Solaris Security Toolkit software.
If you require additional variables, add them as environment variables to the user.init script.
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). For example, the following code adds a new variable ABC_TESTING with a default value of 0 to the user.init file.
There are times when the value of the variable should be set only if it is currently undefined. This approach is most useful when permitting an administrator to change values from the login shell. To accomplish this task, you would alter the previous code sample as follows.
This section provides descriptions of all the standard variables defined by the Solaris Security Toolkit software, listed in alphabetical order. Where applicable, recommendations and other helpful information are provided so that you can use these variables more effectively.
Within the software, the four categories of environment variables are as follows:
Each of the variables described in this section is defined in one of the following files, depending on its function within the Solaris Security Toolkit software. (As noted previously, the functions are divided into categories based on their purpose.)
For detailed information about these files, see Chapter 3.
To simplify portability and configuration issues, the environment variables defined in the various .init scripts are used throughout the Solaris Security Toolkit software.
If you require additional variables, add them as environment variables to the user.init script. For more information, see Creating Environment Variables.
|
Note - The default environment variable values used by scripts are defined in the finish.init script. |
This section presents the variables in the following organization:
Framework variables are those that are defined and used by the Solaris Security Toolkit software to either maintain configuration state or to provide core variables that are used by the software. These variables are typically global and are in the software framework, its core functions, and scripts.
You can dramatically change the behavior of the software by changing these variables; therefore, change them only when absolutely necessary. Changes should be made only by experienced administrators who clearly understand the impact of the changes and can resolve any resulting problems.
|
Note - Not all framework variables can be modified. This limitation exists to promote consistency between Solaris Security Toolkit software deployments and to aid in supporting those configurations. |
|
Caution - Neverattempt to directly change any framework variables that cannot otherwise be overridden. |
This section describes the following framework variables:
|
Note - Normally, this variable should not require modification. |
The convention used by the Solaris Security Toolkit software is to store all of the audit scripts in the Audit directory. However, for flexibility, the JASS_AUDIT_DIR environment variable is available for administrators who need to store audit scripts in different locations. By default, this variable is set to JASS_HOME_DIR/Audit.
This variable is used in audit runs only. The value of this variable determines how the Solaris Security Toolkit software performs the check_minimized function that is included in many of the audit scripts. If this variable is set to 0, which is the default value, or has no value, then the check_minimized function responds immediately without performing any of its checks. If this variable has a value of 1, the script performs its checks.
This variable is included to permit the exclusion of these checks from a software run when a system has not been minimized. Otherwise, the check_minimized functions would result in failure messages on non-minimized systems, thereby precluding an audit run passing successfully.
Starting with version 0.3 of the Solaris Security Toolkit software, the variable JASS_CONFIG_DIR was renamed to JASS_HOME_DIR to provide a clearer meaning as to its use. The JASS_CONFIG_DIR variable is deprecated and should no longer be used. See JASS_HOME_DIR.
|
Note - This environment variable is not used for systems running the Solaris 10 OS. |
This variable defines the approach used by the Solaris Security Toolkit software to disable services that are started from run-control scripts. For Solaris 9 OS, this variable is assigned the default value of conf, whereas all earlier releases default to the value of script.
|
Note - If a particular service does not use a configuration file, or it does not check for its existence prior to starting, then the software uses the script method when disabling the service. |
When the JASS_DISABLE_MODE variable is set to conf, the software disables a service by moving aside its configuration file. This approach is effective on services that first check for the existence of a configuration file prior to starting. This approach leads to a more supportable and sustainable configuration because Solaris OS patches rarely replace these disabled configuration files.
When this variable is set to script, the software disables services by moving aside their respective run-control scripts. This approach is also effective because a service is not able to run, if it is never permitted to start. This configuration is less supportable, however, because Solaris OS patches install run-control scripts, re-enabling services that were disabled.
This variable sets the number of characters printed for the host name when the JASS_DISPLAY_HOSTNAME variable is set.
|
Note - The JASS_DISPLAY_HOSTNAME variable is used only when JASS_VERBOSITY is less than or equal to 2 (Brief). |
This variable controls the display of host name information during audit runs. You can select the level of verbosity to be used by the Solaris Security Toolkit software. In single-line output modes (see JASS_VERBOSITY), you have the option of tagging each line with the host name of the system on which the software is being run. This value is the same as JASS_HOSTNAME. Including this information can be useful when processing runs from multiple systems. If this variable is set to 1, then the software prepends the host name of the target system to each line of output. Otherwise, the software does not include this information. By default, the software does not display this information.
This variable sets the number of characters printed for the script name when the JASS_DISPLAY_SCRIPTNAME variable is set.
|
Note - The JASS_DISPLAY_SCRIPTNAME variable is used only when JASS_VERBOSITY is less than or equal to 2 (Brief). |
This variable controls the display of the current script name during audit runs. You can select the level of verbosity to be used by the Solaris Security Toolkit software. In single-line output modes (see JASS_VERBOSITY), you have the option of tagging each line with the name of the current audit script being run. Including this information can be useful when attempting to determine the source of failure messages. If this variable is set to 1, then the software prepends the current audit script name to each line of output. Otherwise, the software does not include this information. By default, the software includes this information.
This variable sets the number of characters printed for the timestamp when the JASS_DISPLAY_TIMESTAMP variable is set.
|
Note - The JASS_DISPLAY_TIMESTAMP variable is used only when JASS_VERBOSITY is less than or equal to 2 (Brief). |
This variable controls the display of timestamp information during audit runs. You can select the level of verbosity to be used by the Solaris Security Toolkit software. In single-line output modes (see JASS_VERBOSITY), you have the option of tagging each line with the timestamp associated with the software run. This value is the same as JASS_TIMESTAMP. Including this information can be useful when processing multiple runs from a single system or set of systems. If this variable is set to 1, then the software prepends the timestamp of the run to each line of output. Otherwise, the software does not include this information. By default, the software does not display this information.
This variable contains the keyword-specific suffix used for file copies. This is used by the copy_files() function to obtain different files for different drivers from the JASS_FILES directory structure.
This variable specifies a list of file system objects that are copied to the target system. Specify each of the objects listed in this variable by using its absolute path name. Each object is stored in a file system hierarchy under the root directory of JASS_HOME_DIR/Files.
|
Note - JASS_FILES cannot be added to the user.init file. To change this variable, copy the relevant .driver file to a new name and modify the new file. |
|
Note - This functionality is basically equivalent to the JASS_FILES "+" function. |
File lists are added to the contents of the general file list only when the Solaris Security Toolkit software is run on a defined version of the Solaris OS. A version-specific list is created by appending the major and minor operating system version to the end of the JASS_FILES variable, separated by underscores. The Solaris Security Toolkit software currently supports the options listed in TABLE 7-1.
|
Applies to all versions of the Solaris OS, and overwrites instead of appending |
|
For example, the /etc/logadm.conf file is only applicable to the Solaris 9 OS. To install the Files/etc/logadm.conf file only on the Solaris 9 OS, use the following syntax.
You can use the JASS_FILES variable to specify files in the following ways:
The following example is from the hardening.driver:
JASS_FILES=" /etc/dt/config/Xaccess /etc/init.d/set-tmp-permissions /etc/issue /etc/motd /etc/rc2.d/S00set-tmp-permissions /etc/rc2.d/S07set-tmp-permissions /etc/syslog.conf " |
By defining the JASS_FILES environment variable to include this file, the /etc/motd file on the client is replaced by the JASS_HOME_DIR/Files/etc/motd file from the Solaris Security Toolkit software distribution. You can copy any file, directory, or symbolic link this way by simply including it in the Files directory and adding it to the JASS_FILES definition in the corresponding driver.
Host-specific files are those that are copied only if the host name of the target system matches the host name assigned to the object in the Files directory. To use this capability, simply create files in the Files directory of the following form:
In this scenario, the JASS_HOME_DIR/Files/etc/syslog.conf.HOSTNAME file is copied to JASS_ROOT_DIR/etc/syslog.conf on the target system only if its host name matches the value defined by HOSTNAME. When there is both a syslog.conf and syslog.conf.HOSTNAME, the host-specific file takes precedence.
OS release-specific files are similar in concept to host-specific files, but are copied to the target system only if the target's version of the Solaris OS matches that assigned to the object in the Files directory. To use this functionality, create files in the Files directory with the following form:
In this example, the JASS_HOME_DIR/Files/etc/syslog.conf+OS file is copied to the target as JASS_ROOT_DIR/etc/syslog.conf only if the version of the Solaris OS on the target system matches the value defined by OS.
The OS variable should mirror the output produced by the uname -r command. For example, if Solaris 8 OS were being secured, then a file with the name of JASS_HOME_DIR/Files/etc/syslog.conf+5.8 would be copied. This file would not be copied to any other OS release. The OS-specific files take precedence over generic files, but host-specific files take precedence over OS-specific files.
The JASS_FILES variable also supports OS-specific extensions. Use these extensions to specify a list of file system objects that should be copied only for certain versions of the Solaris OS. The OS-specific JASS_FILES extensions are supported for Solaris OS versions 5.5.1, 5.6, 7, 8, 9, and 10. For example, to copy a list of files only for Solaris 8 OS, define the JASS_FILES_5_8 variable and assign to it the list of files to be copied.
This section describes and illustrates how to customize the JASS_FILES environment variable. The following code examples are taken from the Drivers/config.driver file. This profile file performs basic configuration tasks on a platform. This is how the config.driver file looks at default:
The following example profile provides clear examples of how file templates, drivers, and finish scripts are used. The config.driver is configured to copy the /.cshrc and /.profile files from the JASS_HOME_DIR/Files directory onto the target platform when the driver.run function is called.
To change the contents of either of these files, modify the copies of the files located in the JASS_HOME_DIR/Files directory. If you need to add or remove file templates only, simply adjust the JASS_FILES variable accordingly. Track changes to the Solaris Security Toolkit configuration using a change-control mechanism. For more information, refer to "Maintaining Version Control", Chapter 1, Solaris Security Toolkit 4.2 Administration Guide.
The software supports OS version-specific file lists. For detailed information, see the previous section Specifying Files With the JASS_FILES Variable.
|
Note - Normally, this variable does not require modification. |
This variable points to the location of the Files directory under JASS_HOME_DIR. This directory contains all of the file system objects that can be copied to the client.
To copy objects to a system, you must list a file in a JASS_FILES variable or one of its OS-specific extensions. These objects are copied to the client during hardening runs by the install-templates.fin script. Set the JASS_FILES variable within an individual driver. This variable is not defined by any other configuration file. For other methods of copying files using this variable, see JASS_FILES. By default, this variable is set to JASS_HOME_DIR/Files.
|
Note - Normally, this variable should not require modification. |
The convention used by the Solaris Security Toolkit software is to store all finish scripts in the Finish directory. However, for flexibility, the JASS_FINISH_DIR environment variable is for storing finish scripts in different locations. By default, this variable is set to JASS_HOME_DIR/Finish.
This variable defines the location of the Solaris Security Toolkit source tree. In JumpStart mode, the JumpStart variable SI_CONFIG_DIR sets the JASS_HOME_DIR variable. In stand-alone mode, it is set by the jass-execute script, which is included in the base directory.
|
Caution - Do notchange this variable, because several components of the framework rely on this variable being set properly. |
This variable contains the host name of the system on which the Solaris Security Toolkit software is being run. This variable is set during software runs through the Solaris OS uname -n command within the driver.init script.
|
Note - This environment variable has been removed from the Solaris Security Toolkit software as of version 4.2. |
|
Note - Normally, this variable should not require modification. |
This variable defines the Solaris OS instruction set potential of the target system. Use this variable to determine if the system has the potential of operating in 32- or 64-bit mode. This task is done to provide instruction set architecture (ISA) information for use by finish scripts. The value of this variable is defined based on a check for the existence of the Solaris OS package, SUNWkvmx. If this package is installed, then the system is assumed to be 64-bit capable, and this variable is set to 64. Otherwise, the system is assumed to be only 32-bit capable, and this variable is set to 32.
|
Note - The logBanner function displays output only when JASS_VERBOSITY variable is 3 (Full) or higher and the JASS_LOG_BANNER variable is not 0. |
This variable controls the behavior of the logBanner function. The logBanner function generates all of the banner messages used by the Solaris Security Toolkit software. If this variable is set to 0, then the logBanner function responds immediately without displaying any information. Otherwise, the logBanner function displays the information passed to it as an argument. Use this variable to adjust the output of the software to better suit your needs. By default, this variable has no value and, therefore, the logBanner function operates normally.
This variable controls the behavior of the logError function. The logError function generates messages with the prefix [ERR ]. If this variable is set to 0, then the logError function responds immediately without displaying any information. Otherwise, the logError function displays the information passed to it as an argument. Use this variable to adjust the output of the software to better suit your needs. By default, this variable has no value and, therefore, the logError function operates normally.
This variable controls the behavior of the logFailure function. The logFailure function generates messages with the prefix [FAIL]. If this variable is set to 0, then the logFailure function responds immediately without displaying any information. Otherwise, the logFailure function displays the information passed to it as an argument. Use this variable to adjust the output of the software to better your needs. By default, this variable has no value and, therefore, the logFailure function operates normally.
This variable controls the behavior of the logNotice function. The logNotice function generates messages with the prefix [NOTE]. If this variable is set to 0, then the logNotice function responds immediately without displaying any information. Otherwise, the logNotice function displays the information passed to it as an argument. Use this variable to adjust the output of the software to suit your needs. By default, this variable has no value and, therefore, the logNotice function operates normally.
This variable controls the behavior of the logSuccess function. The logSuccess function generates messages with the prefix [PASS]. If this variable is set to 0, then the logSuccess function responds immediately without displaying any information. Otherwise, the logSuccess function displays the information passed to it as an argument. Use this variable to adjust the output to suit your needs. By default, this variable has no value and, therefore, the logSuccess function operates normally.
This variable controls the behavior of the logSummary function. The logSummary function generates messages with the prefix [SUMMARY]. If this variable is set to 0, then the logSummary function responds immediately without displaying any information. Otherwise, the logSummary function displays the information passed to it as an argument. Use this variable to adjust the output to suit your needs. By default, this variable has no value and, therefore, the logSummary function operates normally.
This variable controls the behavior of the logWarning function. The logWarning function generates messages with the prefix [WARN]. If this variable is set to 0, then the logWarning function responds immediately without displaying any information. Otherwise, the logWarning function displays the information passed to it as an argument. Use this variable to adjust the output to suit your needs. By default, this variable has no value and, therefore, the logWarning function operates normally.
|
This variable defines the way that the Solaris Security Toolkit software operates. This variable accepts one of the following values:
In stand-alone mode, this variable is set to APPLY by the jass-execute command. In JumpStart mode, the variable defaults to APPLY. For the purpose of this variable, APPLY refers to hardening runs.
|
Caution - Do notchange this variable, because it is set automatically. |
This variable is a global variable specifying the OS version of the client on which the Solaris Security Toolkit software is being used. This variable is set automatically in the driver.init script through the uname -r command and exported so that all other scripts can access it.
This variable determines if the system being hardened or audited is a Solaris OS system. If the system is running a generic version of Solaris OS, it is set to Generic. This variable is in the driver.init file.
|
Note - Normally, this variable should not require modification. |
The convention used by the Solaris Security Toolkit software is to store all software packages to be installed in the Packages directory. However, for flexibility, the JASS_PACKAGE_DIR variable is available to store packages in a different location. By default, in stand-alone mode, this variable is set to JASS_HOME_DIR/Packages.
In JumpStart mode, however, this variable is defined as a transient mount point, JASS_ROOT_DIR/tmp/jass-packages. The package directory, stored on the JumpStart server, is mounted as this directory on this client during a JumpStart installation.
|
Note - Normally, this variable should not require modification. |
The convention used by the Solaris Security Toolkit software is to store all of the software patches to be installed in the Patches directory. However, for flexibility, the JASS_PATCH_DIR variable is available to store patches in a different location. By default, in stand-alone mode, this variable is set to JASS_HOME_DIR/Patches.
In JumpStart mode, however, this variable is defined as a transient mount point, JASS_ROOT_DIR/tmp/jass-patches. The actual package directory, stored on the JumpStart server, is mounted as this directory on this client during a JumpStart installation.
|
This variable defines the Solaris OS package name of the Solaris Security Toolkit software. This variable has a value of SUNWjass.
|
This variable is part of the execution log and undo functions. The path specified by JASS_REPOSITORY defines the directory where the required run information is stored. This functionality facilitates the capture of information related to each script that is run, the resulting output of each, and the listing of files that were installed, modified, or removed during a run.
This variable is dynamically altered during the execution of the software. Any values assigned to this variable in any of the init files are overwritten. By default, this variable is assigned the value of:
JASS_ROOT_DIR/var/opt/JASS_PKG/run/JASS_TIMESTAMP
|
Caution - Do notchange this variable, because it is automatically set. |
This variable defines the root directory of the target's file system. For JumpStart mode, this directory is always /a. For stand-alone mode, this variable should be set to / or the root directory of the system.
Starting with Solaris Security Toolkit software version 0.2, the software automatically sets this variable's value in the jass-execute script, so manual modification is no longer required.
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable, by default, defines the root home directory for Solaris 10 OS as /root:
|
This variable is part of the execution log. This variable defines the name and absolute path to the file that stores the output generated during an audit run. This information is collected to document which scripts were executed, in addition to the output of each audit check tested during the course of the run.
Any errors or warnings generated are stored in this file. The information stored in this file is equivalent to the output displayed on the screen during an audit run. By default, this variable is set to JASS_REPOSITORY/jass-audit-log.txt.
|
This variable is part of the execution log and undo functionality. This variable is also used by the jass-check-sum program included in JASS_HOME_DIR. This variable defines the name and absolute path to the file that stores all of the checksum information used by the software. This information records the state of files both before and after modification. This information is used to determine if files changed since they were last modified by the software. This information is stored within the JASS_REPOSITORY directory structure and has a default value of:
JASS_REPOSITORY/jass-checksums.txt
|
This variable is part of the execution log. This variable defines the name and absolute path to the file that stores the output generated during an cleanup run. This information is collected to document which scripts were executed, in addition to listing any files that were installed, removed, or modified during a run.
Any errors or warnings generated are stored in this file. The information stored in this file is equivalent to the output displayed on the screen during an cleanup run. By default, this variable is set to:
JASS_REPOSITORY/jass-cleanup-log.txt
This variable's name was changed before the Solaris Security Toolkit 4.0 software release. See JASS_RUN_SCRIPT_LIST.
|
This variable is part of the execution log. This variable defines the name and absolute path to the file that stores the output generated during hardening runs. This information is collected to document which scripts are executed, in addition to listing any files that were installed, removed, or modified during a run.
Any errors or warnings generated are stored in this file. The information stored in this file is equivalent to the output displayed on the screen during a hardening run. By default, this variable is set to:
JASS_REPOSITORY/jass-install-log.txt
|
This variable is part of the execution log and undo functionality. This variable defines the name and absolute path to the file that stores the manifest information associated with a run. The manifest file records the operations conducted as part of a hardening run. This file is also used in undo runs to determine which files must be moved, and in what order, to restore a system to a previous configuration. By default, this variable is set to:
JASS_REPOSITORY/jass-manifest.txt
|
This variable is part of the execution log. This variable defines the name and absolute path to the file that stores a listing of all finish or audit scripts executed during a run. This information is collected for informational and debugging purposes and is stored within the JASS_REPOSITORY directory structure. By default, this variable is set to:
JASS_REPOSITORY/jass-script-list.txt
|
This variable is part of the execution log. This variable defines the name and absolute path to the file that stores the output generated during an undo run. This information is collected to document which scripts were executed, in addition to listing any files that were installed, removed, or modified during a run.
Any errors or warnings generated are stored in this file. The information stored in this file is equivalent to the output displayed on the screen during an undo run. By default, this variable is set to:
JASS_REPOSITORY/jass-undo-log.txt
|
This variable defines the name and absolute path to a file that holds variables saved during a run using the set/get_stored_keyword_val functions. By default, this variable is set to:
JASS_REPOSITORY/jass-values.txt
|
Note - Do not attempt to edit the JASS_REPOSITORY/jass-values.txt file. |
|
This variable is part of the execution log. This variable defines the name and absolute path to the file containing the version and associated information for a run. This file typically includes information about the version, mode, and security profile used by the Solaris Security Toolkit software during its run. This information is collected to document the manner in which the software was used on a system. By default, this variable is set to:
JASS_REPOSITORY/jass-version.txt
|
Caution - The Solaris Security Toolkit undo feature is notavailable if you define the value of JASS_SAVE_BACKUPas 0. |
This variable controls the creation of backup files during hardening runs. The default value is 1, which causes the software to create a backup copy of any file modified on the client. If the value is changed to 0, then all backup copies created during a run are removed at its completion.
Modify the user.run script if you want to prevent the creation of backup copies of files. The value in the user.run script overrides any value set in the variable.
|
This variable contains the name of the currently executing finish or audit script.
|
This variable contains a set of files holding a list of scripts that had errors during the execution of the run. By default, this variable is set to:
JASS_REPOSITORY/jass-script-errors.txt
|
This variable contains a set of files holding a list of scripts that had failures during the execution of the run. By default, this variable is set to:
JASS_REPOSITORY/jass-script-failures.txt
|
This variable contains a set of files holding a list of scripts that had notes during the execution of the run. By default, this variable is set to:
JASS_REPOSITORY/jass-script-notes.txt
|
This variable contains a set of files holding a list of scripts that had warnings during the execution of the run. By default, this variable is set to:
JASS_REPOSITORY/jass-script-warnings.txt
This variable specifies a list of finish scripts to execute on a target system when you want to use a specific driver. For each entry, make sure you provide a corresponding finish script with the same name located in the JASS_FINISH_DIR directory.
Store an audit script also in JASS_AUDIT_DIR, corresponding to each finish script that is stored in JASS_FINISH_DIR.
|
Note - JASS_SCRIPTS cannot be added to the user.init file. To change this variable, copy the relevant .driver file to a new name and modify the new file. |
The JASS_SCRIPTS variable supports OS-specific extensions. Use these extensions to specify a list of finish scripts to execute only when the target system is running certain versions of the Solaris OS. Create a version-specific list by appending the major and minor operating system versions to the end of the JASS_SCRIPTS variable, separated by underscores. The Solaris Security Toolkit software supports the options listed in TABLE 7-2.
|
Applies to all versions of the Solaris OS, and overwrites instead of appending |
|
For example, to use the disable-something.fin script only on the Solaris 9 OS, you would add the following to the driver.
In this example, assuming that the operating system is the Solaris 9 OS, the disable-something.fin script is added to the end of JASS_SCRIPTS.
To add or remove finish scripts from a driver, modify the JASS_SCRIPTS variable as needed. Drivers provide a mechanism for grouping file templates and scripts into a single security profile. These profiles allow you to logically group customization. For example, a single profile could be used to define a baseline that is applied to all of the systems within an organization. Alternatively, a profile could define the modifications that are done to secure systems operating as database servers. These profiles can be used individually or combined into more complex profiles.
JASS_SCRIPTS="print-jass-environment.fininstall-recommended-patches.fininstall-jass.finset-root-password.finset-term-type.fin" |
In this example, five different scripts are configured to run when the driver.run function is executed. (See Understanding Driver Functions and Processes for more information about driver.run.) These five scripts are grouped into the config.driver, because they represent system configuration changes that are not directly related to hardening.
|
Note - Normally, this variable should not require modification. |
This variable controls whether the Solaris Security Toolkit software runs in stand-alone or JumpStart mode. This variable defaults to 0 for JumpStart installations and 1 when the jass-execute command is used to initiate a run.
|
This variable determines which suffixes must be appended onto backup copies of files. By default, this variable is set to:
During a run, the value of the timestamp field changes to reflect the time a file is created. This action guarantees that all backup file names are unique.
This variable is dynamically altered during runs. Any value assigned to this variable in the init files is overwritten.
|
Note - Normally, this variable should not require modification. |
This variable creates the JASS_REPOSITORY directory:
/var/opt/SUNWjass/run/JASS_TIMESTAMP
As noted previously, this directory contains the logs and manifest information for each run of the Solaris Security Toolkit software. This variable contains the timestamp associated with the start of a run, and its value is maintained for the entire run. As a result, its value is unique for each run. This unique value allows information for each run to be clearly separated from all others, based on the time that the run was started. By default, this variable is set to date:
This command creates a timestamp of the form YYYYMMDDHHMMSS. For example, a run started at 1:30 a.m. on July 1, 2005 would be represented by the value 20050701013000.
This variable was renamed to JASS_OS_REVISION before the Solaris Security Toolkit 4.0 release. See JASS_OS_REVISION.
|
This variable contains information about whether the jass-execute command was started with any of the -b, -f, or -k options, or none of them. The possible values are:
This variable specifies the location of the configuration files user.init and user.run. By default, these files are stored in the JASS_HOME_DIR/Drivers directory. Use these files to customize the Solaris Security Toolkit software to meet the needs of your organization.
If you need to customize the Solaris Security Toolkit software, do so in these files to minimize the impact of Solaris Security Toolkit software upgrades in the future.
Global variables should be created and assigned either in the user.init file or within a driver. New functions or overrides of existing functions should be implemented in the user.run file. All variable or function overrides take precedence over their counterparts defined in the Solaris Security Toolkit software.
|
Caution - Do notmodify this variable directly. Instead, use the jass-executecommand with the -Voption |
This variable controls how the Solaris Security Toolkit software displays its results when running during audit runs. The software currently supports five different verbosity levels: 0 through 4. Set this variable to any of these values using the -V option with the jass-execute command.
|
Note - In hardening runs and other operations, this variable is set to 3 (Full) and normally should not be changed. |
The verbosity levels used during audit runs are as listed in TABLE 7-3.
In the least verbose mode, level 0, only a single line is displayed representing the overall result for a run. The output at this level would look like:
|
This variable defines the version of the Solaris Security Toolkit software associated with the software distribution being used. This variable documents the version of the software and permits its use with logging and other functions.
|
Note - For Solaris OS versions 9 and earlier, which do not have Solaris zones, JASS_ZONE_NAME is automatically set to global. |
For the Solaris 10 OS, which enables the use of zones, certain Solaris Security Toolkit scripts use this variable to check if they are in the global zone. Following is a list of the Finish and Audit scripts that are zone aware:
For more information about zone-aware scripts, see TABLE 1-4.
If the scripts are not running in the global zone, the scripts log that information with the logNotGlobalZone function and finish.
The JASS_ZONE_NAME variable is set in the Solaris Security Toolkit scripts at initialization by using /usr/bin/zonename. If this command does not exist, the variable is set to global.
Script behavior variables are those that are defined and used by the Solaris Security Toolkit software to affect the behavior of finish and audit scripts. The Solaris Security Toolkit software provides a robust and flexible framework for customizing its functionality to suit individual site requirements. The Toolkit software limits the amount of source code that has to be modified for users to implement site-specific customization. The script variables provide an easy to use method for altering the behavior of a script without modifying the script's source code.
These variables are defined in the JASS_HOME_DIR/Drivers/finish.init file. Although they are global, their use is typically limited to a small set of finish and audit scripts. As described earlier in this chapter, you can customize these variables using techniques such as static, dynamic, and complex assignment in either the user.init file or within an individual driver.
Tune these variables where necessary to meet organizational or site security policy and requirements. Used in this manner, the software provides the greatest value in helping you improve and sustain the security posture of your environment.
This section describes the following script behavior variables:
This variable contains a list of user accounts that should be disabled on a system. During hardening runs, these accounts are disabled by the disable-system-accounts.fin script. During audit runs, the disable-system-accounts.aud script inspects the accounts defined by this variable, to ensure that they are disabled.
By default, the following accounts are assigned to the JASS_ACCT_DISABLE variable:
This variable contains a list of user accounts that should be removed from a system. During hardening runs, these accounts are removed by the remove-unneeded-accounts.fin script. During audit runs, the remove-unneeded-accounts.aud script inspects the system to ensure that the accounts do not exist.
By default, the following accounts are assigned to the JASS_ACCT_REMOVE variable:
This variable contains a numeric value specifying the maximum number of weeks passwords remain valid before they must be changed by users. The default value for this variable is 8 (weeks). This variable is used by these scripts:
This variable contains a numeric value specifying the minimum number of weeks that must pass before users can change their passwords. This variable has a default value of 1 (week). This variable is used by these scripts:
This variable contains a numeric value specifying the number of weeks before passwords expire and users are warned. This warning is displayed to users upon login during the warning period. The default value of this variable is 1 (week).
This variable is used by these scripts:
This variable contains a list of user accounts that should be permitted to use the at and batch facilities. During hardening runs, the install-at-allow.fin script adds each user account defined by this variable to the JASS_ROOT_DIR/etc/cron.d/at.allow file, if not already present. Similarly, during audit runs, the install-at-allow.aud script determines if each user account defined by this variable is listed in the at.allow file.
|
Note - For a user account to be added or checked, it must also exist in JASS_PASSWD. |
By default, this variable contains no user accounts.
This variable contains a list of user accounts that should be prevented from using the at and batch facilities. During hardening runs, the update-at-deny.fin script adds each user account defined by this variable to the JASS_ROOT_DIR/etc/cron.d/at.deny file, if not already present. Similarly, during audit runs, the update-at-deny.aud script determines if each user account defined by this variable is listed in the at.deny file.
|
Note - For a user account to be added or checked, it must also exist in JASS_PASSWD. |
By default, this variable contains all of the user accounts defined on the system in the JASS_PASSWD file.
This variable contains a string value that represents a file name containing a banner message to be displayed to users after logging into CDE. During hardening runs, this banner is installed by the set-banner-dtlogin.fin script. During audit runs, the existence of this banner is checked by the set-banner-dtlogin.aud script. The default value of this variable is /etc/motd.
|
Note - This variable is only used for systems running Solaris OS version 2.6 through 8. |
This variable contains a string value that is used as a banner displayed to users prior to authenticating for FTP service. During hardening runs, this banner is installed by the set-banner-ftpd.fin script. During audit runs, the existence of this banner is checked by the set-banner-ftpd.aud script. The default value of this variable is \"Authorized Use Only\".
This variable contains a string value that is used as a banner displayed to clients immediately after connecting to the sendmail service. During hardening runs, this banner is installed by the set-banner-sendmail.fin script. During audit runs, the existence of this banner is checked by the set-banner-sendmail.aud script. The default value of this variable is Mail Server Ready.
This variable contains a string value that represents a file name containing a banner message to be displayed to users prior to authenticating the Secure Shell service. During hardening runs, this banner is installed by the set-banner-sshd.fin script. During audit runs, the existence of this banner is checked by the set-banner-sshd.aud script. The default value of this variable is /etc/issue.
This variable contains a string value that is used as a banner displayed to users prior to authenticating for Telnet service. During hardening runs, this banner is installed by the set-banner-telnetd.fin script. During audit runs, the existence of this banner is checked by the set-banner-telnetd.aud script. The default value of this variable is \"Authorized Use Only\".
This variable contains a string value that represents the path name and core file naming pattern used by the coreadm facility. This variable is used to configure coreadm to restrict core files generated on the system to the specified directory and name based on the file pattern defined by this variable. During hardening runs, coreadm is configured by the enable-coreadm.fin script. During audit runs, the coreadm configuration is checked by the enable-coreadm.aud script. The default value of this variable is:
/var/core/core_%n_%f_%u_%g_%t_%p
For more information on the file naming options, refer to the coreadm(1M) manual page.
This variable contains a string value that defines which users are permitted to perform checkpoint and resume functions on a system. During hardening runs, this restriction is implemented by the set-power-restrictions.fin script. During audit runs, this restriction is checked by the set-power-restrictions.aud script. The default value of this variable is "-", indicating that only the root account is permitted to perform these management functions. For more information, see the /etc/default/power information in Chapter 3.
This variable contains a list of user accounts that should be permitted to use the cron facility. During hardening runs, the update-cron-allow.fin script adds each user defined by this variable to the JASS_ROOT_DIR/etc/cron.d/cron.allow file, if not already present. Similarly, during audit runs, the update-cron-allow.aud script determines if each user defined by this variable is listed in the cron.allow file.
|
Note - For a user account to be added or checked, it must also exist in JASS_PASSWD. |
By default, this variable contains only the root account.
This variable contains a list of user accounts that should be prevented from using the cron facility. During hardening runs, the update-cron-deny.fin script adds each user defined by this variable to the JASS_ROOT_DIR/etc/cron.d/cron.deny file, if not already present. Similarly, during audit runs, the update-cron-deny.aud script determines if each user defined by this variable is listed in the cron.deny file.
|
Note - For a user account to be added or checked, it must also exist in JASS_PASSWD. |
By default, this variable contains all of the user accounts defined in the JASS_PASSWD file with user identifiers less than 100 and greater than 60000. Typically, the ranges below 100 and above 60000 are reserved for administrative access. Note that by default, the root account is explicitly excluded from this list.
This variable contains a numeric value representing the maximum size, in blocks, that the cron facility log file can be before it is rotated. During hardening runs, this setting is installed by the update-cron-log-size.fin script. During audit runs, this setting is checked by the update-cron-log-size.aud script. The default value of this variable is 20480 (or 20 megabytes). This size is an increase over the default Solaris OS value of 1024 (or 0.5 megabytes).
This variable stores the allowed password encryption algorithms. The values can be one or more of the following:
This variable contains the default cryptographic algorithm that is configured for the system. The default setting is "1", corresponding to BSD MD5. This variable is used in the set-flexible-crypt.fin script to modify the Solaris OS default in the /etc/security/crypt.conf file for the CRYPT_DEFAULT variable.
This variable tells the Solaris Security Toolkit whether to force the changing of all passwords after a change in cryptographic settings. If set to 1, the set-flexible-crypt.fin script uses the passwd -f command to force all users to change their passwords at the next login. The defaults are:
This variable contains a string value representing the absolute path to the FixModes software distribution, if present. If the FixModes software is installed from the software distribution by the Solaris Security Toolkit, it is installed into the directory defined by this variable. During hardening runs, this variable is used by the install-fix-modes.fin script to install and run the FixModes software. During audit runs, the FixModes software is run by the install-fix-modes.aud script. The default value of this variable is /opt.
This variable contains a list of options that are passed to the FixModes software when it is run during hardening runs from the install-fix-modes.fin script. This variable is not used during audit runs. By default, no options are specified by this variable.
This variable contains a numeric (octal) value that represents the file creation mask (umask) to be used by the FTP service. During hardening runs, this setting is installed by the set-ftpd-umask.fin script. During audit runs, this setting is checked by the set-ftpd-umask.aud script. The default value of this variable is 022.
This variable contains a list of user accounts that should be prevented from using the FTP service. During hardening runs, the install-ftpusers.fin script adds each user defined by this variable to one of the following:
For the Solaris 8 OS or earlier, the JASS_ROOT_DIR/etc/ftpusers file
For the Solaris 9 or 10 OS, the JASS_ROOT_DIR/etc/ftpd/ftpusers file if not already present
Similarly, during audit runs, the install-ftpusers.aud script determines if each user account defined by this variable is listed in the ftpusers file. By default, this variable contains all of the user accounts defined in the JASS_PASSWD file with user identifiers less than 100 and greater than 60000. Typically the ranges below 100 and above 60000 are reserved for administrative access.
|
Note - This variable is not used on systems running the Solaris 10 OS, because run-control scripts are managed by the Service Management Facility in the Solaris 10 OS. |
This variable contains a Boolean value that determines whether the kill run-control scripts should be disabled or simply left in place when a service is disabled. The start run-control scripts are always disabled. Some administrators prefer to have the kill scripts left in place so that any services that are started manually can be properly terminated during a system shutdown or reboot. By default, this variable is set to 1 indicating that the kill run-control scripts should be disabled. Setting this variable to 0 configures the software to ignore kill run-control scripts.
This variable contains a numeric value specifying the number of consecutive failed login attempts that can occur before the login process logs the failure and terminates the connection, and, on systems running the Solaris 10 OS, locks the account to prevent further login attempts. During hardening runs, this setting is installed by the set-login-retries.fin script. During audit runs, the set-login-retries.aud script checks that this setting is installed. By default, this variable has a value of 3.
|
Note - This variable is not used for systems running the Solaris 10 OS, because the /usr/bin/digest command provides MD5 functionality in the Solaris 10 OS. |
This variable contains a string value representing the absolute path to the MD5 software distribution, if present. If the MD5 software is installed from the software distribution by the Solaris Security Toolkit, it is installed into the directory defined by this variable. During hardening runs, this variable is used by the install-md5.fin script to install the MD5 software. During audit runs, install-md5.aud script checks for the existence of the MD5 software at the location defined by this variable. The default value of this variable is /opt.
This variable controls the display of information for novice Solaris Security Toolkit users. This variable provides additional guidance for less-experienced administrators. The default is 1, which means you are a novice user. You can disable this capability by setting the JASS_NOVICE_USER variable to 0 (zero) in the JASS_HOME_DIR/Drivers/user.init file.
Unless otherwise specified, the JASS_PASS_ environment variables listed in this section are used by the set-strict-password-checks.[fin|aud] scripts. They are used by the Solaris Security Toolkit software to modify and audit the values in the /etc/default/passwd file of the corresponding variables without the JASS_PASS_ prefix in the Solaris 10 OS. Refer to the passwd(1) man page for more information about the basic variables (without the JASS_PASS_ prefix).
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the directory where the generated dictionary databases reside. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable can contain a list of comma-separated dictionary files, such as JASS_PASS_DICTIONLIST=file1,file2,file3. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the HISTORY value for a specific driver and is used to check password history on a driver by the enable-password-history.fin and enable-password-history.aud scripts. The defaults are:
This variable contains a numeric value specifying the minimum length of a user password. The default value for this variable is 8 (characters). This variable is used by the set-user-password-reqs.[fin|aud] scripts
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the maximum number of allowable consecutive repeating characters in a password. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the minimum number of alpha characters required in a password. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the minimum differences required between an old and a new password. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the minimum number of digits required for a password. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - If JASS_PASS_MINNONALPHA is set, the Solaris Security Toolkit uses that value, and ignores JASS_PASS_MINDIGIT and JASS_PASS_MINSPECIAL. |
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the minimum number of lower-case letters required. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the minimum number of non-alpha, including numeric and special, characters required for a password. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - If JASS_PASS_MINNONALPHA is set, the Solaris Security Toolkit uses that value, and ignores JASS_PASS_MINDIGIT and JASS_PASS_MINSPECIAL. |
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the minimum number of special, non-alpha and non-digit, characters required for a password. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - If JASS_PASS_MINNONALPHA is set, the Solaris Security Toolkit uses that value, and ignores JASS_PASS_MINDIGIT and JASS_PASS_MINSPECIAL. |
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable contains the minimum number of upper-case letters required for a password. The defaults are:
(See JASS_PASS_ Environment Variables for more information.)
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable is used to enable or disable checking the password against the login name. The default value for all the drivers is YES, which means checking is enabled. (See JASS_PASS_ Environment Variables for more information.)
|
Note - This variable is used only for systems running the Solaris 10 OS. |
This variable is used to determine if white-space characters are allowed in passwords. The default value for all the drivers is YES, which means white-space characters are allowed. (See JASS_PASS_ Environment Variables for more information.)
This variable contains a string value that specifies the location of the password file on the target system. This variable is used in many of the scripts and for dynamic assignment of many variables. This variable has a default value of:
This variable contains a string value that defines which users are permitted to perform power management functions on a system. During hardening runs, this restriction is implemented by the set-power-restrictions.fin script. During audit runs, this restriction is checked by the set-power-restrictions.aud script. The default value of this variable is "-", indicating that only the root account is permitted to perform these management functions. For more information, see the /etc/default/power information in Chapter 3.
This variable contains a string value that specifies options to be passed to the patchadd or installpatch commands when installing a Solaris Recommended and Security Patch Cluster on a system. For information on available options, refer to the patchadd(1M) manual page or the installpatch program code. During hardening runs, this variable is used by the install-recommended-patches.fin script when installing the patch cluster on the system. This variable is not used during audit runs. By default, no options are assigned to this variable.
This variable contains a string value that specifies the file where the list of .rhosts or hosts.equiv files found on the system are stored. This variable is used during hardening runs by the print-rhosts.fin script. This variable is not used during audit runs. By default, no file name is assigned to this variable. As a result, the output of the print-rhosts.fin script is displayed on the screen.
This variable contains a numeric value that is used as the root user's primary group identifier value. During hardening runs, this setting is installed by the set-root-group.fin script. During audit runs, this setting is checked by the set-root-group.aud script. By default, this value is set to 0 (or root). This value overrides the Solaris OS default value of 1 (or other).
This variable contains a string value that is used as the encrypted password for the root account. During hardening runs, this setting is installed by the set-root-password.fin script. During audit runs, this setting is checked by the set-root-password.aud script. By default, this variable is set to:
This encrypted string equates to the clear-text string t00lk1t.
This variable contains a string value specifying options to be used with the sadmind daemon that is executed from the inetd process. During hardening runs, this setting is installed by the install-sadmind-options.fin script. During audit runs, these settings are checked by the install-sadmind-options.aud script. By default, this variable has a value of -S 2 to instruct the sadmind daemon to use strong authentication (AUTH_DES) when communicating with clients.
|
Note - Due to changes in sendmail versions and configurations, this variable is used only for Solaris 8 OS. Other mechanisms are used for newer and earlier Solaris OS versions to achieve the same goal. See disable-sendmail.fin for more information. |
This variable contains a string value specifying options to be used by the sendmail daemon to determine its operation. During hardening runs, the disable-sendmail.fin script configures the daemon for the operation specified by this variable. During audit runs, the disable-sendmail.aud script checks to ensure that the sendmail daemon is configured for the correct operation. The default value of this variable is \"\". This value indicates that the sendmail daemon should operate in queue-processing mode only. This value overrides the default value where the sendmail daemon is configured to operate as a daemon and receive incoming mail.
This variable contains a string value that specifies the file where the list of set-group-id files found on the system are stored. This variable is used during hardening runs by the print-sgid-files.fin script. This variable is not used during audit runs. By default, no file name is assigned to this variable. As a result, the output of the print-sgid-files.fin script is displayed on the screen.
This variable contains a list of shells to add to the JASS_ROOT_DIR/etc/shells file. During hardening runs, the install-shells.fin script adds each shell defined by this variable to the JASS_ROOT_DIR/etc/shells file, if not already present. Similarly, during audit runs, the install-shells.aud script determines if each shell defined by this variable is listed in the shells file.
The default values for this variable are as follows:
For Solaris 8 OS and later, the following shells are added to the default value:
This variable contains a string value that specifies the file where the list of set-user-id files found on the system are stored. This variable is used during hardening runs by the print-suid-files.fin script. This variable is not used during audit runs. By default, no file name is assigned to this variable. As a result, the output of the print-suid-files.fin script is displayed on the screen.
This variable contains a string value that defines which users are permitted to perform system suspend or resume functions. During hardening runs, this restriction is implemented by the set-sys-suspend-restrictions.fin script. During audit runs, this restriction is checked by the set-sys-suspend-restrictions.aud script. The default value of this variable is "-", indicating that only the root account is permitted to perform these management functions. For more information, refer to the /etc/default/sys-suspend file.
For the Solaris 10 OS, this variable contains a list of SMF-ready services under inetd control that you want to disable. The JASS_SVCS_DISABLE script disables all services on the list that are SMF ready and that are installed on the system. The entries on this list must be in the form of the FMRI listed in TABLE 1-1 in Chapter 1. This list can also contain legacy non-SMF services. For these to have any effect, the service must be defined in the JASS_ROOT_DIR/etc/inet/inetd.conf file, otherwise the entry is ignored.
For Solaris OS versions earlier than 10, this variable simplifies the removal of different services from the JASS_ROOT_DIR/etc/inet/inetd.conf file. During hardening runs, the update-inetd-conf.fin script disables each inetd service defined by this variable, unless it is also listed in the JASS_SVCS_ENABLE variable. Similarly, during audit runs, the update-inetd-conf.aud script determines that the correct inetd services are disabled on the system. By default, the list of services disabled by this variable includes all of the entries that are provided by default with the Solaris OS.
The JASS_SVCS_DISABLE and JASS_SVCS_ENABLE variables provide a straightforward and easy-to-use mechanism for modifying the default behavior of update-inetd-conf.fin without requiring any modifications to the script itself. The four configuration possibilities for modifying these variables are as follows:
JASS_SVCS_ENABLE (not defined)
This example is the default case for backward compatibility with older versions of the Solaris Security Toolkit software. In this case, the services listed in JASS_SVCS_DISABLE are disabled when the update-inetd-conf.fin script is run.
JASS_SVCS_DISABLE (not defined)
Only services listed in JASS_SVCS_ENABLE are left enabled. All other services, including those that are not Sun-specific, are disabled. This example permits the implementation of the principle that all that is not explicitly permitted is denied.
The services in JASS_SVCS_DISABLE are disabled and JASS_SVCS_ENABLE are left enabled. Services not covered in the list are unaffected. If a service is listed in both JASS_SVCS_ENABLE and JASS_SVCS_DISABLE, then it is enabled because JASS_SVCS_ENABLE takes precedence.
JASS_SVCS_DISABLE (not defined)
JASS_SVCS_ENABLE (not defined)
In this example, none of the services' states are changed, because there is no explicit direction defined.
For the Solaris 10 OS, this variable contains a list of SMF-ready services under inetd control that you want to enable. The entries on this list must be in the form of the FMRI listed in TABLE 1-1 in Chapter 1. CODE EXAMPLE 7-2 shows an example of code to add to the user.init file to enable rlogin for systems running the Solaris 10 OS. This list can also contain legacy non-SMF services. For these to have any effect, the service must be defined in the JASS_ROOT_DIR/etc/inet/inetd.conf file, otherwise the entry is ignored.
For Solaris OS versions earlier than 10, this variable contains a list of inetd services that are expected to be enabled on a system. During hardening runs, the update-inetd-conf.fin finish script enables any service listed in this variable that is currently disabled. If the service is already enabled, no action is taken. During audit runs, the update-inetd-conf.aud script determines if the services defined by this variable are enabled on the system. By default, this variable contains no services. As a result, the behavior of the update-inetd-conf.fin script and update-inetd-conf.aud script is controlled solely by the contents of the JASS_SVCS_DISABLE variable.
|
Note - Adjust this variable to ensure that it is large enough to meet the current and expected /tmp needs for system functions and applications running on the system. |
This variable contains a string value representing the amount of space to allocate to the /tmp (tmpfs) file system. During hardening runs, this setting is installed by the set-tmpfs-limit.fin script. During audit runs, this setting is checked by the set-tmpfs-limit.aud script. This variable has a default value of 512 megabytes.
This variable contains a numeric (octal) value that represents the file creation mask (umask). During hardening runs, this setting is used by the set-system-umask.fin and set-user-umask.fin scripts. During audit runs, this setting is checked by the set-system-umask.aud and set-user-umask.aud scripts. The default value of this variable is 022.
This variable contains a string value that specifies the file where the list of unowned files found on the system are stored. A file is considered unowned if its user or group assignment does not correspond to a valid user or group on the system. This variable is used during hardening runs by the print-unowned-objects.fin script. This variable is not used during audit runs. By default, no file name is assigned to this variable. As a result, the output of the print-unowned-objects.fin script is displayed on the screen.
This variable contains a string value that specifies the file where the list of world-writable files found on the system are stored. This variable is used during hardening runs by the print-world-writable-objects.fin script. This variable is not used during audit runs. By default, no file name is assigned to this variable. As a result, the output of the print-world-writable-objects.fin script is displayed on the screen.
JumpStart mode variables are those that are defined and used by the Solaris Security Toolkit software solely when operating in JumpStart mode. These variables facilitate the use of the Solaris Security Toolkit software either as a JumpStart framework or integrated as part of a larger build environment. These variables are mentioned separately because they are relevant only during a JumpStart installation.
These variables are defined in the JASS_HOME_DIR/Drivers/user.init file. They are in the user.init file because they typically require modification in contrast to most of the other variables that can be used with no modification.
|
Note - In some cases, such as with multihomed JumpStart servers, special customization might be required. |
Tune these variables where necessary to best suit the environment in which the Solaris Security Toolkit software is used.
This section describes the following JumpStart mode variables:
This variable defines the named resource or location where the Solaris Security Toolkit software expects to find the software packages that it might be required to install onto a client. This resource is defined as an NFS path of the form: host name:/path/to/software. This resource is mounted to JASS_PACKAGE_DIR by the mount_filesystems function during the execution of the driver.run script.
The location of this resource must be specified by host name or IP address, and the complete path must be listed to provide the NFS daemon enough information to mount the directory during a run. Because a host name or IP address can be specified in the value of the environment variable, it often requires modification.
The Solaris Security Toolkit software attempts to configure the correct host name and directory path automatically; however, this automatic configuration might not be applicable to your environment. By default, this variable is set to:
The HOSTNAME variable is dynamically assigned to the address of the NFS server from which the client has mounted the /cdrom file system.
This variable defines the named resource or location where the Solaris Security Toolkit software should expect to find the software patches that it may be required to install onto the client. This resource is defined as an NFS path of the form: host name:/path/to/patches. This resource is mounted to JASS_PATCH_DIR by the mount_filesystems function during the execution of the driver.run script.
The location of this resource must be specified by host name or IP address, and the complete path must be listed to provide the NFS daemon enough information to mount the directory during the Toolkit run. Because a host name or IP address can be specified in the value of the environment variable, it often requires modification.
The Solaris Security Toolkit software attempts to configure the correct host name and directory path automatically; however, this automatic configuration might not be applicable to your environment. By default, this variable is set to:
The HOSTNAME variable is dynamically assigned to the address of the NFS server from which the client has mounted the /cdrom file system.
| Solaris Security Toolkit 4.2 Reference Manual | 819-1503-10 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.
