Auditing
Developers working on the kernel often have a natural interest to watch and inspect what is going
on inside the code. But they are not the only ones who would like to know what the kernel does.
System administrators, for instance, might wantto observe which decisions the kernel has taken
and which actions were performed. This can be beneficial for a number of reasons, ranging from
increased security to postmortem forensic investigation of things that went wrong. It could, for
instance, be very interesting to not only observe that a wrong security decision caused by some
misconfiguration was made by the kernel, but also to know which process or users took advantage
of this. This chapter describes the methods provided by the kernel for this purpose.19.1 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, admin-
istrators 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.(^1) This includes the ability to check if (and which) users were nosy enough to try peeking into files that they shouldn’t have
access to.