Audit Trail Mechanism Overview

The objects that are created, manipulated, etc. by the audit interfaces are the event specific data within each audit record, and the audit records themselves. To a post-processing application, an audit record logically appears as the following, (as defined by the POSIX.6 standard):

• header, provides the version number of the POSIX.6 standard to which the record content conforms; indicates the data format the data record is written in; includes fields for event-time (to be compatible with the time format proposed in POSIX.4), event-type, and event-status. The event-type is the specified result of a POSIX.1 event (interface call) or POSIX.6 event (interface call) that was made. The event-status indicates the result of the event (the event was successful, successful and used appropriate privilege, failed due to access control, failed due to lack of appropriate privilege, etc.).

• a set of subject attributes, describes the subject that caused the event to be reported. The user accountable for the event is indicated, as well as possibly the process id, user id, and group id.

• a set of event specific items, contains relevant items that are specified to be included for the particular event-type.

• zero or more sets of object attributes, describes the objects effected by the event.

For example the call made to the interface chown(), would create an audit record with a defined event-type AUD-AET-chown. The event-specific items would include the pathname for the object, the owner, and the owning group (the parameters used in the chown() call). The object attributes would describe the object effected, e.g., the record could contain the user id and group id of the file before the execution of the chown() call.

A sample of the events that will cause an audit record to be generated include POSIX.1 functions such as changing the owner or permissions of a file, changing directories, creating objects, creating processes (fork() or exec() family), killing processes, creating or deleting links, opening files, using the setuid or setgid features, and others. The POSIX.6 functions that are considered auditable events include opening an audit trail, suspending or resuming auditing for an application, setting access control list information, setting privilege information, setting mandatory access control labels, and setting information labels. Additional events may be defined by an implementation to be auditable events and thus cause audit records to be generated.

According to the POSIX.6 standard, the interfaces specified to support the audit mechanisms can be grouped as follows:

• Get and release access to an audit trail - These interfaces are used to select (open) and close an audit trail.
• Write audit records - This interface is used after the system or an application constructs the audit record in the required form. A call to this interface will add the header and subject information to the record and append it to the audit trail (in the system-dependent internal form).
• Read audit Records - This interface provides the application the next audit record. The interface reads the record into working storage and provides the application a pointer to the record.
• Control system auditing - This interface will suspend or resume system auditing of the current process. This is dependent on the audit policy of the system (suspension may not be allowed).
• Analyzing an audit record - These interfaces are used to get specific fields from within the record, and are also used to convert the record to human readable text.
• Storing audit records - These interfaces allow the system or an application to store a record in user-managed space (perhaps for later post-processing), and conversely allow the system or an application to return the record to system-managed space. This process requires that the record be converted from its internal format to a ``byte-copyable'' format. These interfaces provide this conversion.

1. Open the system audit trail for writing (an audit trail other than the system audit trail can be specified). Opening the audit trail for writing requires appropriate privilege, however opening the trail for reading does not require appropriate privilege. If the call to open is successful, a pointer to the beginning of the audit trail is returned to the calling process. This pointer is then used to access the audit trail.
2. Construct the audit record in user managed space. (The standard assumes that an application or system process would construct the audit record in the managed space of the application or system process).
3. Write the record into the audit trail using the pointer provided.
4. Close the audit record.

1. Open the audit trail for reading. The system allocates a buffer area to read the records. A pointer to the beginning of the audit trail is returned. Opening an audit trail for reading does not require privilege.
2. Read the audit record using the pointer returned by the open call. Subsequent read calls return a pointer to the next sequential record.
3. Read the logical pieces of the record (header, subject details, event-specific information, object-specific information) by making calls to the particular area of interest in the record. For example, to access subject details in the record a call is first made to receive a pointer to the header information. Another call uses that pointer to access the subject details of the record. Repeated calls return the data items from the subject details in a predefined order.
4. Close the audit trail.
5. Deallocate the system storage area allocated by the system.