5.6.3.1.2 Syscall audit record generation
Once attached, every security-relevant system call performed by the process is evaluated in the kernel. The
process’s descendants maintain their attachment to the audit subsystem.
1. All security-relevant system calls made by the process are intercepted at the beginning or at the exit
of the system call code. The intercept routine then evaluates the intended action, and an audit context
corresponding to the system call is built to be used in the corresponding audit record.
2. The process invokes a system call service routine to perform the intended system call.
3. The audit record is placed in a netlink; from there, it is transferred to the audit trail by the audit
daemon.
5.6.3.1.2.1 System call interface intercept functions
In order to evaluate each system call as a potential audit candidate, the SLES kernel’s system call interface
functions are extended with calls to audit framework functions. Ordinarily, system calls are performed in a
three step process.
The first step changes from user to kernel mode, copies system call arguments, and sets up appropriate kernel
registers. The second step calls the system call service routine to perform the system call, and the third step
switches from the kernel to user space after copying the result of the system call.
The LAF extensions to the previous steps involve calling the audit subsystem function
audit_syscall_entry() between step one and two, and calling the audit subsystem function
audit_syscall_exit() between steps two and three. This is done by adding hooks to the ptrace
system. The do_syscall trace() function is called twice, once before the system call is performed, at
which time it calls audit_syscall_entry() and once again after the system call is performed. At that
time it calls audit_syscall_exit(). audit_syscall_entry() stores relevant audit data needed
to create the audit record. audit_syscall_exit(), which is invoked after the system call is performed,
141
Figure 5-73: Audit Record Generation