Filter
Top Products
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.
5.6.3.1 Audit 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.1 Kernel 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