| Solaris Security Toolkit 4.1 Administration Guide |    
|
| Solaris Security Toolkit 4.1 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.
|
Caution - The contents of the files in the JASS_REPOSITORYshould never be modified by an administrator. |
When you use the Solaris Security Toolkit software to harden a system, either in JumpStart or standalone 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 may 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 restores the backed-up files to their original locations. If files were not backed up, then the undo function is not available.
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 appropriate 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.1 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 not a 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 first be saved. 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. Also, this function causes the file checksums to be calculated. File checksums are used both by the undo feature as well as the jass-check-sum command.
Although using 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 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 may 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 -d, -a, -h, -l or -H options with the undo feature. You must provide either -b, -k, or -f options when running undo in quiet mode. |
The jass-execute -u command is the standard 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 a response:
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 (might lose data) and restore original file.
If you want to change the default undo behavior, use the -b, -k, and -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 need to 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 may be necessary to manually re-implement changes after the undo run completes. Furthermore, it may be necessary to reconcile differences between groups of files depending on the types of changes made. 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 in jass-checksums.txt file 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 are 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 output-file option redirects the console output of jass-execute runs to a separate file, 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 is a significant amount of output generated by a Solaris Security Toolkit undo run.
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 email-address option instructs the Solaris Security Toolkit software to e-mail a copy of the completed run to an email address. The email report is in addition to any logs generated on the system using other options.
Sometimes it's 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 NFS was disabled, undo the hardening run. Then, enable NFS and repeat the hardening run with the revised security profile.
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.
Reboot and back up 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 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:
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 run(s) 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.
The following example 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.
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 compares the checksum of each modified file. Any mismatches in the checksum files cause a notice to be generated and logged. For these files, the undo run asks you what action you want to take.
5. If the undo run discovers an exception (a file that was manually 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 our example, if we choose item 1, the following output is displayed.
Take appropriate action regarding files that were manually modified after any hardening runs.
When an undo run encounters modified files and you choose to not overwrite them, reconcile these before rebooting the system.
6. Reconcile any exceptions before continuing.
7. After reconciling any exceptions, reboot the system.
Rebooting the system is necessary for the system to stop and start services available before it was hardened.
| Solaris Security Toolkit 4.1 Administration Guide | 817-7424-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.
To