audit man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

audit(5)							      audit(5)

       audit - introduction to HP-UX Auditing System

       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

       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

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

       HP-UX 11i Version 3 is the last	release	 to  support  trusted  systems

       The  HP-UX  Auditing  System  continues	to  work without converting to
       trusted mode.

       The auditing system described above was developed by HP.

       audevent(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),


List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net