Audit logger configuration
The audit logger is responsible for constructing the complete audit record. You must select the audit events that you want to be logged.
Audit events selection
Audit event selection has the following types:
- Per-Process Auditing
- To select process events efficiently, the system administrator can define
audit classes. An audit class is a subset of the base auditing events in the
system. Auditing classes provide for convenient logical groupings of the base
auditing events.
For each user on the system, the system administrator defines a set of audit classes that determine the base events that could be recorded for that user. Each process run by the user is tagged with its audit classes.
- Per-Object Auditing
- The operating system provides for the auditing of object accesses by name; that is, the auditing of specific objects (normally files). By-name object auditing prevents having to cover all object accesses to audit the few pertinent objects. In addition, the auditing mode can be specified, so that only accesses of the specified mode (read/write/execute) are recorded.
Kernel audit trail modes
Kernel logging can be set to BIN or STREAM modes to define where the kernel audit trail is to be written. If the BIN mode is used, the kernel audit logger must be given (before audit startup) at least one file descriptor to which records are to be appended.
BIN mode consists of writing the audit records into alternating files. At auditing startup, the kernel is passed two file descriptors and an advisory maximum bin size. It suspends the calling process and starts writing audit records into the first file descriptor. When the size of the first bin reaches the maximum bin size, and if the second file descriptor is valid, it switches to the second bin and reactivates the calling process. The kernel continues writing into the second bin until it is called again with another valid file descriptor. If at that point the second bin is full, it switches back to the first bin, and the calling process returns immediately. Otherwise, the calling process is suspended, and the kernel continues writing records into the second bin until it is full. Processing continues this way until auditing is turned off. See the following figure for an illustration of audit BIN mode:
The alternating bin mechanism is used to ensure that the audit susbsystem always has something to write to while the audit records are processed. When the audit subsystem switches to the other bin, it empties the first bin content to the trace file. When time comes to switch the bin again, the first bin is available. It decouples the storage and analysis of the data from the data generation. Typically, the auditcat program is used to read the data from the bin that the kernel is not writing to at the moment. To make sure that the system never runs out of space for the audit trail (the output of the auditcat program), the freespace parameter can be specified in the /etc/security/audit/config file. If the system has less than the amount of 512-byte blocks specified here, it generates a syslog message.
If auditing is enabled, the binmode parameter
in the start stanza in /etc/security/audit/config should
be set to panic. The freespace parameter
in the bin stanza should be configured at minimum to a value
that equals 25 percent of the disk space dedicated to the storage of the audit
trails. The bytethreshold and binsize parameters
should each be set to 65536 bytes.
In the STREAM mode, the kernel writes
records into a circular buffer. When the kernel reaches the end of the buffer,
it simply wraps to the beginning. Processes read the information through a
pseudo-device called /dev/audit. When a process
opens this device, a channel is created for that process. Optionally, the
events to be read on the channel can be specified as a list of audit classes.
See the following figure for an illustration of audit STREAM mode:
The main purpose of the STREAM mode is to allow for timely reading of the audit trail, which is desirable for real-time threat monitoring. Another use is to create a trail that is written immediately, preventing any possible tampering with the audit trail, as is possible if the trail is stored on some writable media.
Yet another method to use the STREAM mode is to write the audit stream into a program that stores the audit information on a remote system, which allows central near-time processing, while at the same time protecting the audit information from tampering at the originating host.
Audit records processing
The auditselect, auditpr, and auditmerge commands are available to process BIN or STREAM mode audit records. Both utilities operate as filters so that they can be easily used on pipes, which is especially handy for STREAM mode auditing.
- auditselect
- Can be used to select only specific audit records with SQL-like statements.
For example, to select only exec() events that were generated by user afx,
type the following:
auditselect -e "login==afx && event==PROC_Execute" - auditpr
- Used to convert the binary audit records into a human-readable form. The
amount of information displayed depends on the flags specified on the command
line. To get all the available information, run the auditpr command
as follows:
When the -v flag is specified, the audit tail which is an event specific string (see the /etc/security/audit/events file) is displayed in addition to the standard audit information that the kernel delivers for every event.auditpr -v -hhelrtRpPTc - auditmerge
- Used to merge binary audit trails. This is especially useful if there
are audit trails from several systems that need to be combined. The auditmerge command
takes the names of the trails on the command line and sends the merged binary
trail to standard output, so you still need to use the auditpr command
to make it readable. For example, the auditmerge and auditptr commands
could be run as follows:
auditmerge trail.system1 trail.system2 | auditpr -v -hhelrRtpc