Kernel Event Auditing
+ Security Event AuditingSynopsisAUDIT
- Kernel Event Auditing
+ Security Event AuditingMACThe &os; 7-CURRENT development branch includes
support for Event Auditing based on the &posix;.1e draft and
- the &sun; BSM implementation. Event auditing
+ the &sun;'s published BSM API and file format. Event auditing
permits the selective logging of security-relevant system events
- for the purposes of system analysis, system monitoring, and
- security evaluation. After some settling time in &os; 7-CURRENT,
+ for the purposes of post-mortem analysis, system monitoring, and
+ intrusion detection. After some settling time in &os; 7-CURRENT,
this support will be merged to &os; 6-STABLE and appear
in subsequent releases.
@@ -96,7 +96,7 @@
The implementation of Event Auditing in &os; is similar to
that of the &sun; Basic Security Module, or BSM
library. Thus, the configuration is almost completely
- interchangeable with &solaris; and Darwin operating systems.
+ interchangeable with &solaris; and Mac OS X/Darwin operating systems.
@@ -109,23 +109,48 @@
- class: A class specifies the category
- different actions the system are placed in. For example,
- use of &man.login.1; could be placed in a class.
+ event: An auditable event is
+ an event that can be logged using the audit subsystem. The
+ administrator can configure which events will be audited.
+ Examples of security-relevant events include the creation of
+ a file, the building of a network connection, or the logging
+ in of a user. Events are either attributable,
+ meaning that they can be traced back to a user
+ authentication, or non-attributable. Examples
+ of non-attributable events are any events that occur before
+ authentication has succeeded in the login process, such as
+ failed authentication attempts.
- event: An event could be considered
- an action taken on the system. Creating a file would be
- an event.
+ class: Events may be assigned to
+ one or more classes, usually based on the general category
+ of the events, such as file creation,
+ file access, or network. Login
+ and logout events are assigned to the lo
+ class. The use of classes allows the administrator to
+ specify high level auditing rules without having to specify
+ whether each individual auditable operation will be logged.
- record: A record is a log or a note
- about a specific action.
+ record: A record is a log entry
+ describing a security event. Records typically have a
+ record event type, information on the subject (user) associated
+ with the event, time information, information on any objects,
+ such as files, and information on whether the event corresponded
+ to a successful operation.
+ trail: An audit trail, or log file,
+ consists of a series of audit records describing security
+ events. Typically, trails are in roughly chronological
+ order with respect to the time events completed. Only
+ authorized processes are allowed to commit records to the
+ audit trail.
+
+ prefix: A prefix is considered to
be the configuration element used to toggle auditing for
success and failed events.
@@ -136,7 +161,7 @@
Installing Audit Support
- Support for Event Auditing should have been installed with
+ Support for Event Auditing is installed with
the normal installworld process. An
administrator may confirm this by viewing the contents
of /etc/security. Files
@@ -190,21 +215,19 @@
audit_user - The events to audit
- for individual users. A user name does not need to appear
- in here.
+ for individual users. Users not appearing here will be
+ subject to the default configuration in the control
+ configuration file.audit_warn - A shell script
- used by auditd to form warning messages.
+ used by auditd to generate warning messages in
+ exceptional situations, such as when space for audit
+ records is running low.
- If these files do not exist, for whatever reason, they can
- be installed easily by issuing the following commands:
-
- &prompt.root; cd /usr/src/contrib/bsm/etc && make install
-
Audit File Syntax
@@ -392,15 +415,21 @@
we see the following:
dir:/var/audit
-flags:lo,ad,-all,^-fa,^-fc,^-cl
+flags:lo
minfree:20
naflags:loThe option is used to set the default
- directory where audit logs are stored.
+ directory where audit logs are stored. Audit is frequently
+ configured so that audit logs are stored on a dedicated file
+ system, so as to prevent interference between the audit
+ subsystem and other subsystems when file systems become full.
+
The option is used to set the
- system-wide defaults. The current setting,
+ system-wide defaults. The current setting,
+ configures the auditing of all &man.login.1; and &man.logout.1;
+ actions. A more complex example,
audits all system
&man.login.1; and &man.logout.1; actions, all administrator
actions, all failed events in the system, and finally disables
@@ -426,19 +455,17 @@
to eighty (80) percent full.The option specifies audit
- flags to be considered non attributable; i.e.: classes of
- events which cannot be attributed to a specific user
- on the system. This can be overridden with the
- audit_user configuration file.
+ classes to be audited for non-attributed events —
+ that is, events for which there is no authenticated user.
+
The audit_user FileThe audit_user file permits the
- administrator to map audit specific events directly
- to users. This adds a finer-grained control mechanism
- for all system users.
+ administrator to determine which classes of audit events
+ should be logged for which system users.
The following is the defaults currently placed in
the audit_user file:
@@ -462,15 +489,16 @@
Event Audit Administration
- Events from the auditd daemon cannot
+ Events written by the kernel audit subsystem cannot
be altered or read in plain text. Data is stored and accessed
in a method similar to that of &man.ktrace.1; and &man.kdump.1;,
that is, they may only be viewed by dumping them using the
- praudit or auditreduce
- utilities.
+ praudit; audit trails may be reduced using
+ the auditreduce command, which selects records
+ from an audit trail based on properties of interest, such as the
+ user, time of the event, and type of operation.
- There are two utilities because of different requirements.
- For example, the praudit utility will dump the
+ For example, the praudit utility will dump the
entire contents of a specified audit log in plain text. To dump an
audit log in its entirety, use:
@@ -483,7 +511,7 @@
command, where trhodes is the user of
choice:
- &prompt.root; auditreduce -e trhodes /var/audit/AUDITFILE
+ &prompt.root; auditreduce -e trhodes /var/audit/AUDITFILE | prauditThis will select all audit records produced by the user
trhodes stored in the
@@ -496,13 +524,17 @@
Rotating Audit Log Files
- Manually rotating audit log files will cause great
- havoc within the system. Therefore, adding a line to
- &man.newsyslog.conf.5; will provide no usefulness. So how
- are the logs to be rotated? Sending the appropriate flag
- to the audit utility will shut down
- event auditing and safely rotate. The following command
- should handle everything for an administrator:
+ Because of log reliability requirements, audit trails
+ are written to only by the kernel, and managed only by
+ auditd. Administrators should not
+ attempt to use &man.newsyslog.conf.5& or other tools to
+ directly rotate audit logs. Instead, the audit
+ management tool should be used to shut down auditing,
+ reconfigure the audit system, and perform log rotation.
+ The following command causes the audit daemon to create a
+ new audit log and signal the kernel to switch to using the
+ new log. The old log will be terminated and renamed, at
+ which point it may then be manipulated by the administrator.&prompt.root; audit -n