Use the pmlogadm program to perform backup or archive operations on a policy server's event log database. Because Safeguard stores keystroke logs in individual flat files on the policy server, you may use standard Unix commands to back up or archive them. Make sure the keystroke log files are not associated with active sessions prior to backup or archive.
Disabling and enabling services
While pmlogadm can perform the backup and archive operations on a live event log database, for best results we recommend that you follow these steps prior to performing a backup or archive.
- Stop the pmserviced and pmlogsrvd services.
This example shows how to disable services on Redhat Linux systems: # service pmserviced stop
Stopping pmserviced service: done
# service pmlogsrvd stop
Stopping pmlogsrvd service: done
- Ensure there are no running pmmasterd processes:
# ps -ef | grep pmmasterd
A running pmmasterd process indicates that there may be an active Safeguard session.
This procedure also allows you to safely backup or archive any keystroke log files. Once the backup or archive operation has completed, remember to restart the pmserviced and pmlogsrvd services.
This example shows how to restart the services on Redhat Linux systems:
# service pmlogsrvd start
Starting pmlogsrvd service: done
# service pmserviced start
Starting pmserviced service: done
Backing up event logs
The pmlogadm backup command creates a clean backup copy of your event log database.
This example performs a backup of the current event log database, placing the copy in the /backup directory:
# pmlogadm backup /var/opt/quest/qpm4u/pmevents.db /backup
5 / 208 pages complete
10 / 208 pages complete
...
205 / 208 pages complete
208 / 208 pages complete
Backing up keystroke logs
Safeguard stores the keystroke logs in individual files and do not require any special commands for processing.
This example uses the unix cp command to recursively copy the keystroke logs to the /backup directory:
# cp -r /var/opt/quest/qpm4u/iolog /backup
Archiving event logs
The pmlogadm archive command creates an archive of old event logs and removes the old event logs from the current database. The following example archives logs for all events that occurred before April 1, 2014 from the current event log database, creating an archive database in the /archive/2014Q1 directory.
If you omit the --no-zip option, pmlogadm also creates a tar-gzip'ed archive of the database files.
# pmlogadm archive /var/opt/quest/qpm4u/pmevents.db 2014Q1 \
--dest-dir /archive --no-zip --before "2014-04-01 00:00:00"
Archive Job Summary
Source Log : /var/opt/quest/qpm4u/pmevents.db
Archive Name : 2014Q1
Destination Dir : /archive
Zip Archive : No
Cut off time : 2014/04/01 00:00:00
No pmlogsrvd pid file found, assuming service is not running.
X events will be archived.
Adding events to the archive.
Verifying archive.
Archive verification completed successfully. Removing events from source log.
Archive task complete.
Archiving keystroke logs
You can use the pmlog command with some carefully chosen options to get a list of keystroke logs associated with the event logs you archive. In this example, you process the list generated by pmlog, with the Unix xargs and mv commands to move the keystroke logs into the /archive/2014Q1/iolog directory.
# mkdir /archive/2014Q1/iolog
# pmlog -f /archive/2014Q1/archive.db \
-c "defined iolog && length(iolog) != 0" -p iolog \
| xargs -i{} mv {} /archive/2014Q1/iolog
The usage of the xargs command may differ depending on your platform.
Safeguard for Sudo supports loading the following sudo-compatible plugins on the policy server:
-
Approval plugin
-
Audit plugin
You can write these sudo plugins both in C and in Python.
To load a sudo audit or approval plugin on a policy server, you must configure the plugins in the sudoers policy file located in /etc/opt/quest/qpm4u/policy/sudoers by default. On a policy server that supports multiple policies, you can have different plugins configured for each policy.
Syntax
Safeguard for Sudo does not use the /etc/sudo.conf file to load modules. Safeguard for Sudo uses the sudoers policy file and it uses a slightly different syntax.
The syntax of the /etc/sudo.conf file is the following:
Plugin symbol_name plugin_file.so plugin_arguments...
The syntax of the Safeguard for Sudo sudoers policy file is the following:
Defaults plugins += "symbol_name plugin_file.so plugin_arguments..."
Where:
-
symbol_name is the name of the symbol used to look up the plugin.
-
plugin_file.so is the path to the plugin file.
-
plugin_arguments are optional arguments passed to the plugin. For Python plugins, the arguments are used to find the Python script to load.
For more information about the audit and approval plugins, see the Sudo Plugin API and Sudo Python Plugin API man pages.
Sudo version 1.9 introduced a new plugin API to apply extra restrictions to a command after it has been accepted by the sudoers policy. Safeguard for Sudo supports loading sudo-compatible approval plugins, including those written in Python, on the policy server. You can specify multiple approval plugins in the sudoers file. Safeguard for Sudo currently supports loading up to 8 Python approval plugins at once.
For more information about configuring a C-based approval plugin, see the Sudo Plugin API man page.
To configure a Python-based approval plugin in the sudoers file
To configure the sudoers policy to load the Python-based approval plugin, use the following configuration in the sudoers file:
Defaults plugins += "python_approval python_plugin.so ModulePath=<path> ClassName=<class>"
Where ModulePath is the path to the Python script that the plugin uses, and ClassName denotes what gets called within the plugin.
The following example Python approval plugin only allows users running commands during business hours, that is, from Monday to Friday between 8:00 and 17:59:59.
Defaults plugins += "python_approval python_plugin.so \
ModulePath=/root/example_approval_plugin.py \
ClassName=BusinessHoursApprovalPlugin"
Defaults plugins += "python_approval python_plugin.so \
ModulePath=/root/example_approval_plugin.py \
ClassName=BusinessHoursApprovalPlugin"
For a more detailed Python approval plugin example, see the sudo repository on GitHub.
Sudo version 1.9 introduced a new plugin API to access audit information. Safeguard for Sudo supports loading sudo-compatible audit plugins, including those written in Python, on the policy server. This can be used in a number of different ways, for example to implement custom logging or to send events from Safeguard for Sudo directly to Elasticsearch or other Logging as a Service providers.
You can specify multiple audit plugins in the sudoers file. Sudo currently supports loading 8 Python audit plugins at once.
For more information about configuring a C-based audit plugin, see the Sudo Plugin API man page.
To configure a Python-based audit plugin in the sudoers file
To configure the sudoers policy to load the Python-based audit plugin, use the following configuration in the sudoers file:
Defaults plugins += "python_audit python_plugin.so ModulePath=<path> ClassName=<class>"
The following example Python audit plugin logs the plugin accept / reject / error results to the output:
Defaults plugins += "python_audit python_plugin.so \
ModulePath=/root/example_audit_plugin.py \
ClassName=SudoAuditPlugin"
For a more detailed Python audit plugin example, see the sudo repository on GitHub.
