System Administration Guide: Security Services

Deciding Who and What to Audit

Novice system administrators tend to start out wanting to collect as much information as possible about user and system actions. However, audit files can quickly grow to fill the available space, so it makes sense to be selective about what kinds of activities are audited.

Issue 

Description 

1. Determine which audit classes you need for your site 

The best time to add audit classes or to change the default classes is before you start the auditing service. See Audit Flags for information about auditing classes.

2. Determine event-to-class mappings 

In many situations, the default mapping is sufficient. However, if you have added new classes or have changed them, you might also need to move an event to a different class. 

3. Decide what classes should be audited for all users on all machines 

The system-wide audit flags in the audit_control file apply to all users and processes. Audit flags determine whether an audit class is audited for success, for failure, and for both. Every machine in the installation should have the same audit flag settings in their audit_control file.

4. Determine user exceptions to the installation-wide audit settings 

If you decide that some users should be audited differently from the system-wide settings, modify the users' entries in the audit_user file on each machine. For more information see How to Change Users' Audit Characteristics.

5. Determine the minimum free disk space (minfree) that should be available on an audit file system before a warning is sent

When the amount of disk space on an audit file system drops below the minfree percentage, the audit daemon switches to the next available audit directory and sends a warning that the soft limit has been exceeded. For more information, see Example — Changing the Soft Limit for Warnings.

6. Decide which audit policies your site needs 

The policy variable is a dynamic kernel variable, so its value is not saved when the system is brought down. Therefore, you should set the desired policy by using an appropriate startup script. For more information, see How to Enable or Disable an Audit Policy.

7. Decide how to manage the audit_warn mail alias

The audit_warn script is run by the auditd daemon whenever the daemon switches audit directories or encounters difficulty (such as lack of disk space). By default, the audit_warn script sends mail to an audit_warn alias and sends a message to the console. You need to either modify the alias, or change the script to send the message to a different alias. For more information, see How to Configure the audit_warn Alias.

8. Decide what to do when all the audit directories are full 

To permit the system to continue functioning in the event of an audit trail overflow, you can enable the cnt policy. For a cnt policy example, see Example — Setting the cnt Policy.

Alternatively, you can create an account that can log in and work without being audited. See Example — Creating an Audit Admin Login for an audit account example.

Determining Which Audit Policies to Use

Audit policies refer to the auditing options that are enabled or disabled for a particular configuration. You can inspect, enable, or disable the current audit policy with the auditon system call at the program level. Or, to do the same task you can run the auditconfig command.

By default, all audit policies are disabled. You need to enable any audit policies that you want to use.

The audit policies are disabled by default to minimize storage requirements and system processing demands. You can enable audit policies, and disable them dynamically. Use the following table to determine if the needs of your site justify the additional overhead that results from enabling one or more audit policies.

Policy Name 

Description 

Why Change the Policy? 

arge

When disabled, this policy omits environment variables of an executed program script from the exec audit record.

When enabled, this policy adds the environment variables of an executed program script to the exec audit record. The resulting audit records contain much more detail than when this policy is disabled.

The disabled option collects much less information than the enabled option. 

The enabled option makes sense when you are auditing a few users, or when you have suspicions about the environment variables that are being used in exec programs.

argv

When disabled, this policy omits the arguments of an executed program script from the exec audit record.

When enabled, this policy adds the arguments of an executed program script to the exec audit record. The resulting audit records contain much more detail than when this policy is disabled.

The disabled option collects much less information than the enabled option. 

The enabled option makes sense when you are auditing a few users, or when you have reason to believe that unusual exec programs are being run.

cnt

When disabled, this policy blocks a user or application when audit records can not be added to the audit trail because no disk space is available.  

When enabled, this policy allows the event to complete without an audit record being generated. A count of audit records that are dropped is maintained. 

The disabled option makes sense in an environment where security is paramount.  

The enabled option makes sense when system availability is more important than security. 

group

When disabled, this policy does not add a groups list to audit records. 

When enabled, this policy adds a groups list to every audit record as a special token.

The disabled option usually satisfies requirements for site security. 

The enabled option makes sense when you need to audit which groups are generating auditable events. 

path

When disabled, this policy records in an audit record at most one path that is used during a system call. 

When enabled, this policy records every path that is used in conjunction with an audit event to every audit record. 

The disabled option places at most one path in an audit record. 

The enabled option enters each file name or path that is used during a system call in the audit record as a path token. 

seq

When disabled, this policy does not number the audit records in sequence. 

When enabled, this policy adds a sequence number (seq token) to every audit record.

The disabled option is sufficient when auditing is running smoothly. 

The enabled option makes sense when you are checking that audit files are being written correctly. In the case of file corruption (for example, a partially written audit record), you may be able to spot bad records faster if the sequence numbers are out of order or if some numbers are missing. 

trail

When disabled, this policy does not add a trailer token to audit records. 

When enabled, this policy adds a trailer token to every audit record.

The disabled option creates a smaller audit record. 

The enabled option marks the end of each audit record clearly with a trailer token. The trailer token is often used in conjunction with the sequence token when debugging. In the case of file corruption (for example, a partially written audit record), the auditreduce command resyncs faster on good records.