Administrator's Guide

#auditdp -p portable -P portable2 -s "+event=login"
• Extract exec events from a particular session and write to stdout:
#auditdp -r /var/.audit/audit_trail -s "+sid=1234" -P | \
auditdp -p -s "+event=exec"
or
#auditdp -r /var/.audit/audit_trail -s "+sid=1234;+event=exec"
9.9 Viewing Audit Logs
Auditing can generate a significant amount of data. Use the audisp command to select
the data that you want to view:
#/usr/sbin/audisp audit_trail
NOTE: The audisp command will be obsolete in a future release. Invoking
/usr/sbin/auditdp -r audit_trail produces the same output as
/usr/sbin/audisp audit_trail.
The following options are available with the audisp command:
-f Displays failed events only.
-p Displays successful events only.
-c system_call Displays the selected system call.
-t Display events that occurred after the given time.
-s Displays events that occurred before the given time.
-u user-name Displays information for a specific user.
-l terminal-name Displays information for a specific terminal.
-e event-name Displays information for the given event.
> file-name Writes output to specified file.
It can take a few minutes to prepare the record for viewing when working with large
audit logs. When viewing the audit data, be aware of the following anomalies:
• Audit data can appear inaccurate when programs that call auditable system calls
supply incorrect parameters. The audit data shows what the user program passed
to the kernel. For example, calling the kill system call with no parameters produces
unpredictable values in the parameter section of the audit record.
• System calls that take file name arguments may not have device and inode
information properly recorded. The values will be -1 if the call does not complete
successfully.
• Auditing the superuser while changing the event or system call audit parameters will
result in a long audit record. For example, when you add an event type to be audited,
186 Audit Administration