Chatta subito con l'assistenza
Chat con il supporto

Safeguard for Sudo 7.2.3 - Administration Guide

Introducing Safeguard for Sudo Planning Deployment Installation and Configuration Upgrade Safeguard for Sudo System Administration Managing Security Policy Administering Log and Keystroke Files Supported sudo plugins Troubleshooting Safeguard Variables Safeguard programs Installation Packages Supported Sudoers directives Unsupported Sudo Options Safeguard for Sudo Policy Evaluation

Local logging

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:

pmmasterdlog /var/adm/pmmasterd.log 
pmrunlog /var/adm/pmrun.log

Alternatively, you can enable UNIX syslog error logging in the pm.settings file, by specifying:

syslog YES

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:

syslog YES 
facility LOG_AUTH

See PM settings variables for more information about modifying the Safeguard configuration settings.

Event logging

Event logs are enabled by default for all requests sent to the Safeguard Policy Servers. The default location of the event log file is /var/opt/quest/qpm4u/pmevents.db.

It is possible to disable logging of accepted or rejected commands on a per-user or per-command basis. One common use case is to prevent the logging of privileged commands run via cron jobs. For example, to disable logging of accepted commands as well as keystroke logging for the user operator, specify:

Defaults:operator !log_allowed, !log_input, !log_output

It is also possible to disable logging for a specific command, for example /usr/bin/id:

Defaults!/usr/bin/id !log_allowed, !log_input, !log_output

To disable logging of rejected commands, the log_denied flag can be disabled:

Defaults!/usr/bin/id !log_allowed, !log_denied, !log_input, !log_output

When disabling event logging it is important to also disable keystroke logging. Otherwise, the keystroke log will still be created but will not be referenced by the event log database.

Keystroke (I/O) logging

Once your 30-day trial license has expired, One Identity requests that you obtain a Keystroke Logging license to remain in compliance. See Safeguard licensing for details.

You can enable keystroke logging using the log_input and log_output default parameters.

Enabling log_input and log_output enables keystroke logging.

For example, to enable keystroke logging for all requests, specify:

Defaults log_input, log_output

To specify keystroke logging of output just for the root user, specify:

Defaults:root log_output

You can also override default settings by using the LOG_INPUT, LOG_OUTPUT, NOLOG_INPUT, NOLOG_OUTPUT tags in a user specification entry. For example, to suppress keystroke logging for the ls command, enter:


The location of the keystroke log file is determined by the iolog_dir and iolog_file default specifications.

The defaults are:

Defaults iolog_dir = "/var/opt/quest/qpm4u/iolog"
Defaults iolog_file = "%{user}/%{runas_user}/%{command}_%Y%m%d_%H%M_XXXXXX"

See the Sudoers man page for an explanation of the supported percent (%) escape sequences.

The trailing “XXXXXX” characters at the end of iolog_file are required; without them, no I/O log will be generated. These X’s are replaced with a unique combination of digits and letters, similar to the mktemp() function.

Sub-command logging

Sudo version 1.9.8 introduced the ability to log or intercept sub-commands spawned from the original command run by sudo. To use this feature with Safeguard for Sudo, the version of sudo installed must be 1.9.8 or higher and both the client and the policy server must be running Safeguard for Sudo 7.2.2 or above. In addition, privilege_manager_audit_plugin must be enabled in /etc/sudo.conf as follows:

Plugin privilege_manager_audit_plugin /opt/quest/libexec/

Logging sub-commands can be used to gain visibility into further commands executed by a sudo-run shell, editor or other process. When the log_subcmds sudoers setting is enabled, sudo will preload a dynamic shared object that connects back to sudo when a new process is executed. On Linux systems running sudo 1.9.11 or higher, a different method that utilizes tracing may be used instead.

For example, to enable sub-command logging for all commands:

Defaults log_subcmds

To log sub-commands only for the bash shell:

Defaults!/bin/bash log_subcmds

To log sub-commands only for the operator user:

Defaults:operator log_subcmds

If the intercept sudoers setting is enabled or the INTERCEPT tag is used with the command, in addition to logging each sub-command, a policy check is performed. If the command is not permitted by the sudoers policy, it will not be permitted to execute. If both log_subcmds and intercept are enabled, intercept takes precedence.

For example, to intercept sub-commands run via the vim editor for all users:

Defaults!/usr/bin/vim intercept

You can also override default settings by using the INTERCEPT and NOINTERCEPT tags in a user specification entry. For example, to allow the operator user to run any command but intercept sub-commands run by the zsh shell:

operator ALL=(ALL) ALL, INTERCEPT:/usr/bin/zsh

NOTE: The version of sudo distributed with RedHat system may have log_subcmds and intercept disabled. It may be necessary to install a sudo package from on RedHat systems to use these features.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione