|
|
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 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. ``Common output record header'' illustrates the common header along with the system call and result fields.
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: Result: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.
System calls without pathnames
| pipe | fork | kill | close |
| setuid | setgid | exit | security |
| read | setpgrp | msg | dup |
| sem | shm | write | fcntl |
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, ``Access denial output record'' 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.
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
``System calls without pathnames'',
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
``close(S) system call record''.
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 ``System calls with pathnames'', 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).
System calls with pathnames
| open | unlink | creat |
| exec | chdir | mknod |
| chown | chmod | stat |
| umount | exece | chroot |
| link | mount |
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
``Output record with two pathnames''.
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. ``chmod(S) system call record'' illustrates the output record from a chmod(S) system call.
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
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:
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.
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
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.
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
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.
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
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:
Audit subsystem output record
Process ID: 517 Date/Time: Wed Mar 4 8:30:04 1992 Event type: Audit subsystem activity Action: Audit enabled
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.
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
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.
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