Kernel audit processing
illustrates how the event masks are used
to determine when to generate an audit record for an event:
Auditing algorithm (cont)
Checking for auditable events
Whenever a system call is invoked, the kernel invokes the
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:
The systrap routine checks a global variable to see
if auditing is enabled.
If auditing is enabled,
invokes an audit check function
to see if the system call corresponds to an auditable event.
function returns either zero (if the system call does not correspond to an
auditable event), or a number that represents the auditable event.
The auditing subsystem uses the number returned to check the process event mask
and see if the event is being audited.
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.
audit check function
completes processing, the
routine executes the system call.
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.
In previous releases, the
object level event mask would then be evaluated.
For this release, this step is skipped.
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
controls the number of audit buffers in the kernel
controls the size of each of the buffers.
The tunable parameter
controls the size of the per-LWP audit buffer in multiprocessor systems.
These are defined in the
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
Overview of auditable event types and classes
Object level event mask
© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 03 June 2005