Overview

Obviously, the surveillance needs of administrators differ considerably from those of developers. While programmers are usually interested in comparatively low-level information, administrators will tend to need a higher-level view: Which processes have opened network connections? Which users have started programs? When did the kernel grant or refuse certain privileges?1 To answer such questions, the kernel provides the audit subsystem.

While programmers will run their experiments on machines solely devoted to development, administrators face a different problem: The machines they have to monitor usually serve as production machines. This places two crucial constraints on the audit mechanism:

□ It must be possible to dynamically change the criteria that select the types of events to be logged. In particular reboots or insertion and removal of kernel modules must not be required.

□ System performance must not degrade by a significant amount when auditing is in use. Disabling the audit mechanism should also leave no negative impact on system performance.

1This includes the ability to check if (and which) users were nosy enough to try peeking into files that they shouldn't have access to.

Netlink connection

Figure 19-1: Overview of the audit subsystem.

Netlink connection

Figure 19-1: Overview of the audit subsystem.

A sketch of the overall design of the audit subsystem is depicted in Figure 19-1. The kernel contains a database with rules to specify the events that must be recorded. The database is filled from userland by means of the auditctl tool. If a certain event happens and the kernel decides per the database that it must be audited, a message is sent to the auditd daemon. The daemon can store the message in a log file for further inspection. Communication between userland and the kernel (rule manipulation and message transmission) is performed with the aid of a netlink socket (this connection mechanism was discussed in Chapter 12). The kernel and userland parts of the audit mechanism are mutually dependent on each other. Because the impact of audit on the kernel is minimal if only events are logged that appear with comparatively low frequency, the implementation is also referred to as the lightweight auditing framework.

To further decrease the impact on system performance, the audit mechanism distinguishes between two types of audit events, as follows:

□ System call auditing allows recording whenever the kernel enters or leaves a system call. Although additional constraints can be specified to limit the number of logged events (for example, a restriction to a certain UID), system calls still happen with a rather high frequency, so a certain impact on system performance is unavoidable if system call auditing is employed.

□ All other types of events that are not directly connected with system calls are handled separately. It is possible to disable auditing of system calls and to record only events of this type. This will affect the system load only very little.

It is important to understand the difference (and relationship) between auditing and more canonical techniques like system call tracing. If an audited process creates new children by forking, attributes relevant to auditing are inherited. This allows audit trails to be generated, which are important to observe the behavior of an application as a whole, or to track the actions of a certain user. In general, the audit mechanism allows (trusted) applications to be traced in a more task-oriented manner (i.e., from a higherlevel point of view) than pure system call tracing (as implemented by ptrace) would allow. Various hooks that produce audit events are distributed across the kernel, but nearly all parts of the kernel could be extended with code to send specific audit messages.

Although audit is a fairly general mechanism, SELinux and AppArmor (a competitor to SELinux that is not included in the official kernel source, but is, for instance, employed by OpenSUSE) are the most notable users of the auditing features.

Continue reading here: Audit Rules

Was this article helpful?

0 0