Administering Log and Keystroke Files
Administering Log and Keystroke Files
Safeguard allows you to control what is logged, as well as when and where it is logged. To help you set up and use these log files, the topics in this section explore enabling and disabling logging, as well as how to specify the log file locations.
Safeguard includes three different types of logging; the first two are helpful for audit purposes:
- keystroke logging, also referred to as I/O logging
Keystroke logs record the user’s keystrokes and the terminal output of any sessions granted by Safeguard.
- event logging
Event logs record the details of all requests to run privileged commands. The details include what command was requested, who made the request, when the request was sent, what host the request was submitted from, and whether the request was accepted or rejected.
- error logging
You can configure some aspects of the event and keystroke logging by means of the security policy on the policy servers. What you can configure and how you configure it depends on which type of security policy you are using on your policy server -- pmpolicy or sudo.
Security policy types
Configuring keystroke logging for Safeguard for Sudo policy
Safeguard for Sudo enables event logging. Each time a sudo command is run, the policy server accepts or rejects the requested command according to the sudoers policy file and creates an event (audit) log. If enabled, the policy server records the keystroke input and terminal output for each accepted command, creating comprehensive "keystroke logs" files. With these logs, you can perform forensic-level auditing of any command that ran by means of sudo.
Event logs are captured and stored on the policy servers in /var/opt/quest/qpm4u/pmevents.db; keystroke logs are stored at /var/opt/quest/qpm4u/iolog.
You can use the iolog_dir and iolog_file policy options to reconfigure the iolog file location.
Configure the sudoers policy for keystroke logging by using the log_input and log_output defaults flags, or the LOG_INPUT and LOG_OUTPUT command tags, as follows:
Defaults log_input, log_output # keystroke logging enabled
Defaults!/sbin/reboot !log_input,!log_output # no logging for reboots
For complete I/O log records you must use both log_input and log_output.
# disable keystroke logging for the pmreplay command
ADMINS ALL = (ALL) NOLOG_INPUT:NOLOG_OUTPUT:/opt/quest/sbin/pmreplay
ADMINS is a User_Alias. See the Sudoers man page for definition of User_Alias.
Validating Sudo commands
To validate that the centrally managed policy is working, log on to a policy server (or a Sudo Plugin host) as a non-root user, run a command that is already set up in your sudoers policy file and observe the results.
Use a command you expect to work, such as:
$ sudo id
Then run a command that you know you do not have sufficient privileges to run. For instance, run a fake command, such as:
$ sudo fakecmd
When Safeguard rejects a command, it displays a message similar to this:
Sorry, user tuser is not allowed to execute ‘fakecmd’ as root on myhost.example.com.
Request rejected by Safeguard
All systems that are joined to the same policy server will have the same results based on how you have the sudoers policy file configured.
The location of the error logs for the Safeguard components, pmrun and pmmasterd, is specified using keywords in the pm.settings file. Enter the following to specify that you want the error logs written to the /var/adm directory:
Alternatively, you can enable UNIX syslog error logging in the pm.settings file, by specifying:
Use one of the following keywords to specify which syslog facility to use:
- LOG_AUTH (the default)
- LOG_LOCAL0 through LOG_LOCAL7
For example, to enable syslog error logging using the LOG_AUTH facility, enter in the pm.settings file:
See PM settings variables for more information about modifying the Safeguard configuration settings.