IBM 10 SP1 EAL4 manual Syscall auditing, Filesystem watches, Task structure

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.2Syscall 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.3Filesystem 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.

Figure 5-70: Audit Kernel Components

5.6.1.1.4Task 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