audit(5)audit(5)NAMEaudit - introduction to HP-UX Auditing System
DESCRIPTION
The purpose of the auditing system is to record instances of access by
subjects to objects and to allow detection of any (repeated) attempts
to bypass the protection mechanism and any misuses of privileges, thus
acting as a deterrent against system abuses and exposing potential
security weaknesses in the system.
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 by the administrator, which remain unchanged
throughout a user's history. See about trusted mode. The 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 The is a string repre‐
senting 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 command is used to spec‐
ify those users who are to be audited. See userdbset(1M) and
userdb(4). The associated attribute is called and is described in
security(4).
The 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 cate‐
gory 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 classifi‐
cation information is provided in file In order to meet site-specific
requirements, administrators may also define event categories and pro‐
files in 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 ses‐
sion and ends a session. Those are considered as system-wise informa‐
tion 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 infor‐
mation about self-auditing programs can be found later.
Starting and Halting the Auditing System
The administrator can use the 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, also validates the parameters
specified, and ensures that the auditing system is in a safe and con‐
sistent 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 program, runs in the background to
monitor various auditing system parameters. When these parameters take
on abnormal (dangerous) values, or when components of the auditing sys‐
tem are accidentally removed, prints warning messages and tries to
resolve the problem if possible. See audomon(1M) for more information.
can be spawned by (as part of the start-up process) when the system is
booted up if the parameter AUDITING is set to 1 in file It can also be
started any time by a privileged user.
Viewing of Audited Data
The command is used to view audited data recorded in log files. The
command merges the log files into a single audit trail in chronological
sequence. The administrator can select viewing criteria provided by
the 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 When the current trail exceeds the speci‐
fied 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 to perform various operations on the last
audit trail after each successful switch. If trail switch is unsuc‐
cessful, 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 record‐
ing of some typical system operations, a collection of privileged pro‐
grams 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).
Note: Only privileged programs are allowed to do self-auditing.
The audit suspension they perform only affects these programs
and does not affect any other processes on the system.
Most of these commands generate audit data under a single event cate‐
gory. For example, generates the audit data under the event admin.
Other commands may generate data under multiple event categories. For
example, the command generates data under the events login and admin.
For a list of predefined event categories, see audevent(1M).
WARNINGS
HP-UX 11i Version 3 is the last release to support trusted systems
functionality.
The HP-UX Auditing System continues to work without converting to
trusted mode.
AUTHOR
The auditing system described above was developed by HP.
SEE ALSOaudevent(1M), audisp(1M), audsys(1M), audusr(1M), userdbset(1M), aud‐
ctl(2), audswitch(2), audwrite(2), getaudid(2), getevent(2), setau‐
did(2), setevent(2), getauduser(3), setauduser(3), audit(4), secu‐
rity(4), userdb(4), audit_memory_usage(5), audit_track_paths(5),
diskaudit_flush_interval(5).
audit(5)
