Chapter 13. Configuring Subsystem Logs
For an overview on logs, see the Logs section under the Certificate System Architecture Overview section in the Red Hat Certificate System 9 Planning, Installation and Deployment Guide (Common Criteria Edition).
For log configuration during the installation and additional information, see the Configuring Logs section in the Red Hat Certificate System 9 Planning, Installation and Deployment Guide (Common Criteria Edition).
13.1. Managing Logs
The Certificate System subsystem log files record events related to operations within that specific subsystem instance. For each subsystem, different logs are kept for issues such as installation, access, and web servers.
All subsystems have similar log configuration, options, and administrative paths.
13.1.1. Configuring Logs in the Console
Logs can be configured through the subsystem Console. Specialized logs, such as signed audit logs and custom logs, can also be created through the Console or configuration file.
- In the navigation tree of the Configuration tab, select Log.
- The Log Event Listener Management tab lists the currently configured listeners.To create a new log instance, click Add, and select a module plug-in from the list in the Select Log Event Listener Plug-in Implementation window.
- Set or modify the fields in the Log Event Listener Editor window. The different parameters are listed in Table 13.1, “Log Event Listener Fields”.
Table 13.1. Log Event Listener Fields
|Log Event Listener ID||Gives the unique name that identifies the listener. The names can have any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-), but it cannot contain other characters or spaces.|
|type||Gives the type of log file. system creates error and system logs; transaction records audit logs.|
|enabled|| Sets whether the log is active. Only enabled logs actually record events. The value is either |
|level||Sets the log level in the text field. The level must be manually entered in the field; there is no selection menu. The choices are Debug, Information, Warning, Failure, Misconfiguration, Catastrophe, and Security.|
|fileName||Gives the full path, including the file name, to the log file. The subsystem user should have read/write permission to the file.|
|bufferSize||Sets the buffer size in kilobytes (KB) for the log. Once the buffer reaches this size, the contents of the buffer are flushed out and copied to the log file. The default size is 512 KB.|
|flushInterval||Sets the amount of time before the contents of the buffer are flushed out and added to the log file. The default interval is 5 seconds.|
|maxFileSize||Sets the size, in kilobytes (KB), a log file can become before it is rotated. Once it reaches this size, the file is copied to a rotated file, and the log file is started new. The default size is 2000 KB.|
|rolloverInterval||Sets the frequency for the server to rotate the active log file. The available options are hourly, daily, weekly, monthly, and yearly. The default is monthly.|
13.1.2. Managing Audit Logs
The audit log contains audit records for events that have been set up as recordable events. If you enabled the audit log signing option as described in the Enabling and Configuring Signed Audit Logs section in the Red Hat Certificate System 9 Planning, Installation and Deployment Guide (Common Criteria Edition), the audit log is signed with a log signing certificate belonging to the server. This certificate can be used by auditors to verify that the log has not been tampered with.
Signed audit logs are optional. To enable them, please refer to Section 126.96.36.199, “Configuring a Signed Audit Log in the Console”.
By default, regular audit logs are located in the
/var/log/pki/instance_name/subsystem_name/directory with other types of logs, while signed audit logs are written to
/var/log/pki/instance_name/subsystem_name/signedAudit/. The default location for logs can be changed by modifying the configuration.
The signed audit log creates a log recording system events, and the events are selected from a list of potential events. When enabled, signed audit logs record a verbose set of messages about the selected event activity.
It is also possible to edit the configuration or change the signing certificates after configuration, as covered in Section 188.8.131.52, “Configuring a Signed Audit Log in the Console”.
184.108.40.206. Configuring a Signed Audit Log in the Console
Signed audit logs are configured by default when the instance is first created, but it is possible to edit the configuration or change the signing certificates after the installation.
Provide enough space in the file system for the signed audit logs, since they can be large.
A log is set to a signed audit log by setting the
enableand providing the nickname of the certificate used to sign the log. A special log signing certificate is created when the subsystems are first configured.
Only a user with auditor privileges can access and view a signed audit log. Auditors can use the
AuditVerifytool to verify that signed audit logs have not been tampered with.
The signed audit log is created and enabled when the subsystem is configured, but it needs additional configuration to begin creating and signing audit logs.
- Open the Console.
- In the navigation tree of the Configuration tab, select Log.
- In the Log Event Listener Management tab, select the SignedAudit entry.
- Click Edit/View.
- There are two fields which must be reset in the Log Event Listener Editor window.
- Set the logSigning field to
trueto enable signed logging.
NoteFor more fine-grained audit event select, set audit event filters during the installation configuration. For details, see the Filtering Audit Events section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition).
- Set any events which are logged to the audit log. Appendix E, Audit Events lists the loggable events. Log events are separated by commas with no spaces.
- Save the log configuration.
After enabling signed audit logging, assign auditor users by creating the user and assigning that entry to the auditor group. Members of the auditor group are the only users who can view and verify the signed audit log. See Section 220.127.116.11, “Creating Users” for details about setting up auditors.
Auditors can verify logs by using the AuditVerify tool. See the
AuditVerify(1)man page for details about using this tool. For further details, see Section 13.2.2, “Using Signed Audit Logs”.
18.104.22.168. Handling Audit Logging Failures
There are events that could cause the audit logging function to fail, so events cannot be written to the log. For example, audit logging can fail when the file system containing the audit log file is full or when the file permissions for the log file are accidentally changed.
If log signing is enabled and audit logging fails, the Certificate System instance shuts down in the following manner.
- Servlets are disabled and will not process new requests.
- All pending and new requests are killed.
- The subsystem is shut down.
When this happens, administrators and auditors should work together with the operating system administrator to resolve the disk space or file permission issues. When the IT problem is resolved, the auditor should make sure that the last audit log entries are signed. When this is completed, the administrators can restart the Certificate System.