Meaningful audit trail analysis is hard. It is easy to screw up collecting the data, analyzing the data, and intrepreting the results. Here are a few of the things you should keep an eye out for.
Creating Good Audit Data
There is the old saying, "Garbage in, garbage out." If you don't configure your system to collect useful information to begin with, analyzing it won't do you any good.
The primary configuration file that controls audit data collection is:
You can look at more details about the audit_control file, including its flags and potential values for the flags, by looking at the manual page. For Lion, there are several audit flags that are not documented yet. These are:
Until Apple documents these flags, it is probably best to leave them alone. For more information on setting up the audit_control file, see Getting Started.
Rotated Audit Trail Files
When the audit system rotates an audit trail file (whether triggered automatically (e.g., size limit for a file is reached) or manually), the new audit trail file will have no information about the program name or the parent-child information of the currently running processes. This has at least three potential impacts on your analysis.
First, Audit Control will not be able to display the program names for a lot of the processes since this information is not in the audit trail.
Second, ancestry information for processes will be incomplete. This effects the information in the Process Details window. Also, the Process Tree tab in the Dashboard will look strange because lots of process will not be in the first column because from the audit trail perspective they have no ancestors. These process will also no name.
Third, if you have an audit filter rule that depends on the program's name, it will not fire correctly.
User Names When Using Apple's praudit
If you collect audit trail data on machine A and examine the audit trail data on machine B using Apple's praudit tool, the user name information displayed in the records is probably wrong. For example, Mary might do something on machine A, but when the records are displayed on machine B, praudit says Bob did it.
The reason for this is that the audit records contain user IDs (numbers) and not user names. Praudit, when displaying the user name for an audit record, maps the user IDs to names using the information on the machine currently running praudit. If the names for each UID are not exactly the same on machines A and B, then the wrong name will often be displayed.
Trying to understand how a program interacted with a file is tricky because of a number of factors including the fact that a file and a file name are not the same thing. As a simple example, suppose you have a text editor that opens file foo, the user makes some changes, and then the editor saves the file to the same name. In the audit records you will see something like this:
- editor opens file with an ID of 1234 through the path foo
- editor writes to a file with an ID of 8765 through the path foo.tmp
- editor renames file with ID 8765 to foo.
So you actually never see a write to a file named foo. Keep in mind, this is a very simple example, in reality things get much more complicated.