Watchful Spirit

The Audit daemon is a service that logs events on a Linux system. If you are interested in security-related messages, take a closer look at the Audit daemon. The audit framework described in this article is part of the Linux kernel and can therefore control access to a computer right down to the system call level. The Audit daemon can monitor all access to files, network ports, or other events. The popular security tool SELinux works with the same audit framework used by the Audit daemon.

Configuring Logging

You can set the rules for logging using the auditctl tool. Like all of the other tools mentioned here, it is part of the audit package that should be included in the software repository of your choice of Linux distribution. auditd running in userspace is notified about events that occur via the netlink protocol. The Audit daemon then writes the information to /var/log/audit/audit.log, and you can find the results via aureport and ausearch.

An event dispatcher is also part of the framework. This tool is a type of event multiplexer that can pass audit events on to another program (plugin) in real time. These plugins can be configured via files in the /etc/audisp/plugins.d/ directory.

For example, the /etc/audisp/plugins.d/af_unix.conf file is responsible for simply passing audit events to a Unix domain socket. This socket is used by the Setroubleshoot daemon to create easily readable messages from the raw SELinux logs. Intrusion detection and prevention systems also can draw on this interface to respond to audit events.

You can configure the auditd server via two files – auditd.conf (Listing 1) and audit.rules – in /etc/audit/. The config file specifies general information about the service, whereas the rules file contains the rules that determine what exactly you want to monitor on the system.

log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 3
flush = INCREMENTAL
freq = 20
num_logs = 5
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
max_log_file = 6
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd

You can also spread the rules across multiple files and then store them in the /etc/audit/rules.d/ directory. This approach is useful if you want to manage rules in separate files organized by purpose. The augenrules tool generates a global file called /etc/audit/audit.rules from all the files in this directory. This file is then read when starting auditd. You will find a description of the individual instructions in the very detailed auditd.conf man page.

Enabling Monitoring

You can either use the auditctl tool to determine the audit rules or record them in the audit.rules file. Read the rules defined there using auditctl -R. If, for example, you want to monitor the /etc/hosts file, you can use the command:

auditctl -w /etc/hosts -p war -k hosts-file

Using the -w option specifies the path to the file that you want to monitor (file watch). The -p option lets you define the operations to be monitored, where r stands for read, w for write, x for execute, and a for attribute changes. Finally, the -k option sets a filter key. Using au-search lets you view the file events later.

If you want to set the same value permanently, add the following entry to the audit.rules file:

-w /etc/hosts -p war -k hosts-file

The auditctl tool shows all the currently active rules:

# auditctl -l
w /etc/hosts -p rwa -k hosts-file

In addition to these simple file watches, complex access cases can be monitored. Four different lists are available for this: task, exit, user, and exclude. With task, you can create new processes using fork() or clone(), exit is used for each syscall, user filters messages from userspace, and exclude can suppress certain messages. This is useful, for example, if you want to log certain syscalls but do not want to see the SELinux log messages labeled with AVC (Access Vector Cache).

Logging System Calls

If you want to write a rule for logging syscalls, the general syntax looks like this:

-a Action, List -S Systemcall -F Field=Value -k Key

The -a option here lets you tell the rule engine that you want to add a rule to the existing rule chain. The always and never parameters can be used as possible values here: always produces a log event in each case if the match criteria are correct, and never ignores the event that appears and thus does not produce a log entry.

Using -S lets you specify the syscall to be monitored, and -F determines a control field. Of these, several dozen are very well described in the man page for auditctl. A possible rule field could be auid, with which the syscall to be monitored can be bound to a specific account.

The following rule logs all events where a user executes an open system call with the login UID 1000. This usually occurs when opening a file:

-a exit,always -S open -F auid=1000 -k user-actions

Essentially, all existing system calls can be logged. The man page shows an overview for syscalls.

To avoid logging some of the automatically logged event types, such as user logins, you can add rules to the exclude list:

-a exclude,always -F msgtype=SYSTEM_BOOT

This rule tells the Audit daemon not to log the SYSTEM_BOOT event type. Using

ausearch -m 2>&1 | tr ' ' '\n' | grep '[A-Z]$' | sort

will show a list of all available event types.