IBM 10 SP1 EAL4 manual Audit records, Audit record generation, Kernel record generation

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 –moption is another way to write messages to the log.

5.6.3Audit 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.

5.6.3.1Audit record generation

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.

5.6.3.1.1Kernel record generation

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