Auditing User Exceptions

The security administrator sets up auditing for the default configuration. You may want all users and administrators to be audited according to the system-wide audit flags you specified in the audit_control file. To fine-tune auditing for individual users, you add user entries to the audit_user file. You may also choose to add audit flags to users' entries at the time you add new users, and you should probably set up auditing for the new user just after you unlock the account and configure the security attributes for that user.

Alterations to a static auditing database (audit_control, audit_startup, or audit_warn) on one system should be copied to all hosts on the network. See To Distribute Audit Configuration Files.

The audit_user database is distributed to all hosts by the User Accounts tool in the Solaris Management Console.

In addition to supplying the per-user audit control information in the static databases, you can dynamically adjust the state of auditing while a user's processes are active on a single system.

The audit_user File

If it is desirable to audit some users differently from others, the administrator can edit the audit_user file to add audit flags for individual users. If specified, these flags are combined with the system-wide flags specified in the audit control file to determine which classes of events to audit for that user. The flags the administrator adds to the user's entry in the audit_user file modify the defaults from the audit_control file in two ways: by specifying a set of event classes that are never to be audited for this user or by specifying a set of event classes that are always to be audited.

So, what is audited for an individual user is the combination of the system audit flags and the user's always and never audit flags, shown in Process Preselection Mask.

In the audit_user file entry for each user, there are three fields. The first field is the username, the second field is the always-audit field, the third is the never-audit field.

The two auditing fields are processed in sequence, so auditing is enabled by the first field and turned off by the second.

Avoid the placing the all flag in the never-audit field. This causes all auditing to be turned off for that user, overriding the flags set in the always-audit field.

Using the never-audit flags for a user is not the same as removing classes from the always-audit set. For example, suppose (as shown in the examples below), you have a user katya for whom you want to audit everything except successful reads of file system objects. (This is a good way to audit almost everything for a user while generating only about three-quarters of the audit data that would be produced if all data reads were also audited.) You also want to apply the system defaults to katya. Here are two possible audit_user entries.

The correct entry

katya:all,^+fr:

The incorrect entry:

katya:all:+fr

The first example says, “always audit everything except successful file-reads.” The second example says “always audit everything, but never audit successful file-reads.” The second example is incorrect because it overrides the system default. The first example achieves the desired effect: any earlier default applies, as well as what is specified in the audit_user entry.