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 System. 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 modification 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 system, 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-system 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 pathname 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 pathname is: /etc/security/audit/audubon/files.

The local audit_control file on each system 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 system mounting the audit file system from eagle is:

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

The extra level of hierarchy prevents a system'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

In a Trusted Solaris environment, audit directories, such as the /etc/security/audit/system_name directory and the files directory directly beneath it, should be protected at the label admin_high. Permissions should be 750.

Auditing a System

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

A system–specific audit_control file is maintained on each system because the dir: lines, and perhaps the minfree: line are specific to the system. 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 system. The audit flags specified here are referred to as the system-wide audit flags or the system-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 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 system 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 system, 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 system.

After the audit_control file is configured, the system administrator on a distributed system distributes it to the other hosts. After any change in the file, the administrator runs audit -s on every system 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 (see Process Preselection Mask). Use auditconfig, setaudit (see the getauid(2) man page), or auditon(2) for existing processes.

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 system at a time, since the audit command only applies locally.

Sample audit_control File

Following is a sample audit_control file for the system 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 system 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

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.

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 controls auditing 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.

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.

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, system ID)

Process Preselection Mask

When a user logs in, login combines the system-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 enables 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 system, 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 pathname 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

In the Trusted Solaris environment, the audit_date file is protected at the label admin_high.

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

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