From 43b8eb7340673325309de7378bc65dc0dcab9e88 Mon Sep 17 00:00:00 2001 From: Robert Watson Date: Sat, 4 Feb 2006 20:54:08 +0000 Subject: [PATCH] Some edits of the audit handbook chapter: Rename section "Security Event Auditing" from "Kernel Event Auditing" -- while most of our events are currently generated by the kernel, the intent is that it will be whole system auditing. More carefully distinguish our implementation being based on Sun's published API and file format, and not their implementation. Clarify a few more things audit can be used for, including post-mortem analysis and intrusion detection. Mention Mac OS X compatibility in addition to Darwin. Sort glossary slightly differently -- events before classes, since classes are defined in terms of events. Tweak definition and examples. Mention non-attributable vs attributable here. Mention that classes allow administrators to specify auditing requirements at a high level. Describe contents of a record. Define 'trail'. Since audit is now part of the base system, remove directions for installing files, etc, since complete installs should have them, and if they don't, the user should seek support. Mention that audit trails are happiest on a file system of their own. Update example flags option in audit_control -- add information on the new default, but keep the current example because the new default doesn't reflect the scope of possible expressions, whereas the earlier example did. Rephrase paragraph on avoiding directly manipulating logs in order to explain that this is because the kernel/daemon own the log until it is terminated. Correct example: auditreduce just reduces, not prints, so |praudit is needed or the user will experience the power of raw BSM's effects on his or her terminal. Much suggested by: brueffer Reviewed by: brueffer --- .../books/handbook/audit/chapter.sgml | 124 +++++++++++------- 1 file changed, 78 insertions(+), 46 deletions(-) diff --git a/en_US.ISO8859-1/books/handbook/audit/chapter.sgml b/en_US.ISO8859-1/books/handbook/audit/chapter.sgml index e13893dd2a..a7a172bd8e 100644 --- a/en_US.ISO8859-1/books/handbook/audit/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/audit/chapter.sgml @@ -21,23 +21,23 @@ requirements. --> - Kernel Event Auditing + Security Event Auditing Synopsis AUDIT - Kernel Event Auditing + Security Event Auditing MAC The &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 @@ requirements. --> 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,22 +109,47 @@ requirements. --> - 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 @@ -136,7 +161,7 @@ requirements. --> 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 @@ requirements. --> 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 @@ requirements. --> we see the following: dir:/var/audit -flags:lo,ad,-all,^-fa,^-fc,^-cl +flags:lo minfree:20 naflags:lo The 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 @@ naflags:lo 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 <filename>audit_user</filename> File The 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 @@ audit:fc:no 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 command; 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 @@ audit:fc:no command, where trhodes is the user of choice: - &prompt.root; auditreduce -e trhodes /var/audit/AUDITFILE + &prompt.root; auditreduce -e trhodes /var/audit/AUDITFILE | praudit This will select all audit records produced by the user trhodes stored in the @@ -496,13 +524,17 @@ audit:fc:no 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