Table of Contents
An auditing facility is provided. Its design is intended to be simple
but flexible, in such a way that it can be robustly implemented and
will not impinge on the general responsiveness of the Linux kernel.
The following is a summary of the recent discussion on the linux-privs
list. I am in the process of making a proposal that will be general
enough to handle all of the following features:
- basic (atomic) auditing facility
- two modes of access: blocking and non-blocking
- some sort of circular buffer arrangement with hooks for a module of
some sort to store the audit data on some medium.
-  such a module will accept rules that tell it what to audit and
what to discard.
- perhaps we adopt the model of the firewalling rules.
- audit - session id for following login etc. process trees.
- minimal audit records  include audit-id, uid and time plus raw
numerical data (for off-line translation to readable text
- all audit records have the same prefix-header
- Fixed Header prefix contains a version number (audit readers will know
how to deal with historical formats).
- Events to be audited are selected by event masks: union of system/user/file
- Proposed audit prefix header:
- audit header version (audit generation) __u8
- length of audit record (bytes) __u16
- machine id: __u16
- kind of event (e.g. system call code): __u8
- reason for logging (bitmask: audited syscall, audited file, audited
user, audited group) __u32
- timestamp (when audited) __u32
- audit id (set by init or login etc., for following process evolution)
- user id, group id, program id, ...  __u32
- Classes of event
- Group individual events into classes: file-access/system tweeking etc..
- Audit primarily on class of event.
- Events that will always be audited (fixed events):
- all actions relating to the audit sybsystem itself
- all attempts to change the system date
- all actions relating to group and user attributes
- all definitions and deletions of MAC level names and level identifiers
- chages of init states
- all actions relating to lodable modules
- User level event classes:
- some method for defining user-level event groups: administrator can
- Events that may be audited
- file-access (open, connect, accept, close)
- changing of file attributes (chmod, chattr, umask, create)
- program execution (exec, fork, vfork, exit)
- "exits" - administrator hook to deny requests/grant requests/modify
system etc.,  in the light of the event.
- POSIX only defines a method for writing audit records.
- Audit records are variable length
- each record contains header
- event type - indicates minimal information contained in record
- result (success/failure)
- audit - id
- other stuff...(?)
- subject attributes
- information about the calling process.
- object structures
- contain information on objects associated with the audited event:
- event specific data: as directed by the event type.
- int aud_write(int fildes, aur_rec_t ar)
- special fildes = AUD_SYSTEM_LOG, to indicate that data is written to
the system audit record.
- Policy: here we list audit event types (and the functions that
they refer to)
- exec(), execl(), execlp(), execv(), execvp(), execle(), execve()
- Define a minimus set of events that cannot be turned off: these preserve
the integrety of the audit lof
- user and file bitmasks are provided to trace the behavior of the system
with respect to specific files and users.  These are OR'd together
to determine if an event is to be logged.
Here we discuss the manner in which the kernel records audited events.
Any part of the kernel may audit an event.
Only those user-level processes with their auditing capability set may
audit an event with the kernel.
Contingency is made for the possibility of the system log filling up.
This section discusses the kernel hooks provided for making a hard-copy of the
This section describes the policies used to define what sorts of events are
logged. It also introduces the preferred format for recording these audited
Table of Contents