| Solaris Security Toolkit 4.2 Administration Guide |    
|
| Solaris Security Toolkit 4.2 Administration Guide |
|
| C H A P T E R 4 |
|
Reversing System Changes |
This chapter provides information and procedures for reversing (undoing) the changes made by the Solaris Security Toolkit software during hardening runs. This option provides an automated mechanism by which you can return a system to its state prior to a Solaris Security Toolkit hardening run or sequence of runs.
This chapter contains the following topics:
Each Solaris Security Toolkit hardening run creates a run directory in JASS_REPOSITORY. The names of these directories are based on the date and time the run is initiated. In addition to displaying the output to a screen, the Solaris Security Toolkit software creates a set of files in the directory to track the changes and log the operations.
The files stored in the directory track modifications performed on the system and enable the undo feature to work.
When you use the Solaris Security Toolkit software to harden a system, either in JumpStart or stand-alone mode, the software logs the changes in the JASS_REPOSITORY/jass-manifest.txt file. This file lists operations that the undo feature uses to reverse changes. The file contains information about the hardening operations implemented by the Solaris Security Toolkit software, including files created, copied, moved, or removed. In addition, this file might contain both standard and custom entries that are required when reversing more complex changes, such as software package installations. A separate jass-manifest.txt file is created for each hardening run.
|
Note - The Solaris Security Toolkit software undo feature only reverses changes for which there are entries in manifest files. |
The undo run goes through the manifest files generated during a Solaris Security Toolkit run and stored in the JASS_REPOSITORY. The run can restore the backed-up files to their original locations, depending on whether you use the backup, force, or keep option. See the following for more information on the backup, force, and keep options:
If files were not backed up during hardening, when the JASS_SAVE_BACKUP variable is defined in the user.init file as 0 or when the -c option is used, then the undo function is not available. See Requirements for Undoing System Changes for more information.
When a Solaris Security Toolkit run is undone, the associated directory is not removed. Instead, two files are created in the JASS_REPOSITORY directory: jass-undo-log.txt and reverse-jass-manifest.txt. Afterward, the run that was undone is not listed the next time jass-execute -u is executed. A hardening run can be undone only once.
Be aware of the following limitations and requirements for using the undo feature of the Solaris Security Toolkit software.
The Solaris Security Toolkit framework provides flexibility for designing and building finish scripts. The framework allows you to extend the capabilities of the Solaris Security Toolkit software to better meet the needs of your organization while also helping you to better manage the configuration of systems over their life cycles.
When customizing scripts, it is important to understand how the actions you take can affect the undo feature. To simplify customizing scripts, helper functions make the correct changes to the manifest files. (The undo feature relies on the contents of manifest files to reverse hardening runs.) In most cases, these helper functions provide what you need to customize scripts for your organization.
For a list of helper functions and information about using them, refer to the Solaris Security Toolkit 4.2 Reference Manual. Use these helper functions in place of their system command counterparts, so that undo runs can reference the related entries in manifest files.
In some cases, you might need to perform a function for which there is no helper function. In these cases, use the special function called add_to_manifest. Using this function, you can manually insert entries into manifest files without needing to call one of the helper functions. Use this special function with care, so that you protect the integrity of the system and the Solaris Security Toolkit repository. An example of when you might use this special function is when you want to add software packages that are not in Sun's pkg format. In this example, you would need to tell the undo feature how to remove the packages that were added in another format during the hardening run.
With the helper functions and the special add_to_manifest function, the Solaris Security Toolkit software provides a simple and flexible way to customize scripts and have the changes extended to undo runs.
If you make changes to a finish script's behavior without using these functions, there is no way for the Solaris Security Toolkit software to know that a change was made. Therefore, you would have to manually undo any changes that are not referenced in manifest files.
In another example, before modifying a file on the system, the original version of the file should be saved first. Outside the context of the Solaris Security Toolkit software, typically, users accomplish this task by executing the /usr/bin/cp command. However, within the context of the Solaris Security Toolkit software, if you use this command directly, the Solaris Security Toolkit software has no way of knowing that a manifest entry needs to be created. Instead of using the cp command, use the backup_file helper function. This function saves a copy of the original file, with a suffix of JASS_SUFFIX, and adds a manifest entry instructing the Solaris Security Toolkit software that a copy of the file was made. This function also causes the file checksums to be calculated. File checksums are used by the undo feature and the jass-check-sum command.
Although the jass-execute -u command automatically checks for files that were changed manually after a hardening run, sometimes you might find it helpful to use the jass-check-sum command to list and review the files that have been changed.
This command enables you to review the contents of the JASS_REPOSITORY directory and perform checksums on all of the files listed in manifest files to determine which files listed have changed since their checksums were recorded during a hardening run. Performing this check before proceeding with a forced undo run provides valuable information that might save many hours of needless troubleshooting.
The following is an example output.
The output indicates that three files were changed after the hardening run was completed.
This section describes the jass-execute -u command and options that you can use when executing an undo run.
|
Note - You cannot use the -c, -d, -a, -h, -l or -H options with the undo feature. You must provide the -b, -k, or -f option when running undo in quiet mode. |
The jass-execute -u command is the standard method for executing an undo run. This command automatically discovers any files that were manually modified since the last hardening run. If the Solaris Security Toolkit software discovers files that were manually changed after a hardening run, it asks you to choose one of the following responses:
1. Back up the most current file before restoring the original (the one that existed before the hardening run).
2. Keep the most current file, and do not restore the original file.
3. Force an overwrite to any manually changed file, which might cause data loss, and restore original file.
4. Always back up the most current file before restoring the original (the one that existed before the hardening run).
5. Always keep the most current file, and do not restore the original file.
6. Always force an overwrite to any manually changed file, which might cause data loss, and restore original file.
If you want to define how the undo command should handle any files modified since the hardening run, use the backup (-b), keep (-k), or force (-f) options when executing the undo command.
TABLE 4-1 lists command-line options you can use with undo. For detailed information about each option, see the sections that follow.
The -b option automatically backs up any files that have been manually changed since the last hardening run, then restores the files to their original state prior to the hardening run. To implement the manual changes, you must compare the restored files with the backed-up files, and reconcile the differences manually. If a file is backed up using this option, it appears similar to the following example.
The -f option reverses the changes made during a hardening run with no exceptions, even if files were manually changed after a hardening run. The undo run does not compare the saved file checksums to the current versions of the files. As a result, if you manually changed files after a hardening run, the changes would be overwritten and lost after the undo run.
It might be necessary to manually re-implement changes after the undo run completes. Furthermore, it might be necessary to reconcile differences between groups of files depending on the types of changes made.
|
Note - To help prevent these problems, use the jass-check-sum command or the -b command-line option mentioned previously. |
The -k option automatically keeps any manual changes you made to files after a hardening run, instead of restoring the original files. The -k option discovers any mismatches in files, causes a notice to be generated and logged, and does not overwrite the file with the original. The only changes reversed are those for which the saved checksums are valid.
This option is not without its drawbacks. For example, a system can be rendered into an inconsistent state if a subset of files modified by a finish script is later modified.
Consider the remove-unneeded-accounts.fin finish script. This script modifies both the /etc/passwd and /etc/shadow files on the system. If a user manually changes a password after a hardening run is finished, then the checksum associated with the /etc/shadow file does not match the value saved by the Solaris Security Toolkit software. As a result, if the keep option is used, then only the /etc/passwd file is copied back to its original state. The /etc/shadow file remains in its current form. The two files are no longer consistent.
The -o /complete/path/to/output_file option redirects the console output of jass-execute runs to a separate output_file.
This option has no affect on the logs kept in the JASS_REPOSITORY directory. This option is particularly helpful when performed over a slow terminal connection, because there can be a significant amount of output generated by a Solaris Security Toolkit undo run.
|
Note - You must provide the -b, -k, or -f option when running undo in quiet mode. |
The -q option prevents the Solaris Security Toolkit software from displaying output to the screen. This option has no affect on the logs kept in the JASS_REPOSITORY directory. Similar to the -o option, this option is particularly helpful when running the Solaris Security Toolkit through a cron job or over slow network connections.
The -m e-mail_address option instructs the Solaris Security Toolkit software to email a copy of the completed run to a specified email address. The email report is in addition to any logs generated on the system using other options.
Sometimes it is necessary to reverse the changes made during one or multiple Solaris Security Toolkit hardening runs. If you find that the changes made during a hardening run have negatively impacted your system, undo the changes.
For example, if after a hardening run you discover that a required service such as Solaris Volume Manager (SVM) was disabled, do the following:
2. Create a customized driver.
Refer to "Customizing Drivers" in Chapter 4 of the Solaris Security Toolkit 4.2 Reference Manual for instructions about customizing drivers.
3. Enable the SVM services you want to use through the JASS_SVCS_ENABLE environment variable.
Refer to "JASS_SVCS_ENABLE" in Chapter 7of the Solaris Security Toolkit 4.2 Reference Manual for instructions about using JASS_SVCS_ENABLE.
This section provides instructions for reversing changes made during one or multiple hardening runs. Note that there are limitations and requirements for effectively reversing a hardening run. See Requirements for Undoing System Changes.
|
1. Back up and reboot your system.
Back up and reboot the system before each undo run to ensure that it returns to or can be brought back to a known and working state.
2. Determine which options you want to use with the jass-execute -u command.
See Using Options With the Undo Feature.
The following instructions assume that you are using the jass-execute -u command.
3. To undo one or more hardening runs using the standard -u option, enter the following command from JASS_HOME_DIR/bin:
The Solaris Security Toolkit software collects information about each hardening run by finding all of the manifest files located in JASS_REPOSITORY. If a manifest file is empty or nonexistent, it is assumed that there are no changes to be undone and that run is omitted. In addition, if a file called jass-undo-log.txt exists in the same directory as the manifest file, it is assumed that the run has already been reversed, so that run is omitted. After the collection process is completed, the results are displayed. The following is an example output.
In this example, four separate hardening runs are found. These runs made changes to the system and have not been undone. The list of hardening runs is always presented in reverse chronological order. The first entry in the list is the most recent hardening run.
4. Review the output to determine which runs you want to undo, then enter the corresponding number.
For any entry selected, the Solaris Security Toolkit software reverses each run with an index number equal to or less than the value selected. That is, the undo run undoes the changes in the reverse order that they were originally made, starting with the most recent hardening run and continuing to the one you select. Using the previous example as a guide, if you select run 3, then the undo run first reverses changes for run 1, then moves on to reverse changes for run 2, then finishes by reversing changes to run 3.
CODE EXAMPLE 4-3 shows output generated when the undo run processes two manifest file entries.
In this example, the Solaris Security Toolkit software undoes a copy operation and removes a file that was added during the hardening run. The output of an undo run documents the actual commands that are taken to restore the system, so that the process can be clearly understood and referenced in case you need to troubleshoot a system's configuration.
If the Solaris Security Toolkit's check for files modified since the last hardening run is successful, the undo run continues until all runs and corresponding manifest files are processed and the changes reversed.
In addition to the Solaris Security Toolkit software collecting information about each hardening run by finding all of the manifest files located in JASS_REPOSITORY, the Solaris Security Toolkit software does the following:
a. Compares the checksum of each modified file.
b. Generates and logs a notice for any mismatches in the checksum files.
c. Asks you what action you want to take for these files.
5. If the undo run discovers an exception (a file that was changed after the hardening run), enter one of the options.
The following is an example output showing an exception and the choices for handling the exception.
In this example, if you choose item 1, the following output is displayed.
If you choose item 4, the following output is displayed.
After the Solaris Security Toolkit completes the selected undo operations, you should review the files, which were flagged as changed since hardening, and make any necessary system modifications. Do not reboot the system until these changes are manually reviewed as they might have left the system in an inconsistent state.
6. Reconcile any exceptions before continuing.
7. After reconciling any exceptions, reboot the system.
Rebooting the system is necessary for the modifications to the Solaris OS configuration to take effect.
| Solaris Security Toolkit 4.2 Administration Guide | 819-1402-10 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.
To 