Kernel audit processing

``Auditing algorithm'' illustrates how the event masks are used to determine when to generate an audit record for an event:

Auditing algorithm

Auditing algorithm (cont)

Checking for auditable events

Whenever a system call is invoked, the kernel invokes the systrap routine to perform system call processing. This routine is also used to check if the system call being executed represents an auditable event. The checks are made as follows:

1. The systrap routine checks a global variable to see if auditing is enabled.

2. If auditing is enabled, systrap invokes an audit check function to see if the system call corresponds to an auditable event. The audit check function returns either zero (if the system call does not correspond to an auditable event), or a number that represents the auditable event.

3. The auditing subsystem uses the number returned to check the process event mask and see if the event is being audited.

4. If the event is being audited, the auditing subsystem sets a flag in the audit process structure to indicate that the event is being audited. Event type, current time and an event sequence number are also saved in the audit process structure.

5. After the audit check function completes processing, the systrap routine executes the system call.

6. Any system call that involves a pathname calls a series of kernel routines to obtain pathname information. If the event is being audited (the flag value in the audit process structure is checked) object information is recorded.

7. In previous releases, the object level event mask would then be evaluated. For this release, this step is skipped.

8. After the system call completes, if the event is auditable the operating system calls a recording function that writes the audit record.

Writing audit data

For efficiency, the auditing subsystem records much of its data in numeric format. The audit record is usually written to one of a number of audit buffers in the kernel. The tunable parameter ADT_NBUF controls the number of audit buffers in the kernel and ADT_BSIZE controls the size of each of the buffers. The tunable parameter ADT_LWP_BSIZE controls the size of the per-LWP audit buffer in multiprocessor systems. These are defined in the /etc/conf/mtune.d/audit file.

The high water mark controls the amount of data stored in an audit buffer before auditing switches to the next available buffer. Whenever an audit record would make the amount of data in a buffer larger than the high water mark the auditing subsystem flags the buffer as writable and switches to a new buffer. It also awakens the audit daemon process which will write the flagged buffer to the audit event log file and returns the buffer to the pool of available buffers. If all available buffers are full, the process that is generating the audit record sleeps until a buffer becomes available.