Linux Kernel Architecture

Chapter 19: Auditing

19.2 Audit Rules

How is it possible to place constraints on the types of events for which an audit log record can be gen-

erated? This is done with the help of audit rules, and this chapter discusses their format and purpose.

However, you should also consult the manual pagesthat accompany the audit framework — especially

8(auditctl)— for more information. In general, an audit rule consists of the following components:

❑ The basic information is given by afilter/valuepair. Thefilterdenotes the kind of event to which

the rule belongs. Examples for possible values areentryfor system call entrance ortaskfor task

creation auditing.

❑ Thevaluecan either beNEVERorALWAYS. Although the latter choice enables a rule, the first one

is used to suppress generation of audit events. This is meaningful because all rules for a given

filter type are stored in a list, and the first rule that matches is applied. By placing aNEVERrule in

front, this allows you to (temporarily) disable processing of rules that would normally generate

audit events.

The filters partition the set of auditable events into smaller classes, but these are nevertheless still very

broad. More constraints are required to select practicable subsets of events. This is possible by specifying

anumberoffield/comparator/valuepairs. Afieldis a quantity that can be observed by the kernel. This

can, for instance, be a certain UID, a process identifier, a device number, or an argument to a system call.

comparatorandvalueallow specifying conditions for the field. If these conditions are fulfilled, an audit log

event is issued; otherwise, it is not. The usual comparison operators (less than, less or equal, and so on)

can be employed. The method to feed new rules to the kernel is via theauditctltool, which is in general

called as follows:

root@meitner #auditctl -a filter,action -F field=value

Observe, for instance, how it is possible to audit all events where the root user has created a new process:

root@meitner #auditctl -a task,always -F euid=0

When system calls are being audited, it is also possible (and highly advisable!) to restrict record gener-

ation to specific system calls. The following example instructs the kernel to log all events when the user

with UID 1000 fails to open a file:

root@meitner #auditctl -a exit,always -S open -F success=0 -F auid=1000

If the user tries to open/etc/shadow, but fails to provide the required credentials, the following log

record will be generated:

root@meitner #cat /etc/audit/audit.log

...

type=SYSCALL msg=audit(1201369614.531:1518950): arch=c000003e syscall=2

success=no exit=-13 a0=71ac78 a1=0 a2=1b6 a3=0 items=1 ppid=3900 pid=8358

auid=4294967295 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100

sgid=100 fsgid=100 tty=pts0 comm="cat" exe="/usr/bin/cat" key=(null)

...