HPlogo HP-UX Reference Volume 5 of 5 > a

audit(5)

» 

Technical documentation

Complete book in PDF

 » Table of Contents

 » Index

NAME

audit — introduction to HP-UX Auditing System

SYNOPSIS

#include <sys/audit.h>

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 deterrant 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. Users are assigned unique identifiers called audit ids by the administrator which remain unchanged throughout a user's history. The audusr(1M) command is used to specify those users who are to be audited. The audevent(1M) command is used to specify system activities (auditable events) that are to be audited. Auditable events are classified into several categories, illustrated by the event category list at the end. (An event category consists of a set of operations that affect a particular aspect of the system.)

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 include: at(1), chfn(1), chsh(1), crontab(1), login(1), newgrp(1), passwd(1), audevent(1M), audisp(1M), audsys(1M), audusr(1M), cron(1M), init(1M), lpsched(1M), pwck(1M), and sam(1M). Note that only these privileged programs are allowed to do self-auditing, and that the audit suspension they perform only affects these programs and does not affect any other processes on the system.

Viewing of Audited Data

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

Monitoring the Auditing System

To ensure that the auditing system operates normally and that any abnormal behaviors are detected, a privileged daemon program, audomon(1M), 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(1M) prints warning messages and tries to resolve the problem if possible.

Starting and Halting the Auditing System

The administrator can use the audsys(1M) 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(1M) also validates the parameters specified, and ensures that the auditing system is in a safe and consistent state.

Audit Log Files

At any time when the auditing system is enabled, at least an audit log file must be present, and another back-up log file is highly recommended. Both of these files (along with various attributes for these files) can be specified using audsys(1M). When the current log file exceeds a pre-specified size, or when the auditing file system is dangerously full, the system automatically switches to the back-up file if possible. If a back-up log file is not available, warning messages are sent to request appropriate administrator action.

Event Categories

create

Log creations of objects (files, directories, other objects), including creat(2), mkdir(2), mknod(2), msgget(2), pipe(2), semget(2), shmat(2), and shmget(2).

delete

Log all deletions of objects (files, directories, other objects), including ksem_unlink(2), mq_unlink(2), msgctl(2) rmdir(2) semctl(2), and shm_unlink(2).

readdac

Log reads of Discretionary access control (DAC) information including access(2), fstat(2), fstat64(2), getaccess(2), lstat(2), lstat64(2), stat(2), stat64(2).

moddac

Log all modifications of object's Discretionary access control (DAC) information including chmod(2), chown(2), fchmod(2), fchown(2), fsetacl(2), setacl(2), and umask(2).

modaccess

Log all modifications other than DAC, including chdir(2), chroot(2), link(2), lockf64(2), newgrp(1), rename(2), setgid(2), setgroups(2), setresgid(2), setresuid(2), setuid(2), shmctl(2), shmdt(2), and unlink(2).

open

Log all openings of objects (file open, other objects' open) including execv(2), execve(2), ftruncate(2), ftruncate64(2), kload(2), ksem_open(2), lpsched(1M), mmap64(2), mq_open(2), open(2), ptrace(2), shm_open(2), truncate(2), and truncate64(2).

close

Log all closings of objects (file close, other objects' close) including close(2), ksem_close(2), and mq_close(2).

process

Log all operations on processes, including exit(2), fork(2), kill(2), mlock(2), mlockall(2), munlock(2), munlockall(2), setcontext(2), setrlimit64(2), sigqueue(2), ulimit64(2), and vfork(2).

removable

Log all removable media events (mounting and unmounting events), including mount(2), umount(2), and vfsmount(2).

login

Log all logins and logouts, including login(1), init(1M).

admin

Log all administrative and privileged events, including audevent(1M), audisp(1M), audswitch(2), audsys(1M), audusr(1M), chfn(1), chsh(1), init(1M), passwd(1), pwck(1M), reboot(2), sam(1M), setaudid(2), setaudproc(2), setdomainname(2), setevent(2), sethostid(2), settimeofday(2), stime(2), and swapon(2).

ipccreat

Log all IPC create events including socket(2) and bind(2).

ipcopen

Log all IPC open events including connect(2) and accept(2).

ipcclose

Log all IPC close events including shutdown(2).

uevent1

Log user-defined event.

uevent2

Log user-defined event.

uevent3

Log user-defined event.

ipcdgram

Log IPC Datagram transactions.

For a complete description of system call assignments to event types, see audevent(1M).

Note that some commands such as init(1M) may occur in more than one category because the event varies, depending on the operation done by the command.

AUTHOR

The auditing system described above was developed by HP.

© Hewlett-Packard Development Company, L.P.