Browse Prior Art Database

Extensible and Configurable Audit Event Types and Classes

IP.com Disclosure Number: IPCOM000106937D
Original Publication Date: 1992-Jan-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 4 page(s) / 200K

Publishing Venue

IBM

Related People

Camillone, NA: AUTHOR [+3]

Abstract

Disclosed is a mechanism for defining fully configurable and extensible audit event types and classes in a UNIX* operating system. This design allows for the system auditing subsystem to be customized for the local system accountability policy. This flexibility is provided with a minimal loss in efficiency.

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

Extensible and Configurable Audit Event Types and Classes

       Disclosed is a mechanism for defining fully configurable
and extensible audit event types and classes in a UNIX* operating
system. This design allows for the system auditing subsystem to be
customized for the local system accountability policy. This
flexibility is provided with a minimal loss in efficiency.

      The auditing subsystem is used to enforce the system
accountability policy, and so provides a means for recording the
security relevant occurrences and who was responsible. Most auditing
subsystems provide a means for the system auditor to pre-select which
types of audit events are to be recorded in the system audit trail.
This allows for greater efficiency, since most event types are not of
interest on any particular system. Usually, this involves assigning
event types to users, so that when a user logs into the system,
subsequent tasks run by the user are tagged with those event types,
and when, and if, one of these event types occurs, a record is
written to the audit trail.

      Since there can be literally hundreds of event types in the
system, systems usually group the event types in the system into
audit classes. Each class will contain several related events, and it
is the audit classes which are assigned to users. Then, when an event
occurs, the event is logged in the audit trail if the class for that
type of event is one of the user's assigned audit classes.

      Both event types and event classes are defined symbolically and
numerically. The numeric mapping is done for reasons of efficiency,
but places limits on local extensibility of the system. If a system
administrator wishes to add audit event types or classes to the
system, it is necessary to select unique numerical representation as
well as unique symbolic representation. Since collisions would result
in possible violations of the security policy, auditing subsystems in
the past have generally disallowed it or limited it.

      There are obvious limits to this scheme. First, the event class
definitions may be inadequate for any given system, simply because
the groupings reflect security policy. It is implicitly assumed that
events in the same class are either all audited or are all not
audited. If this assumption is not true, then the efficiency gains of
the class system may be entirely lost. For instance, there are two
ways to group object-related events. They can be grouped either by
the type of object (file, device, directory, shared memory segment,
message pipe, or by the type of action on an object (object creation,
object deletion, object read, object write, object set attributes).
If the second schema is used by the auditing subsystem, while the
local system administrator is only interested in file operations
(because files are the only objects which can contain persistent
data), the local administrator would have no choice except to audit
all object events in order to...