Audit Flags

Audit flags are the short names for the audit classes. Audit flags are used to indicate which classes to audit in the audit_control(4) file, the audit_user(4) file, and as arguments to the auditconfig(1M) command.

The audit_control file is described in "Auditing a Workstation". The audit_user file is described in "The audit_user File".

Definitions of Audit Flags

Each predefined audit class is listed in Table A-1. The table includes the audit flag (which is the short name that stands for the class), the long name, its audit mask, and a pointer to the list of audit events that by default are in that audit class. The system administrator uses the audit flags in the auditing configuration files to specify which classes of events to audit. Additional classes can be defined and existing classes can be renamed by modifying the audit_class(4) file.

Audit Flag Syntax

Depending on the prefixes, a class of events can be audited whether it succeeds or fails, or only if it succeeds or only if it fails. The format of the audit flag is shown here.

prefixflag
-lo        # audit for failure
+lo        # audit for success
lo         # audit for success and failure

The audit flag +lo means "all successful attempts to log in and log out". The audit flag -lo means "all failed attempts to log in". (You cannot fail an attempt to logout.). The audit flag lo means "all successful attempts to log in and log out and all failed attempts to log in".

The audit class xs should not be audited for failure; failures will place a lot of noise in the audit trail. The correct audit flag syntax would be +xs. See the audit_class(4) file for more information on X server audit classes.

For another example, the +all flag refers to all successful attempts of any kind.

The all flag can generate large amounts of data and fill up audit file systems quickly, so use it only if you have extraordinary reasons to audit everything

The following table shows prefixes that specify whether the audit class is audited for success or failure or both.

Prefixes to Modify Previously Set Audit Flags

Use the modify prefixes in any of three ways: in the flags line in the audit_control(4) file to modify already-specified flags, as flags in the user's entry in the audit_user(4) file, or as arguments to the auditconfig(1M) command.

The prefixes in Table 1-3 along with audit flags, turn on or turn off previously specified audit classes. These prefixes turn on or off previously specified flags only.

The ^- prefix is used in the flags line in the following example from an audit_control file.

flags:lo,ad,-all,^-fc 

Audit Storage

On every workstation, the /etc/security/audit directory contains subdirectories with all the audit log files. The /etc/security directory contains files related to audit configuration. Because the /etc/security directory contains the per-workstation audit_data file, which is used by the audit daemon at boot time, the /etc/security directory must be part of the root file system.

The audit postselection tools look in directories under /etc/security/audit by default. For this reason, the path name of the mount point for the first audit file system on an audit server is in the form: /etc/security/audit/server-name (where server-name is the name of the audit server). If more than one audit partition is on an audit server, the name of the second mount point is: /etc/security/audit/server-name.1, the third is /etc/security/audit/server-name.2, and so forth.

For example, the names of the audit file systems available on the audit file server audubon are /etc/security/audit/audubon and /etc/security/audit/audubon.1.

Each audit file system has a subdirectory named files. This files subdirectory is where the audit files are located and where the auditreduce commands looks for them. For example, the audit file system on audit server audubon has a files subdirectory whose full path name is: /etc/security/audit/audubon/files.

The local audit_control file on each workstation directs the audit daemon to put the audit files in the files subdirectory. For example, the dir: line for the audit_control file on a workstation mounting the audit file system from eagle is:

dir: /etc/security/audit/eagle/files

The extra level of hierarchy prevents a workstation's local root file system from filling with audit files when (for whatever reason) the /etc/security/audit/server-name[.suffix] directory is not available on the audit server. Because the files subdirectory is present on the audit server and the clients use the same naming convention for their local audit log files, /etc/security/audit/client-name, audit files cannot be created unintentionally in the local mount-point directory if the mount fails.

Permissions on Audit Directories

Audit directory permissions on the /etc/security/audit/workstation-name directory and the files directory directly beneath it are shown in the following table.

Auditing a Workstation

Auditing is set per workstation by the security administrator in the file audit_control. This file on each workstation is read by the audit daemon (see the audit_control(4) man page). The audit_control file is located in the /etc/security directory.

A separate audit_control file is maintained on each workstation because the dir: lines, and perhaps the minfree: line are specific to the workstation. In a distributed system, the other lines should be identical.

You specify four kinds of information in four kinds of lines in the audit_control file:

• The audit flags line (flags:) contains the audit flags that define what classes of events are audited for all users on the workstation. The audit flags specified here are referred to as the machine-wide audit flags or the machine-wide audit preselection mask. Audit flags are separated by commas, with no spaces.

• The nonattributable flags line (naflags:) contains the audit flags that define what classes of events are audited when an action cannot be attributed to a specific user. The flags are separated by commas, with no spaces.

• The audit threshold line (minfree:) defines the minimum free-space level for all audit file systems. See "What Makes a Directory Suitable for Storing Audit Data".

  The minfree percentage must be greater than or equal to 0. The default is 20 percent.

• The directory definition lines (dir:) define which audit file systems and directories the workstation will use to store its audit trail files.

  There may be one or more directory definition lines. The order of the dir: lines is significant, because the auditd command opens audit files in the directories in the order specified (see the audit(1M) man page). The first audit directory specified is the primary audit directory for the workstation, the second is the secondary audit directory where the audit daemon puts audit trail files when the first one fills, and so forth.

The security administrator modifies the default audit_control file during the configuration process on each workstation.

After the audit_control file is configured, the security administrator on a distributed system distributes it to the other workstations. After any change in the file, the administrator runs audit -s on every workstation on the network to instruct the audit daemon to reread its audit_control file.

The audit -s command does not change the preselection mask for existing processes. Use auditconfig, setaudit (see the getauid(2) man page), or auditon(2) for existing processes.

Sample audit_control File

Following is a sample audit_control file for the workstation willet. willet uses two audit file systems on the audit server egret, and a third audit file system mounted from the audit administration server audubon, which is used to store audit records only when the audit file system on egret fills up or is unavailable. The minfree value of 20 percent specifies that the warning script (see the audit_warn(1M) man page) is run when the file systems are 80 percent filled and the audit data for the current workstation will be stored in the next available audit directory, if any. The flags specify that all logins and administrative operations are to be audited (whether or not they succeed), and that failures of all types except failures to create a file system object are to be audited.

flags:lo,ad,-all,^-fc
naflags:lo,nt
minfree:20
dir:/etc/security/audit/egret/files
dir:/etc/security/audit/egret.1/files
#
# Audit filesystem used when egret fills up
#
dir:/etc/security/audit/audubon

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_user, audit_startup, or audit_warn) on one workstation should be copied to all workstations on the network. See "To Distribute Audit Configuration Files to a Network of Workstations".

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 workstation.

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 workstation audit flags and the user's always and never audit flags, as shown below.

What is audited = (Workstation Audit Flags + User's Always Audit) - User's Never Audit

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 common mistake of leaving the all set 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.

Successful events and failed events are treated separately, so a process can (for example) generate more audit records when an error occurs than when the event is successful.

Dynamic controls refer to controls put in place by the administrator while processes are running. These persist only while the affected processes (and any of their children) exist, but will not continue in effect at the next login. Dynamic controls apply to one workstation at a time, since the audit command only applies to the current workstation where you are logged in.

Each process has two sets of one-bit flags for audit classes. One set controls whether the process is audited when an event in the class is requested successfully; the other set, when an event is requested but fails (for any reason). It is common for processes to be more heavily audited for failures than for successes, since this can be used to detect attempts at browsing and other types of attempts at violating system security.

Process Audit Characteristics

The following audit characteristics are set at initial login:

• Process preselection mask

• Audit ID (AUID)

• Audit Session ID

• Terminal ID (port ID, workstation ID)

Process Preselection Mask

When a user logs in, login combines the workstation-wide audit flags from the audit_control file with the user-specific audit flags (if any) from the audit_user file, to establish the process preselection mask for the user's processes. The process preselection mask specifies whether events in each audit event class are to generate audit records.

The algorithm for obtaining the process preselection mask is as follows: the audit flags from the flags: line in the audit_control file are added to the flags from the always-audit field in the user's entry in the audit_user file. The flags from the never-audit field from the user's entry in the audit_user file are then subtracted from the total.

user's process preselection mask = (flags: line + always audit flags) - never audit flags

Audit ID

A process also acquires its audit ID when the user logs in, and this audit ID is inherited by all child processes started by the user's initial process. The audit ID helps enforce accountability. Even after a user assumes a role, the audit ID remains the same. The audit ID that is saved in each audit record allows the administrator to always trace actions back to the original user that logged in.

Audit Session ID

The audit session ID is assigned at login and inherited by all descendant processes.

Terminal ID

The terminal ID consists of the host name and the Internet address, followed by a unique number that identifies the physical device on which the user logged in. Most of the time the login will be through the console and the number that corresponds to the console device will be 0.

The audit_data File

When auditd starts on each workstation, it creates the file /etc/security/audit_data. The format of the file consists of a single entry with the two fields separated by a colon (see the audit_data(4) man page). The first field is the audit daemon's process ID, and the second field is the path name of the audit file to which the audit daemon is currently writing audit records. Here is an example:

# cat /etc/security/audit_data
116:/etc/security/audit/egret.1/files/19910320100002.not_terminated.tern

The Audit Daemon's Role

The following list summarizes what the audit daemon, auditd(1M), does.

• auditd opens and closes audit log files in the directories specified in the audit_control file in the order in which they are specified.

• auditd reads audit data from the kernel and writes it to an audit file.

• auditd executes the audit_warn script when the audit directories fill past limits specified in the audit_control file. The script, by default, sends warnings to the audit_warn alias and to the console. Your site should customize audit_warn to suit your needs. The audit_warn script is described in "The audit_warn Script".

• With the system default configuration, when all audit directories are full, processes that generate audit records are suspended and auditd writes a message to the console and to the audit_warn alias. (The auditing policy can be reconfigured with the auditconfig command.) At this point only the system administrator could log in to write audit files to tape, delete audit files from the system, or do other cleanup.

When the audit daemon starts as the workstation is brought up to multiuser mode, or when the audit daemon is instructed by the audit -s command to reread the file after the file has been edited, auditd determines the amount of free space necessary and reads the list of directories from the audit_control file and uses those as possible locations for creating audit files.

The audit daemon maintains a pointer into this list of directories, starting with the first. Every time the audit daemon needs to create an audit file, it puts the file into the first available directory in the list, starting at the audit daemon's current pointer.

What Makes a Directory Suitable for Storing Audit Data

A directory is suitable for storing audit records if it is accessible to the audit daemon, which means that it must be mounted, that the network connection (if remote) permits successful access, and that the permissions on the directory allow access. Also in order for a directory to be suitable for audit files, it must have sufficient free space remaining. You can edit the minfree: line in the audit_control file to change the default of 20 percent. To give an example of how the minfree percentage is applied, if the default minimum free space of 20 percent is accepted, an email notice is sent to the audit_warn alias whenever a file system becomes more than 80 percent full.

When no directories on the list have enough free space left, the daemon starts over from the beginning of the list and picks the first accessible directory that has any space available until the hard limit is reached. In the default configuration, if no directories are suitable, the daemon stops processing audit records, and they accumulate within the kernel until all processes generating audit records are suspended.

Keeping Audit Files Manageable

To keep audit files at a manageable size, a cron job can be set up that periodically switches audit files (see the cron(1M) man page). Intervals might range from once per hour to twice per day, depending on the amount of audit data being collected. The data can then be filtered to remove unnecessary information and then compressed.