System Administration Guide
Chapter 6, Using the Audit Manager

Understanding audit reports

Understanding audit reports

To interpret the audit trail, you need to understand the records produced by the program and what they mean. Remember that audit records come from three sources: system calls, trusted applications, and protected subsystems. Record formats differ greatly among these three sources. Further, system calls differ greatly from one another in content because of the specific function being performed. For example, a process creation, fork(S), need only indicate the process ID of the newly created process and the ID of its spawning process (parent). However, for an open(S) system call, an object is being acted upon and the name of that object must be recorded. For system calls like mount(S) and link(S), still more information must be recorded; each requires that two object names be recorded. The reduction facility sorts records presented to it and outputs the information in an organized manner.

Output records can be classified into two types: system call records produced by the kernel audit mechanism and application audit records. Some items are considered common to all output records. For example, the date and time of the record and the process ID associated with the record are printed for each type. Beyond this, the content of a record depends on what was audited. 

System call record formats

System call records account for the majority of the records in the audit trail. The operating system contains over 60 system calls. Not all of these system calls are audited as only some of these are deemed to be security-related. Slightly over half of the system calls have the potential to create an audit record. Some system calls support multiple functions -- such as fcntl(S), msgctl(S), shmctl(S), and semctl(S) -- that may only generate audit records for certain functions. For example, the fcntl(S) system call allows files to be opened by duplicating open file descriptors and also permits file-specific flags maintained by the kernel to be retrieved. The first case constitutes an auditable event, making an object available to a subject, while the second has no real security relevance. Furthermore, system calls may perform functions that are considered auditable events but are not enabled by the system event mask at the time.

For the most part, the output of system call records is the same for all calls. Variations exist because some system calls operate on objects -- such as open(S) -- and the object name is contained in the record. Each contains at least the time, date, process ID, system call name, event type, login user ID, real user and group IDs, effective user and group IDs, and an indicator of success or failure for the call.

Each output record contains these basic information fields and others depending on the system call. Example 6-4 illustrates the common header along with the system call and result fields. 

Example 6-4 Common output record header

   Process ID: 68         Date/Time: Sat Mar  7 13:25:09 1992
   Luid: root  Euid: root  Ruid: root  Egid: root  Rgid: root
   Event type:
   System call:
Each system call is classified into a system event type based on the actions that are performed. This describes the event type of the system call. The actual system call name is given. In most cases this uniquely identifies the action. Unfortunately, some UNIX system calls are overloaded, causing a system call entry point to be used to accomplish multiple actions. For example, msgctl(S) is the system call entry for message queue IPC operations. This single entry point calls msgget(S) and msgop(S) to perform certain IPC functions.

System calls like this are not self-explanatory. The audit subsystem is aware of these overloaded calls and provides additional information to identify the particular function. For system calls that succeed, the result is specified as successful. For each that returns an error, the error provides additional record classification. For example, an open(S) that fails from lack of permission is classified as an access denial. An unsuccessful system call that generates an audit record indicates the error in the result field.

The system call output records can be divided into two groups. The first group contains records that do not require pathnames in the audit record. For example, the fork(S) system call is audited to track new processes as they are spawned into the system, but the audit record does not require a pathname. On the other hand, open(S) returns a file descriptor for the specified pathname. Subsequent operations, like close(S), use the file descriptor. To provide meaningful audit records, this second type of record must contain the pathname. The reduction associates this pathname with all further actions on that file, even though the action may have been performed with a file descriptor. 

Table 6-3 System calls without pathnames

 pipe     fork      kill    close
 setuid   setgid    exit    security
 read     setpgrp   msg     dup
 sem      shm       write   fcntl
An output record from one of the above system calls uses the generic record mask described in Example 6-5, ``setuid(S) system call record'', which illustrates the output record from a successful setuid(S) system call. 

Example 6-5 setuid(S) system call record

   Process ID: 6381        Date/Time: Tue Mar 17 11:25:19 1992
   Luid: blf  Euid: blf  Ruid: root  Egid: root  Rgid: root
   Event type: Modify process
   System call: Setuid
   Result: Successful

Similarly, Example 6-6 shows the output record from a setuid(S) system call that failed due to a lack of permission on the file. Notice that the event type classification is different and that the error is reflected in the result field. 

Example 6-6 Access denial output record

   Process ID: 6381        Date/Time: Tue Mar 17 11:25:19 1992
   Luid: blf  Euid: blf  Ruid: blf  Egid: guru  Rgid: guru
   Event type: Modify process
   System call: Setuid
   Result: Failed (EPERM)-Not owner

Many system calls in this group generate additional information in the output record to help clarify the audit trail. The semaphore, shared memory, message queue and subsystems(S) system calls are overloaded. They map to multiple functions. These audit records identify the specific function being performed and also the affected object (for example, shared memory). close(S), dup(S), and fcntl(S) operate on file descriptors that were mapped from pathnames. An output record indicating a dup(S) of a file descriptor would not be very useful because it does not uniquely identify the file. Thus, the file descriptor correlates to a pathname and prints the pathname in the record.

Even though the read(S) and write(S) system calls are listed in Table 6-3, they are audited only in certain circumstances and neither has a dedicated output record. Both system calls are audited only for the first occurrence for a file. Subsequent reads and writes do not need to be audited as they provide no additional information. The audit records are used to track the state of the file. When the file is closed by exec(S), close(S), or exit(S), the name of the object and an indicator of whether the file was read or written is included in the system call record for the action that caused the file to be closed. This is illustrated in Example 6-7. 

Example 6-7 close(S) system call record

   Process ID: 421        Date/Time: Sat Mar  7 17:15:09 1992
   Luid: blf  Euid: blf  Ruid: blf  Egid: guru  Rgid: guru
   Event type: Make object unavailable
   System call: Close
   File Access-Read: Yes  Written: No
   Object: /tmp/datafile
   Result: Successful

The second group of system calls, shown in Example 6-8, contains pathnames as part of the output record. The pathname represents the target of the system call. Two of the system call records actually contain two pathnames: link(S) and mount(S). 

Example 6-8 System calls with pathnames

 open     unlink   creat
 exec     chdir    mknod
 chown    chmod    stat
 umount   exece    chroot
 link     mount
Each of the system calls in Example 6-8 takes one or more pathnames as arguments to the call. The pathnames are audited and become an important part of the reduction process. Output records for these calls indicate the object name acted upon. This name is also retained by the reduction facility and, where applicable, is associated with the file descriptor returned by the system call. This provides a mapping for other system calls like dup(S) that operate on the file but do not contain the pathname. Example 6-9 shows an output record generated from a creat(S) system call. The record format is the basic format augmented by the pathname. 

Example 6-9 Output record with pathname

   Process ID: 64        Date/Time: Sat Mar  7  23:25:09 1992
   Luid: root  Euid: root  Ruid: root  Egid: root  Rgid: root
   Event type: Object creation
   System call: Creat
   Object:  /tmp/daemon.out
   Result: Successful

All of the calls in this group use the same format for pathnames. Two calls, link(S) and mount(S), operate on two pathnames: a source and a target. Both names are audited and reflected in the output record by the reduction facility. A typical record produced by a link(S) system call is shown in Example 6-10. 

Example 6-10 Output record with two pathnames

   Process ID: 14231     Date/Time: Thu Mar 18  03:25:39 1992
   Luid: lp  Euid: lp  Ruid: lp  Egid: lp  Rgid: lp
   Event type: Object creation
   System call: Link
   Source:  /tmp/printfile
   Target:  /usr/spool/lp/lp3014
   Result: Successful

Two other records in this group generate special output records. These are chown(S) and chmod(S), which are used to alter discretionary access permissions and file ownership for objects. Due to the security-relevant nature of their actions, the previous and new values of the object owner, group, and mode are output in the record. Example 6-11 illustrates the output record from a chmod(S) system call. 

Example 6-11 chmod(S) system call record

   Process ID: 6841       Date/Time: Sat Mar  7 13:25:09 1992
   Luid: blf  Euid: blf  Ruid: blf  Egid: guru  Rgid: guru
   Event type: Discretionary Access Change
   System call: Chmod
   Object:  /tmp/demo/newfile
   Old values: Owner-blf  Group-guru  Mode-100600
   New values: Owner-blf  Group-guru  Mode-100666
   Result: Successful

Application audit records

There are six different types of audit records generated by application programs. The formats for these are similar. Unlike system calls, any record produced in one of the six categories is always formatted identically, although the information varies. The categories are:

Each record contains some information common to all audit output records. This includes the process ID, the time and date, and the audit event type. The remainder of the output record depends on the record type. 

Login/Logoff record

All attempts to log into the system are audited by the login program. This is true of successful as well as unsuccessful attempts, and creates an important trail of user accesses and attempted accesses to the system. You can use the audit records for login or logoff to determine who actually used the system. It is also valuable in determining if repeated penetration attempts are being made. The system supports the option of locking terminals after a certain number of attempts and this event can also be audited. See ``Setting login restrictions on terminals'' for more information.

Each login record indicates the specific action that was audited. The three possibilities are: successful login, unsuccessful login, or logoff. All successful logins and logoffs result in an audit output record that indicates the user account and terminal of the login session. For unsuccessful attempts, the user name is meaningless, because the attempt failed. In this case, only the terminal on which the attempt occurred is output along with the basic record fields.

NOTE: You can keep a record of unsuccessful attempts to log in (including the login name entered at the prompt) -- see ``Logging unsuccessful login attempts''.

Example 6-12 Successful login audit output record

   Process ID: 2812      Date/Time: Fri Mar  6 10:31:14 1992
   Event type: Login/Logoff Activity
   Action: Successful login
   Username: blf
   Terminal: /dev/tty2

User password record

All attempts, successful or not, to modify a user account password are carefully audited by the authorization subsystem. To avoid revealing user passwords, audit records for these events contain no password text, but only indicate the account and action that was audited. The actions are classified into successful password change, unsuccessful change, and lack of permission to change the password. 

Example 6-13 Unsuccessful password change audit record

   Process ID: 7314      Date/Time: Tue Mar  3 18:30:44  1992
   Event type: Authentication database activity
   Action: Unsuccessful password change
   Username: blf

Protected database record

Programs that maintain and modify the system's protected databases audit all access attempts and unusual circumstances associated with the databases. This may range from integrity problems to security-related failures. In addition to the record header and the specific audit action, the output includes the name of the program detecting the problem, the object affected by the problem, expected and actual values, and the action and result of the event.

Example 6-14 Protected database output record

   Process ID: 7314      Date/Time: Tue Mar  3 18:30:44 1992
   Event type: Authentication database activity
   Command: authck
   Object: Protected password database
   Value: Expected-0 Actual-0
   Security action: /tcb/files/auth/code
   Result: extraneous file in protected password hierarchy

Audit subsystem record

Events that affect the operation of the audit subsystem itself are audited very carefully. The Audit Manager and the audit daemon auditd, both generate audit records for functions they support. Additionally, the audit device driver also writes audit records for certain function requests. The functions audited include:

Each output record includes the common header information along with an indicator of the function audited. This provides an accurate accounting of all attempts to affect the operation of the audit subsystem. Example 6-15 shows an actual audit record written to indicate the startup and initialization of the subsystem. 

Example 6-15 Audit subsystem output record

   Process ID: 517      Date/Time: Wed Mar  4  8:30:04 1992
   Event type: Audit subsystem activity
   Action: Audit enabled

Protected subsystem record

Each protected subsystem can generate audit records through the audit daemon. These records indicate unusual conditions detected by the subsystem. For example, if a subsystem encounters permission problems with a file or is denied service due to lack of memory or some other resource, the subsystem generates an error message to that effect. You can use these records to help maintain the security and availability of the system.

Aside from the normal record header output, the subsystem records contain a subsystem name, an action, and a result. The subsystem name is the subsystem that detected the inconsistency and wrote the audit record. The action and result describe the action taken by the subsystem and the problem detected.

Example 6-16 Authorized subsystem audit output record

   Process ID: 2812      Date/Time: Fri Mar  6 10:31:14 1992
   Event type: Authorized subsystem activity
   Subsystem: System Administrator Subsystem
   Security action: Update /etc/rc
   Result: Cannot open for update

Terminal and user account record

User accounts or terminals may become locked if the number of unsuccessful login attempts, as stored in the Authorization database, is exceeded. For example, if a terminal is used to enter the system and the result is a series of unsuccessful logins, the login program may lock the terminal after a specified number of tries. Similarly, if a user attempts to log in to an account and fails repeatedly, that user account may be locked. Locking accounts and terminals prevents further access until the system administrator clears the lock. See ``Setting login restrictions'' for more information. A terminal or user account lock may signal an attempted penetration of the system. These audit records contain the usual header information along with an identifier of the user account or terminal.

Example 6-17 User account lock output record

   Process ID: 517      Date/Time: Wed Mar  4  8:30:04 1992
   Event type: System administrator activity
   Action: User account locked by system administrator
   Username: root