Browse Prior Art Database

Reliable, Extensible Audit Trail Storage in AIX

IP.com Disclosure Number: IPCOM000122568D
Original Publication Date: 1991-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 143K

Publishing Venue

IBM

Related People

Camillone, NA: AUTHOR [+3]

Abstract

Disclosed is a mechanism for providing audit trail storage. This mechanism provides for reliable and recoverable storage of audit records, and the mechanism itself is extensible to support different modes of auditing.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 42% of the total text.

Reliable, Extensible Audit Trail Storage in AIX

      Disclosed is a mechanism for providing audit trail
storage. This mechanism provides for reliable and recoverable storage
of audit records, and the mechanism itself is extensible to support
different modes of auditing.

      Audit subsystems in operating systems must provide some means
of storing audit records for later analysis. The simplest solution is
to simply direct output into a named file, as the accounting
subsystem does with accounting records. This approach implies a
certain amount of inefficiency, since audit trails tend to get quite
large and so later records will be stored in the triple-indirect
blocks of the file. In addition, it is difficult to recover from
storage or file system failures, since no alternate storage media is
normally specified. This approach also does not allow for easy
post-processing of the audit records. As a result of these
shortcomings, audit subsystems normally write records in fixed or
limited size bins.

      The disclosed mechanism provides bin-based audit trail storage
in the following manner. At system initialization time, the auditbin
daemon is started. The first step performed by this daemon is to
start audit bin logging in the kernel. It does this by invoking the
auditbin() system call. This call allows its invoker to define two
audit bins, the current bin and the next bin. What is unique here is
that these are defined by descriptor, not by name. This allows for
different forms of storage options besides filesystem-based objects
like files and named pipes. Also worth noting is that only two bins
are in use at any one time. This allows for simpler recovery
processing. As part of the auditbin() call, the auditbin can specify
a maximum bin size. A key part of the bin auditing design is that the
daemon will usually wait at this point instead of returning from the
call.

      After bin auditing is enabled, system auditing is turned on and
the system will begin writing records into the current bin. When the
bin reaches the maximum size specified by the auditbin daemon, the
system will switch to the next bin and the auditbin daemon is awoken
and will return from the call. At this point, the auditbin daemon
will invoke post-processing filters on the full bin. These filters
can be used to compress the bins or do post-selection of specific
events or other tasks. The filters that are used for post-processing
are fully configurable by the system administrator.

      After the filters complete their task (which usually involves
appending the bin to an audit trail file), the auditbin daemon
invokes the auditbin system call once again, but this time only
supplies a next bin, since the system already has a current bin. If
the current bin is full by the time the auditbin daemon 'returns',
the system will switch bins at that point. Otherwise, the auditbin
daemon will wait again for a full bin. This mode of processing will
continue until e...