audit(5)

User and Event Selection

The auditing system provides administrators with a mechanism to select users and activities to be audited.

On a system that has been converted to trusted mode, users are assigned unique identifiers called audit IDs by the administrator, which remain unchanged throughout a user's history. See WARNINGS about trusted mode. The audusr command is used to specify those users who are to be audited.

On a system that has not been converted to trusted mode, each login session is assigned a unique identifier called audit tag. The audit tag is a string representing information such as user name and login time. It can uniquely identify each login session and the person responsible for the session. See also setauduser(3) and getauduser(3). The userdbset command is used to specify those users who are to be audited. See userdbset(1M) and userdb(4). The associated attribute is called AUDIT_FLAG and is described in security(4).

The audevent command is used to specify system activities (auditable events) that are to be audited. Auditable events are classified into event categories and profiles for easier configuration. Once an event category or a profile is selected, all system calls and self-auditing events associated with that event category or profile are selected. When the auditing system is installed, a default set of event classification information is provided in file /etc/audit/audit.conf. In order to meet site-specific requirements, administrators may also define event categories and profiles in /etc/audit/audit_site.conf. See audit.conf(4) and audevent(1M) for more information.

Note that even if an user is not selected for auditing, it is expected that some records may still be generated at the time user starts a session and ends a session. Those are considered as system-wise information that are more in favor of event selection than the user selection. Other programs that do self-auditing may also make arbitrary decision to ignore the user selection though it is not recommended. More information about self-auditing programs can be found later.

Starting and Halting the Auditing System

The administrator can use the audsys command to start or halt the auditing system, or to get a brief summary of the status of the audit system. Prior to starting the auditing system, audsys also validates the parameters specified, and ensures that the auditing system is in a safe and consistent state. See audsys(1M) for more information.

Monitoring the Auditing System

To ensure that the auditing system operates normally and to detect abnormal behaviors, a privileged daemon program, audomon, runs in the background to monitor various auditing system parameters. When these parameters take on abnormal (dangerous) values, or when components of the auditing system are accidentally removed, audomon prints warning messages and tries to resolve the problem if possible. See audomon(1M) for more information. audomon can be spawned by /sbin/init.d/auditing (as part of the init start-up process) when the system is booted up if the parameter AUDITING is set to 1 in file /etc/rc.config.d/auditing. It can also be started any time by a privileged user.

Viewing of Audited Data

The audisp command is used to view audited data recorded in log files. The audisp command merges the log files into a single audit trail in chronological sequence. The administrator can select viewing criteria provided by the audisp command to limit the search to particular kinds of events which the administrator is interested in investigating.

Audit Trails

At any time when the auditing system is enabled, at least an audit trail must be present. The trail name and various attributes for the trail can be specified using audsys. When the current trail exceeds the specified size, or when the auditing file system is dangerously full, the system automatically switches to another trail with the same base name but a different timestamp extension and begin recording to it. A script can be specified using audomon to perform various operations on the last audit trail after each successful switch. If trail switch is unsuccessful, warning messages are sent to request appropriate administrator action.

Self-auditing Programs

To reduce the amount of log data and to provide a higher-level recording of some typical system operations, a collection of privileged programs are given capabilities to perform self-auditing. This means that the programs can suspend the currently specified auditing on themselves and produce a high-level description of the operations they perform. These self-auditing programs are described in the following manpages: at(1), chfn(1), chsh(1), crontab(1), login(1), newgrp(1), passwd(1), audevent(1M), audisp(1M), audsys(1M), audusr(1M), cron(1M), groupadd(1M), groupdel(1M), groupmod(1M), init(1M), lpsched(1M), sam(1M), useradd(1M), userdel(1M), and usermod(1M).

Most of these commands generate audit data under a single event category. For example, SAM generates the audit data under the event admin. Other commands may generate data under multiple event categories. For example, the init command generates data under the events login and admin. For a list of predefined event categories, see audevent(1M).