IBM 10 SP1 EAL4 5.6.3 Audit records

7. If audit is enabled, the kernel intercepts the system calls, and generates audit records according to the

filter rules. Or, the kernel generates audit records for watches set on particular file system files or

directories.

8. Trusted programs can also write audit records for security relevant operation via the audit netlink, not

directly to the audit log.

9. The auditctl –m option is another way to write messages to the log.

5.6.3 Audit records

The kernel as well as user space generate the audit records. The records can take various formats depending

on the information they hold and from where they are generated. This section highlights the areas from which

the audit records are generated, and the various audit record formats.

The audit framework is an event-based system in which data is recorded whenever an auditable event occurs.

An event represents a single action that might affect the security of the system. Either system calls or user-

level trusted programs trigger events.

In order to catch all security-relevant events, audit is designed to record actions of the kernel as well as those

of the security-relevant trusted programs. As such, there are two sources that generate audit records: the

kernel and trusted user programs.

All actions are recorded in the form of audit records. Each audit record contains information pertaining to the

security-relevant action, which allows the administrator to irrefutably attribute the action to a particular user

and ascertain the time that the action was taken.

The Audit Subsystem, by default, has the general logging mechanism active. This mechanism offers a set of

APIs that can be used by other kernel subsystems, such as SELinux (SELinux is not used in SLES). If the

audit daemon is not listening, or Netlink is not configured, the records are logged to syslog via printk.

The following sections describe how records are generated through the kernel and user space.

The kernel component of Linux audit consists of extensions to the process task structure for storing additional

audit related attributes. The kernel provides intercept functions, or hooks, to trap entry into and exit from the

system calls interface, hooks to the VFS to track file system related events, and hooks for IPC and socket

operations. The kernel evaluates the security events and, if allowed by the filters, generates audit records.

To begin auditing, a process attaches itself to the audit framework. Attaching means the process extends the

task structure to include an audit context. By default, the task builds the audit context, if audit is enabled.

Only when specifically stated that auditing should be disabled for the task, the audit context will not be built

for the task. As mentioned in the Linux Audit Operation section, at kernel initialization, four lists of rules are

created. The per-task list holds filter rules that are checked on task creation to see whether auditing should be

disabled for the process.

An audit context can be in one of the following four states:

•Disabled, no syscall audit will be generated for the task. The audit context is NULL.

•Build the audit context, but do not fill in the sycall info at syscall entry.

•Build the audit context and always fill it on syscall's entry.

•Build the audit context, fill it at syscall's entry, and always write it out at syscall's exit.

140