Index: chapter.sgml =================================================================== RCS file: /data/fbsd-cvs/ncvs/doc/en_US.ISO8859-1/books/handbook/audit/chapter.sgml,v retrieving revision 1.7 diff -u -r1.7 chapter.sgml --- chapter.sgml 4 Feb 2006 07:57:25 -0000 1.7 +++ chapter.sgml 4 Feb 2006 20:43:09 -0000 @@ -21,23 +21,23 @@ - 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 @@ 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: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 @@ 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 @@ 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 | praudit This 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