Linux Kernel Architecture

Chapter 19: Auditing

audit_receive_msg

audit_netlink_ok

kauditd not running? Start kauditd

Dispatch by type

Figure 19-4: Code flow diagram foraudit_receive_msg.

The remainder of the function is a dispatcher that calls specific processing functions selected by request

type after the required information has been extracted from the netlink message. As usual, the dispatcher

is implemented with a largecasestatement.

Let us focus our attention on one particular example of how to handle a request, namely how the kernel

adds new audit rules to the rule database. For requests of typeAUDIT_ADD_RULE, the dispatcher delegates

further processing toaudit_receive_filter, where the following piece of code is responsible for dealing

with the request:

kernel/auditfilter.c

switch (type) {

..

case AUDIT_ADD:

case AUDIT_ADD_RULE:

if (type == AUDIT_ADD)

entry = audit_rule_to_entry(data);

else

entry = audit_data_to_entry(data, datasz);

if (IS_ERR(entry))

return PTR_ERR(entry);

err = audit_add_rule(entry,

&audit_filter_list[entry->rule.listnr]);

audit_log_rule_change(loginuid, sid, "add", &entry->rule, !err);

...

break;

}

The request typeAUDIT_ADDis supported only for backward compatibility, so it is not important in this

context.audit_data_to_entrywas mentioned before: It takes an instance ofstruct audit_rule_data

that comes from userspace, and converts it into an instance ofstruct audit_krule— the kernel internal

representation of an audit rule.audit_add_rule, in turn, is responsible for placing the newly constructed

object on the appropriate audit rule list inaudit_filter_list. Since adding audit rules is a decision

worth remembering,audit_log_rule_changeprepares a corresponding audit log message that is sent to

the userland audit daemon.

19.3.4 Logging Events

With all the infrastructure in place, you can now take a look at how the actual auditing is implemented.

The process is split into three phases. First, the logging process needs to be started viaaudit_log_start.