The kernel checks the effective capabilities of the sender process. If the sender does not possess the right
capability, the netlink message is discarded.

5.6.1.1.2 Syscall auditing

The second component is a mechanism that addresses system call auditing. It uses the generic logging
mechanism for creating audit records and communicating with user space.

5.6.1.1.3 Filesystem watches

The third component adds file system auditing support, based on file locations and names, to the audit
subsystem. It employs the kernel inotify mechanism (Section 5.1.4) to track of all the objects being watched
and a hash table to store the audit information for the inodes of the objects. Inotify is used to keep the rules
list up to date. The audit filtering for a filesystem object is done based on dev and/or inode depending on
whether dev/inode is specified in the rule or whether a path is specified.
At kernel startup four lists are created to hold the filter rules. One list is checked at task creation, another is
checked at syscall entry time, the third is checked at syscall exit time, and the fourth is used to filter user
messages. These lists hold the filter rules set by user-space components. Multiple variables are used to
control the operation of audit.

5.6.1.1.4 Task structure

The Audit Subsystem extends the task structure to potentially include an audit context. By default, on task
creation, the audit context is built, unless specifically denied by the per-task filter rules. Then, during system
calls the audit context data is filled. The audit subsystem further extends the audit context to allow for more
auxiliary audit information, which might be needed for specific audit events.
133
Figure 5-70: Audit Kernel Components