To test whether or not you are in a non-global zone in a Solaris Security Toolkit script, you can check the Solaris Security Toolkit 4. Running processes, installed software, and the configurations of non-global zones are audited separately from those of the global zone. For example, an audit of an NGZ, which detected an unauthorized process running, would trigger an NGZ audit failure, not a global zone audit failure.
Similarly, when a global zone is audited, any security violations detected would generate global zone security violations, not NGZ violations. The only overlap between a global and non-global zone audit occurs during a BART review of the global zone. When reviewing these NGZ file systems from the global zone, security violations relevant to the NGZ might be reported on the global zone.
If the Solaris Security Toolkit scripts are not running in the global zone, the scripts log that information with the logNotGlobalZone function and finish. Some Solaris Security Toolkit scripts that are zone aware, such as enable-bsm. If you run such scripts without taking these actions, you are prompted and given instructions to take the required actions to make full use of these capabilities.
In other words, some actions require a kernel module to work. In this case, you need to load the module from the global zone, and then you can use it in the non-global zone. Until you do that, the actions are not performed.
You might need to configure rpcbind to start manually, depending on your system's configuration. Verify that rpcbind is running by using the pgrep command. Use the following form of the pgrep command for systems running the Solaris 10 OS where you have a global zone with child zones, so that you do not receive child zone processes. If you receive a process-id you know that rpcbind is running.
Because this book is designed to be useful to people with varying degrees of experience or knowledge of security, your experience and knowledge will determine how you use this book. This manual contains reference information about the software components and is structured as follows:. Chapter 1 is an introduction to how to use Solaris Security Toolkit 4. Chapter 2 provides reference information for using, adding, modifying, and removing framework functions.
Framework functions provide flexibility for you to change the behavior of the Solaris Security Toolkit software without modifying source code. Chapter 3 provides reference information about for using, modifying, and customizing the file templates included in the Solaris Security Toolkit software. Chapter 4 provides reference information about using, adding, modifying, and removing drivers. This chapter describes the drivers used by the Solaris Security Toolkit software to harden, minimize, and audit Solaris OS systems.
Chapter 5 provides reference information about using, adding, modifying, and removing finish scripts. This chapter describes the scripts used by the Solaris Security Toolkit software to harden and minimize Solaris OS systems. Chapter 6 provides reference information for using, adding, modifying, and removing audit scripts. Chapter 7 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.
Use this function to copy a symbolic link to the target platform. This function takes two arguments: a source link name and a destination file name. This function creates a new symbolic link based on the source link specified using the new file name passed as the destination parameter. This function uses the following copy functions to ensure that the changes made can be reversed during an undo run:. This function is capable of copying regular files, directories, and symbolic links. This function extends capability by permitting the selective copy of files based on tags appended to their file names that contain the values specified by environment variables.
See Chapter 7 for detailed information about all of the environment variables. The files that are copied by this function are selected by the following criteria, which are listed in the order of precedence used to match. For example, if a host-specific and generic file both exist, the host-specific file is used if the name of a target system matches the host name defined by the host-specific file.
In this option, the software copies the file to a target system. Use this function to create an empty file on a target system. This function uses a combination of the touch , chown , and chmod commands to create an empty file with a specific owner, group, and set of permissions. Note - This function does not adjust permissions or ownerships on a file that exists. This function creates a file with specific permissions.
Follows syntax of chown 1 and accepts user and user:group. Follows syntax of chmod 1 and accepts perms. Use this function to create a unique timestamp value for a given file and for all file backup operations. This function is useful for creating a backup of a file that has already been backed up when a unique suffix value is needed. Use this function to disable service configuration files. This function accepts two string values representing the directory name in which the file is located and the service configuration file name.
Use this function to disable files that cannot be stored in their original directory. If a disabled or backed-up copy of a crontab file were stored in the crontabs directory, then the cron service would indicate an error, because there would be no user name that matched the names of the disabled or backed-up files.
To address this issue, this function creates a mirror directory with a. JASS suffix within which to store any of the disabled files. JASS directory into which the disabled file is moved. The file to be disabled, as with the other disable functions, has a suffix of. However, using this function, the disabled file is not stored in the same directory as the original file. JASS directory and renamed as uucp. Use this function to disable the execution of a run-control file.
This function accepts two string values representing the directory name in which the script is located and the run-control script name. To be executed, a script name must begin with either an S or a K depending on its purpose as a start or kill run-control script. In addition, a suffix of. Use this function to find the most recent, still active Solaris Security Toolkit run with a given keyword-value pair as specified.
This function searches through all Solaris Security Toolkit runs on the system that have not been undone. If none of these runs have used this command, nothing is returned. Returns : Prints the timestamp of the most recent active run using that script and keyword-value pair, or "" if no such run was found. Returns : Expanded file name, or empty if no file name matched. Use this function to retrieve a stored keyword-value pair from a saved file. Returns : 0 - Keyword was found.
This function is useful in both audit and finish scripts. See enable-account-lockout. Use these functions to determine if a patch is applied to a system. These functions accept a single string value representing the patch number to check. Use this function to determine whether an SMF service is enabled. Returns : 0 - Service is enabled or will be enabled after reboot. Use this function to determine whether an SMF service is installed.
In stand-alone mode, an SMF command does the verification. In JumpStart mode, the verification is done by searching the service manifest. Returns : 0 - Service is installed stand-alone mode , or the service manifest exists JumpStart mode. Use this function to determine whether an SMF service is running. Returns : 0 - Service is running 1 - Service is not running.
Note - Use this function only for systems running the Solaris 10 OS. Use this function to determine whether a user account exists. Returns : 0 - User account exists 1 - User account does not exist. Use this function to check if a user account is locked in the password file. Returns : 0 - User account is locked 1 - User account is not locked.
Use this function to check whether a user account has a password set. When "NP" no password is returned from this function, then the user has no password defined and could be able to log in without one. Whether the user can actually log in without a password, depends on how the user is logging in and what the security restrictions are of that login mechanism. For example, Secure Shell is configured, by default, to not allow a user who does not have a password to log in.
Returns : 0 - User account is in the password file 1 - User account is not in the password file. Use this function to create a symbolic file link. Use this function to create a new directory on a target system. This function accepts a single string value representing the name of the directory to create.
This function uses the -p option to mkdir so that no error is reported if the target directory exists. Use this function to move a file from one name to another. This function requires two entries: a source file name and a destination file name. This function moves, or renames, the source file to the file name specified by the destination parameter.
Use this function to remove Solaris OS packages from a system. The operations performed by this function are final and cannot be reversed during an undo run. Use this function to set a property value for an SMF service.
Use this function to set a stored keyword-value pair to a saved file. Returns : 0 - Keyword is set. If a keyword that already exists in the file is being set, the old value is overwritten 1 - Problem writing to the file..
Use this function to unlock a user account. Use this function to write an instruction to run the inetconv 1M command in the upgrade file, which is run after rebooting. The inetconv command imports inetd. Use this function to issue logWarning commands about any files in the Solaris Security Toolkit distribution that have not been modified by the user. Because these files can be installed by the Solaris Security Toolkit, with unpredictable results if not fully configured, you should check these files to ensure the files are what you expect.
Modifying the file, or having a customer version not shipped in the distribution produces no warning. If the value is null, nothing is written. Two types of audit functions are provided in the software: private and public. Never use the private scripts defined in this file.
Functions defined in this file are public and can be freely used in both standard and custom audit scripts. These stubs were implemented to allow users to code their scripts to these public interfaces without needing to care if the underlying code is modified or enhanced in newer releases. Use these functions as part of audit scripts to assess components of the system's stored and runtime configurations.
The following functions are public interfaces to the Solaris Security Toolkit software's audit framework. When customizing or creating audit scripts, use the following functions to perform standard operations.
Use these functions to determine if a designated file has content matching a supplied search string. The search string can be in the form of a regular expression. These functions display a 0 for success, 1 for failure, and for an error condition. Use these functions to determine if a file exists on a target system.
These functions display a status of 0 for success, 1 for failure, and for any error condition. Use these functions to determine if a file belongs to a group on a target system. This file stores all site- or organization-specific functions, including those that override any Solaris Security Toolkit software default functions. By default, this file does not exist and must be manually created by the user if this functionality is needed.
This capability allows you to extend or enhance the functionality of the software by implementing new functions or customizing existing ones to better suit your environment.
This file is similar to the user. In JumpStart mode, the driver. This routine mounts the following directories onto the JumpStart client:. If other file system mount points are required, use the user. This routine is JumpStart mode specific and is not executed during stand-alone mode runs.
After the software establishes its foundation by loading common functions, initializing environment variables, and mounting file systems if needed , it is ready to begin its work.
Whether performing a hardening or audit operation, the software assembles a complete list of file templates to be copied to or verified on a target system. Note that both the global and OS environment variables are optional, and either or none can be defined.
In hardening runs, this script takes the contents of the resulting list and copies it to a target system before other finish scripts are run. In audit runs, the install-templates.
In hardening runs, each finish script is executed in turn. In audit runs, some additional processing must be done first. The Solaris Security Toolkit software automatically changes the file name extension from.
After this alteration is made, the software executes each audit script in turn. The output of the scripts is processed in one or more of the following ways:. In audit runs, after all of operations are completed for a driver, the software calculates the driver's total score.
This score denotes the status of the driver and is part of the grand total if multiple drivers are called. If only one driver is used, then this total and the grand total are the same value. The score is zero if all of the checks passed. If any checks fail, the score is a number representing how many checks or subchecks fail. When operating in JumpStart mode, after all operations are completed for a driver, the software unmounts those file systems mounted during the process Mount File Systems to JumpStart Client.
This functionality typically marks the end of a JumpStart client's installation. At this point, control returns to the calling driver. The driver can either exit and end the run or it can call other drivers and start new processing. Modifying the Solaris Security Toolkit drivers is one of the tasks done most often because each organization's policies, standards, and application requirements differ, even if only slightly.
For this reason, the Solaris Security Toolkit software supports the ability to customize tasks undertaken by a driver. If your system or application requires some of the services and daemons that are disabled by the selected driver, or if you want to enable any of the inactive scripts, do so before executing the Solaris Security Toolkit software. Similarly, if there are services that must remain enabled, and the selected driver disables them, override the selected driver's configuration before executing the selected driver in the Solaris Security Toolkit software.
Review the configuration of the software and make all necessary customization before changing the system's configuration. This approach is more effective than discovering that changes must be reversed and reapplied using a different configuration. There are two primary ways in which services can be disabled using the Solaris Security Toolkit software. This approach is one of the most common ways to customize drivers.
0コメント