Chapter 1 Auditing Basics

This chapter explains how auditing works on one system and on a network of Trusted Solaris systems.

• Auditing Overview

• The Audit Mechanism

Auditing makes it possible to:

• Monitor security-relevant events that take place on a system

• Record the events in a network-wide audit trail

• Detect misuse or unauthorized activity (by analyzing the audit trail)

• Review patterns of access, and see the access histories of individuals and objects

• Discover attempts to bypass the protection mechanisms

• Discover extended use of privilege that occurs when a user assumes an administrative role

• Supply additional assurance that attempts to bypass protection mechanisms are recorded and discovered

Auditing may serve as a deterrent: if users know that their actions are likely to be audited, they may be less likely to attempt malicious activities.

Auditing Overview

Auditing in the Trusted Solaris environment is enabled by default, configurable by the system and security administrators, and extensible. By default, audit records are stored in system_name:/var/audit/. Events in the audit classes login/logout and non-attribute are audited for the root user.

The system administrator can provide dedicated partitions for audit records. The audit analyst can collect all records from all systems in a Trusted Solaris network into one audit trail. The auditing records from a network of systems can be viewed as one large file. Record selection (called pre-selection) using a variety of criteria is possible.

After audit data is collected into one audit trail, selection (called post-selection) and interpretation tools enable the audit reviewer to examine specific parts of the audit trail. For example, records can be selected for individual users or groups, for a host name, for a certain type of event on a specific day, or for a time of day.

To simplify audit administration, Trusted Solaris auditing provides classes of auditable events. When the security administrator specifies a class of events to be audited, all events in that class are audited. User commands or kernel system calls are auditable events. Classes of events to be audited are specified per system. Specific users or roles (like root, for example) can be audited specially.

The security administrator can modify and extend the provided event-class mappings. For some events, event details that are not required by site security policy can be omitted from the audit record. Audit classes can be audited for failure, for success, or for both. Selecting which activities to monitor is called pre-selection. When the auditing subsystem encounters error conditions, the security administrator can specify email addresses to be notified.

In the Trusted Solaris auditing subsystem, audit records are protected from snooping by the sensitivity label admin_high. Audit configuration files are accessible by the appropriate administrative role only, and sending records to the audit queue requires privilege. A special privilege, proc_audit_appl, is provided for ISVs and integrators to add their applications' audit records to the audit queue. Audit event numbers from 32768 to 65535 are available for third-party trusted applications.

Successful auditing depends on two other security features: identification and authentication. At login, after a user supplies a user name and password, a unique audit ID is associated with the user's process. The audit ID is inherited by every process started during the login session. Even when users change identity, for example, by assuming an administrative role, all of their actions are tracked with the same audit ID.

The rest of this chapter describes the auditing subsystem. Chapter 2, Auditing Setup describes how to set up and administer auditing. The latter part of the chapter contains setup and maintenance procedures. Chapter 3, Audit Trail Management and Analysis, describes the audit trail, how to manage its files, and how to read them. The latter part of the chapter contains typical procedures for managing and analyzing the audit trail.

The Audit Mechanism

Auditing is enabled by an audit daemon that uses six configurable audit files: audit_class(4), audit_event(4), audit_control(4), audit_user(4), audit_startup(1M), and audit_warn(1M). These files are in the /etc/security directory and determine what to audit, where to put the audit logs, and what to do when there is trouble. By default, events in the lo (login/logout) audit class are audited for the root role, the audit records are written to the /var/audit directory, and no one receives mail when there is trouble.

You can suspend and re-enable auditing without rebooting the system, and you can dynamically change what is being audited.

Audit Startup

Auditing is enabled when the audit daemon starts, usually when the system is booted (see the auditd(1M) man page). When troubleshooting, the daemon can be started manually by executing /usr/sbin/auditd in an admin_high shell in the secadmin role.

The existence of a file with the pathname /etc/security/audit_startup causes the audit daemon to be run automatically when the system enters multiuser mode. The file is actually an executable script that is invoked as part of the startup sequence just prior to the execution of the audit daemon (see the audit_startup(1M) man page). A default audit_startup script that automatically configures the event-to-class mappings and sets the audit policies is created during audit package installation.

The security administrator can edit the audit_startup script to alter the default audit policy. See Setting Audit Policies for more information on audit policy.

Audit Classes and Events

Security-relevant actions may be audited. The system actions that are auditable are defined as audit events in the /etc/security/audit_event file. Each auditable event is defined in the file by a symbolic name, an event number, a set of preselection classes, and a short description (see the audit_event(4) man page).

Most events are attributable to an individual user. However, some events are nonattributable because they occur at the kernel-interrupt level or before a user is identified and authenticated. Nonattributable events are auditable as well.

Each audit event is also defined as belonging to an audit class or classes. Administrators name an audit class (called an audit flag) when specifying for the audit daemon what is to be audited. When naming a class, one simultaneously addresses all of the events in that class. The mapping of audit events to classes is configurable and the classes themselves are configurable. These configuration changes are made in the audit_event file. New classes are added to the audit_class file.

Whether an auditable event is recorded in the audit trail depends on whether the administrator preselects an audit class that includes the specific event.

Audit Classes

The file /etc/security/audit_class stores class definitions. Site-specific definitions can be added and default definitions can be changed. Each entry in the file has the form:

mask:name:description

Each class is represented as a bit in the mask, which is an unsigned integer, giving 32 different available classes plus two global classes, all and no. all is a conjunction of all allowed classes. no is the invalid class. Events mapped to the no class are not audited. Events mapped solely to the no class are not audited even if the all class is turned on. Below is a sample audit_class file:

0x00000000:no:invalid class
0x00000001:fr:file read
0x00000002:fw:file write
0x00000004:fa:file attribute access
0x00000008:fm:file attribute modify
0x00000010:fc:file create
0x00000020:fd:file delete
0x00000040:cl:file close
0x00000100:nt:network
0x00000200:ip:ipc
0x00000400:na:non-attribute
0x00001000:lo:login or logout
0x00002000:ax:x server
0x00004000:ap:application
0x000f0000:ad:administrative
0x00010000:ss:change system state
0x00020000:as:system-wide administration
0x00040000:aa:audit administration
0x00080000:ao:other administration
0x00300000:pc:process
0x00100000:ps:process start/stop
0x00200000:pm:process modify
0x20000000:io:ioctl
0x40000000:fn:fcntl
0x80000000:ot:other
0xffffffff:all:all classes

If the no class is actually turned on for auditing, the audit trail fills up with records for the audit event AUE_NULL.

Kernel Events

Events generated by the kernel (system calls) have event numbers between 1 and 2047. The event names for kernel events begin with AUE_, followed by an uppercase mnemonic for the event. For example, the event number for the creat() system call is 4 and the event name is AUE_CREAT.

Within kernel events there is one pseudo-event defined, AUE_UPRIV, which audits use-of-privilege decisions.

When the AUE_UPRIV pseudo-event is preselected, audit information is collected internally even if the underlying kernel event is not selected. For example, if the kernel event AUE_OPEN_R is not selected for auditing but the pseudo-event AUE_UPRIV is enabled, the kernel event AUE_OPEN_R will be written to the audit trail if a use-of-privilege decision was part of the AUE_OPEN_R system call.

User-Level Events

Events generated by trusted application software outside the kernel range from 2048 to 65535. The event names begin with AUE_, followed by a lowercase mnemonic for the event. The file /etc/security/audit_event lists individual events in numerical order. For a listing of events by class, see Appendix A, Event-to-Class Mappings. The following table shows general categories of user-related events.

Non-Attribute Events

Events that are not attributable to a user, such as AUE_ENTERPROM.

Audit Records

Each audit record describes the occurrence of a single audited event and includes such information as who did the action, which files were affected, what action was attempted, and where and when it occurred.

The type of information saved for each audit event is defined as a set of audit tokens. The definition and structure of every audit token are described in detail in Audit Token Structure. Each time an audit record is created for an event, the record contains some or all of the tokens defined for it, depending on the nature of the event and the audit policy. The audit record descriptions in Audit Records list in order the audit tokens defined for each event.

Audit records are stored in audit files. An audit trail is one or more audit files in a distributed system. The construction of the audit trail is shown in Figure 1–1. The audit trail may be converted to a human readable format by the praudit(1M) command. Specific audit records can be selectively chosen using the auditreduce(1M) command. See Audit Files Management, for details.

Figure 1–1 From the Audit Token to the Audit Trail

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.

The audit_warn Script

Whenever the audit daemon encounters an unusual condition while writing audit records, it invokes the /etc/security/audit_warn script. See the audit_warn(1M) man page. This script can be customized by your site to warn of conditions that might require manual intervention or to handle them automatically. For all error conditions audit_warn writes a message to the console and sends a message to the audit_warn alias. This alias should be set up by the administrator after enabling auditing.

When the following conditions are detected by the audit daemon, it invokes audit_warn.

• An audit directory has become more full than the minfree value permits. (The minfree or soft limit is a percentage of the space available on an audit file system.)

  The audit_warn script is invoked with the string soft and the name of the directory whose space available has gone below the minimum. The audit daemon switches automatically to the next suitable directory, and writes the audit files there until this new directory reaches its minfree limit. The audit daemon then goes to each of the remaining directories in the order listed in audit_control, and writes audit records until each is at its minfree limit.

• All the audit directories are more full than the minfree threshold.

  The audit_warn script is invoked with the string allsoft as an argument. A message is written to the console and mail is sent to the audit_warn alias.

  When all audit directories listed in audit_control are at their minfree limits, the audit daemon switches back to the first one, and writes audit records until the directory completely fills.

• An audit directory has become completely full with no space remaining.

  The audit_warn script is invoked with the string hard and the name of the directory as arguments. A message is written to the console and mail is sent to the audit_warn alias.

  The audit daemon switches automatically to the next suitable directory with any space available, if any. The audit daemon goes to each of the remaining directories in the order listed in audit_control, and writes audit records until each is full.

• All the audit directories are completely full. The audit_warn script is invoked with the string allhard as an argument.

  In the default configuration, a message is written to the console and mail is sent to the audit_warn alias. The processes generating audit records are suspended. The audit daemon goes into a loop waiting for space to become available and resumes processing audit records when that happens. While audit records are not being processed, no auditable activities take place—every process that attempts to generate an audit record is suspended.

• An internal error occurs: another audit daemon process is already running (string ebusy), a temporary file cannot be used (string tmpfile), the auditsvc(2) system call fails (string auditsvc), or a signal was received during auditing shutdown (string postsigterm).

  Mail is sent to the audit_warn alias.

• A problem is discovered with the audit_control file's contents. By default, mail is sent to the audit_warn alias and a message is sent to the console.

Controlling Audit Costs

Because auditing consumes system resources, you must control the degree of detail that is recorded. When you decide what to audit, consider the following three costs of auditing:

• Costs in increased processing time

• Costs of analysis of audit data

• Costs of storage of audit data

The cost in increased processing time is the least significant of the three costs of auditing. The first reason is that auditing generally does not occur during computational-intensive tasks—image processing, complex calculations, and so forth. The other reason that processing cost is usually insignificant is that single-user systems have plenty of extra CPU cycles.

The cost of analysis is roughly proportional to the amount of audit data collected. The cost of analysis includes the time it takes to merge and review audit records, and the time it takes to archive them and keep them in a safe place.

The fewer records you generate the less time it takes to analyze them, so upcoming sections describe how you can reduce the amount of data collected, while still providing enough coverage to achieve your site's security goals.

Storage cost is the most significant cost of auditing. The amount of audit data depends on the following:

• Number of users

• Number of systems

• Amount of use

• Degree of security required

Because the factors vary from one situation to the next, no formula can determine in advance the amount of disk space to set aside for audit data storage.

Full auditing (with the all flag) can fill up a disk quickly. Even a simple task like compiling a program of modest size (for example, 5 files, 5000 lines total) in less than a minute could generate thousands of audit records, occupying many megabytes of disk space. Therefore, it is very important to use the preselection features to reduce the volume of records generated. For example, not auditing the fr class can reduce the audit volume by more than two-thirds. Efficient audit file management is also important after the audit records are created to reduce the amount of storage required.

Auditing Efficiently

What to audit, when to audit it, and where to store the files are factors to consider when enforcing your site's security goals while auditing more efficiently. For example, you might try:

• Random auditing of only a certain percentage of users at any one time.

• Real-time monitoring of the audit data for unusual behaviors. (You set up procedures to monitor the audit trail as it is generated for certain activities and to trigger higher levels of auditing of particular users or systems when suspicious events occur.) See To Read a Current Audit File for an example.

• Setting the public object flag on publicly accessible files or directories. This reduces the potential size of the audit trail while not compromising security, because the viewing of publicly accessible files and directories is not generally interesting for audit purposes. Files so marked do not generate audit records for the following audit events, even if the classes for those events are turned on for auditing:

  AUE_ACCESS, AUE_STAT, AUE_LSTAT, AUE_READLINK, AUE_STATFS, AUE_FSTATFS, AUE_PATHCONF, AUE_OPEN_R, AUE_FGETCMWLABEL, AUE_GETCMWFSRANGE, AUE_GETCMWLABEL, AUE_GETFILEPRIV, AUE_LGETCMWLABEL, AUE_GETMLDADORN, AUE_GETSLDNAME, AUE_OSTAT, AUE_FUSERS, AUE_STATVFS, AUE_XSTAT, and AUE_LXSTAT. The list may not be exhaustive.

  See To Set Public Object Bit for the procedure.

• Reducing the disk-storage requirements for audit files by combining, reducing, and compressing them (see To Combine Selected Audit Files ), and developing procedures for storing them offline.

Setting Audit Policies

The auditconfig command provides a command line interface to get and set audit configuration information and audit policy. It can be used in the audit_startup(1M) script to set audit policies when the audit daemon is started. See the auditconfig(1M) man page and Dynamic Auditing (Tasks), for examples of the use of the auditconfig command.

You can use auditconfig with the -setpolicy option to change the default Trusted Solaris audit policies. Setting audit policies means to add optional audit tokens to the audit record. The auditconfig command with the -lspolicy argument shows the audit policies that are optional. See To Determine Current Audit Policy for the audit policies and their short descriptions. The following gives longer descriptions of the less easily understood policy flags.

To run auditing in an evaluated configuration, you cannot have the cnt policy or the passwd policy turned on. They must be turned off.

ahlt

Halt the computer if an asynchronous audit event occurs which can not be delivered to the audit queue. The default is not to halt the system.

cnt

Do not suspend auditable actions when the queue is full. Count how many audit records are dropped. The default is suspend.

To return to the default, remove the cnt policy. See To Set Audit Policy Temporarily for examples of replacing, adding, and removing audit policies.

path

Add secondary path tokens to audit record. These secondary paths are typically the pathnames of dynamically linked shared libraries or command interpreters for shell scripts. By default they are not included.

seq

Include a sequence number in every audit record. The default is to not include. (The sequence number could be used to analyze a crash dump to find out whether any audit records are lost.)