Chapter 19: Auditing........................................................
Kernel
rule
database
Netlink
connection
Userland
auditd auditctl
rule
definitionsaudit events
Figure 19-1: Overview of the audit
subsystem.
A sketch of the overall design of the audit subsystem is depicted in Figure 19-1. The kernel contains a
database with rules to specify the events that must be recorded. The database is filled from userland by
means of theauditctltool. If a certain event happens and the kernel decides per the database that it
must be audited, a message is sent to theauditddaemon. The daemon can store the message in a log file
for further inspection. Communication between userland and the kernel (rule manipulation and message
transmission) is performed with the aid of a netlink socket (this connection mechanism was discussed
in Chapter 12). The kernel and userland parts of the audit mechanism are mutually dependent on each
other. Because the impact of audit on the kernel isminimal if only events are logged that appear with
comparatively low frequency, the implementation is also referred to as thelightweight auditing framework.
To further decrease the impact on system performance, the audit mechanism distinguishes between two
types of audit events, as follows:
❑ System call auditing allows recording whenever the kernel enters or leaves a system call.
Although additional constraints can be specified to limit the number of logged events (for
example, a restriction to a certain UID), system calls still happen with a rather high frequency,
so a certain impact on system performance is unavoidable if system call auditing is employed.
❑ All other types of events that are not directly connected with system calls are handled separately.
It is possible to disable auditing of system calls and to record only events of this type. This will
affect the system load only very little.
It is important to understand the difference (and relationship) between auditing and more canonical
techniques like system call tracing. If an auditedprocess creates new children by forking, attributes
relevant to auditing are inherited. This allowsaudit trailsto be generated, which are important to observe
the behavior of an application as a whole, or to track the actions of a certain user. In general, the audit
mechanism allows (trusted) applications to be traced in a more task-oriented manner (i.e., from a higher-
level point of view) than pure system call tracing (as implemented byptrace) would allow. Various
hooks that produce audit events are distributed across the kernel, but nearly all parts of the kernel could
be extended with code to send specific audit messages.
Although audit is a fairly general mechanism, SELinux and AppArmor (a competitor to SELinux that
is not included in the official kernel source, but is, for instance, employed by OpenSUSE) are the most
notable users of the auditing features.
