Linux Kernel Architecture

Chapter 19: Auditing

Thecodesnippetrevealsthataudit_receiveis responsible for processing any received packets. It imple-

ments a dispatcher that is discussed later.

Note that there is a kernel command line parameter (audit) that can be set to either 0 or 1. The value is

stored in the global variableenable_auditduring initialization. If it is set to 0, auditing is completely

disabled. When it is set to 1, auditing is enabled, but since no rules are supplied by default, no audit

events will be generated unless appropriate rules are given to the kernel.

There is also a kernel thread for the audit mechanism. Instead of starting the thread during subsystem

initialization, a slightly unconventional way has been chosen: As soon as the userspace daemonauditd

sends the first message, the kernel threadkaudit_taskis started. The function executed by the thread

iskauditd_thread, which is responsible for sending already prepared messages from the kernel to the

userspace daemon. Note that this daemon is necessary because an audit event may end within an inter-

rupt handler, and since the netlink functions cannot be called from here, the finished audit records are

put on a queue and processed later by the kernel daemon that sends them back to userspace. Sending

and receiving is performed with a simple netlink operation and standard queue processing, as discussed

in Chapter 12.

19.3.3 Processing Requests

Userspace applications may (dependent on the usual security checks) issue requests to the audit sub-

system. Since the implementations of routines to satisfy such requests are rather similar, this section

discusses only the dispatching mechanism and an exemplary case.

audit_receiveis called by the network subsystem whenever a new request arrives over the netlink

socket. The code flow diagram for the function can be found in Figure 19-3.

Discard bogus requests

netlink_ack

audit_receive

audit_receive_skb

audit_receive_msg

Figure 19-3: Code flow diagram for

audit_receive.

audit_receivehandles the required locking and delegates the real work toaudit_skb_receive.This

function iterates over the queue as long as there are outstanding requests. Requests with a bogus size are

discarded without further notice. Proper ones are forwarded toaudit_receive_msg.Anacknowledg-

ment is sent withnetlink_ackif this is either explicitely requested (as indicated by thgeNLM_F_ACKflag)

or if processing the request failed.

Observe from the code flow diagram in Figure 19-4 thataudit_receive_messagefirst uses

audit_netlink_okto verify that the sender is allowed to perform the request. If the request was

authorized, the function verifies that the kernel daemon is already running. Should this not be the case

because no request has been sent before,kauditdis launched.