From owner-svn-doc-all@FreeBSD.ORG Sun Oct 28 00:58:36 2012 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B61441E9; Sun, 28 Oct 2012 00:58:36 +0000 (UTC) (envelope-from wblock@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 9C1758FC08; Sun, 28 Oct 2012 00:58:36 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q9S0wa51095597; Sun, 28 Oct 2012 00:58:36 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.4/8.14.4/Submit) id q9S0waDH095595; Sun, 28 Oct 2012 00:58:36 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201210280058.q9S0waDH095595@svn.freebsd.org> From: Warren Block Date: Sun, 28 Oct 2012 00:58:36 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r39825 - head/en_US.ISO8859-1/books/handbook/audit X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 00:58:36 -0000 Author: wblock Date: Sun Oct 28 00:58:36 2012 New Revision: 39825 URL: http://svn.freebsd.org/changeset/doc/39825 Log: Whitespace-only fixes. Translators, please ignore. Modified: head/en_US.ISO8859-1/books/handbook/audit/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/audit/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/audit/chapter.xml Sun Oct 28 00:38:22 2012 (r39824) +++ head/en_US.ISO8859-1/books/handbook/audit/chapter.xml Sun Oct 28 00:58:36 2012 (r39825) @@ -44,18 +44,19 @@ requirements. --> changes, and file and network access. These log records can be invaluable for live system monitoring, intrusion detection, and postmortem analysis. &os; implements &sun;'s published - BSM API and file format, and is interoperable with - both &sun;'s &solaris; and &apple;'s &macos; X audit implementations. - - This chapter focuses on the installation and configuration of - Event Auditing. It explains audit policies, and provides an example - audit configuration. + BSM API and file format, and is interoperable + with both &sun;'s &solaris; and &apple;'s &macos; X audit + implementations. + + This chapter focuses on the installation and configuration + of Event Auditing. It explains audit policies, and provides an + example audit configuration. After reading this chapter, you will know: - What Event Auditing is and how it works. + What Event Auditing is and how it works. @@ -64,8 +65,8 @@ requirements. --> - How to review the audit trail using the audit reduction and - review tools. + How to review the audit trail using the audit reduction + and review tools. @@ -90,59 +91,60 @@ requirements. --> - The audit facility has some known limitations which include - that not all security-relevant system events are currently auditable, - and that some login mechanisms, such as X11-based display managers - and third party daemons, do not properly configure auditing for user - login sessions. - - The security event auditing facility is able to generate very - detailed logs of system activity: on a busy system, trail file - data can be very large when configured for high detail, exceeding - gigabytes a week in some configurations. Administrators should take - into account disk space requirements associated with high volume - audit configurations. For example, it may be desirable to dedicate - a file system to the /var/audit tree so that - other file systems are not affected if the audit file system becomes + The audit facility has some known limitations which + include that not all security-relevant system events are + currently auditable, and that some login mechanisms, such as + X11-based display managers and third party daemons, do not + properly configure auditing for user login sessions. + + The security event auditing facility is able to generate + very detailed logs of system activity: on a busy system, trail + file data can be very large when configured for high detail, + exceeding gigabytes a week in some configurations. + Administrators should take into account disk space + requirements associated with high volume audit configurations. + For example, it may be desirable to dedicate a file system to + the /var/audit tree so that other file + systems are not affected if the audit file system becomes full. - Key Terms in This Chapter - Before reading this chapter, a few key audit-related terms must be - explained: + Before reading this chapter, a few key audit-related terms + must be explained: - event: An auditable event is any event - that can be logged using the audit subsystem. + event: An auditable event is any + event that can be logged using the audit subsystem. Examples of security-relevant events include the creation of - a file, the building of a network connection, or a user logging in. - Events are either attributable, + a file, the building of a network connection, or a user + logging in. Events are either attributable, meaning that they can be traced to an authenticated user, or - non-attributable if they cannot be. - Examples of non-attributable events are any events that occur - before authentication in the login process, such as bad password + non-attributable if they cannot be. Examples + of non-attributable events are any events that occur before + authentication in the login process, such as bad password attempts. - class: Event classes are named sets of - related events, and are used in selection expressions. Commonly - used classes of events include file creation (fc), - exec (ex) and login_logout - (lo). + class: Event classes are named sets + of related events, and are used in selection expressions. + Commonly used classes of events include + file creation (fc), exec (ex) + and login_logout (lo). - record: A record is an audit log entry - describing a security event. Records contain a record event type, - information on the subject (user) performing the action, - date and time information, information on any objects or - arguments, and a success or failure condition. + record: A record is an audit log + entry describing a security event. Records contain a record + event type, information on the subject (user) performing the + action, date and time information, information on any + objects or arguments, and a success or failure + condition. @@ -156,30 +158,31 @@ requirements. --> selection expression: A selection - expression is a string containing a list of prefixes and audit - event class names used to match events. + expression is a string containing a list of prefixes and + audit event class names used to match events. - preselection: The process by which the - system identifies which events are of interest to the administrator - in order to avoid generating audit records describing events that - are not of interest. The preselection configuration - uses a series of selection expressions to identify which classes - of events to audit for which users, as well as global settings - that apply to both authenticated and unauthenticated - processes. + preselection: The process by which + the system identifies which events are of interest to the + administrator in order to avoid generating audit records + describing events that are not of interest. The + preselection configuration uses a series of selection + expressions to identify which classes of events to audit for + which users, as well as global settings that apply to both + authenticated and unauthenticated processes. - reduction: The process by which records - from existing audit trails are selected for preservation, printing, - or analysis. Likewise, the process by which undesired audit - records are removed from the audit trail. Using reduction, - administrators can implement policies for the preservation of audit - data. For example, detailed audit trails might be kept for one - month, but after that, trails might be reduced in order to preserve - only login information for archival purposes. + reduction: The process by which + records from existing audit trails are selected for + preservation, printing, or analysis. Likewise, the process + by which undesired audit records are removed from the audit + trail. Using reduction, administrators can implement + policies for the preservation of audit data. For example, + detailed audit trails might be kept for one month, but after + that, trails might be reduced in order to preserve only + login information for archival purposes. @@ -187,11 +190,11 @@ requirements. --> Installing Audit Support - User space support for Event Auditing is installed as part of the - base &os; operating system. Kernel support for - Event Auditing is compiled in by default, but support for this - feature must be explicitly compiled into the custom kernel by adding - the following line to the kernel configuration file: + User space support for Event Auditing is installed as part + of the base &os; operating system. Kernel support for Event + Auditing is compiled in by default, but support for this feature + must be explicitly compiled into the custom kernel by adding the + following line to the kernel configuration file: options AUDIT @@ -199,14 +202,14 @@ requirements. --> the kernel via the normal process explained in . - Once an audit-enabled kernel is built, installed, and the system - has been rebooted, enable the audit daemon by adding the following line - to &man.rc.conf.5;: + Once an audit-enabled kernel is built, installed, and the + system has been rebooted, enable the audit daemon by adding the + following line to &man.rc.conf.5;: auditd_enable="YES" - Audit support must then be started by a reboot, or by manually - starting the audit daemon: + Audit support must then be started by a reboot, or by + manually starting the audit daemon: /etc/rc.d/auditd start @@ -215,8 +218,9 @@ requirements. --> Audit Configuration All configuration files for security audit are found in - /etc/security. The following - files must be present before the audit daemon is started: + /etc/security. The + following files must be present before the audit daemon is + started: @@ -233,8 +237,8 @@ requirements. --> audit_event - Textual names and - descriptions of system audit events, as well as a list of which - classes each event is in. + descriptions of system audit events, as well as a list of + which classes each event is in. @@ -244,10 +248,11 @@ requirements. --> - audit_warn - A customizable shell script - used by auditd to generate warning messages in exceptional - situations, such as when space for audit records is running low or - when the audit trail file has been rotated. + audit_warn - A customizable shell + script used by auditd to generate + warning messages in exceptional situations, such as when + space for audit records is running low or when the audit + trail file has been rotated. @@ -260,70 +265,76 @@ requirements. --> Event Selection Expressions - Selection expressions are used in a number of places in the - audit configuration to determine which events should be audited. - Expressions contain a list of event classes to match, each with - a prefix indicating whether matching records should be accepted - or ignored, and optionally to indicate if the entry is intended - to match successful or failed operations. Selection expressions - are evaluated from left to right, and two expressions are - combined by appending one onto the other. + Selection expressions are used in a number of places in + the audit configuration to determine which events should be + audited. Expressions contain a list of event classes to match, + each with a prefix indicating whether matching records should + be accepted or ignored, and optionally to indicate if the + entry is intended to match successful or failed operations. + Selection expressions are evaluated from left to right, and + two expressions are combined by appending one onto the + other. - The following list contains the default audit event classes - present in audit_class: + The following list contains the default audit event + classes present in audit_class: - all - all - Match all - event classes. + all - all - + Match all event classes. - ad - administrative - - Administrative actions performed on the system as a - whole. + ad - + administrative - Administrative + actions performed on the system as a whole. - ap - application - - Application defined action. + ap - + application - Application defined + action. - cl - file close - - Audit calls to the close system - call. + cl - + file close - Audit calls to the + close system call. - ex - exec - Audit - program execution. Auditing of command line arguments and - environmental variables is controlled via &man.audit.control.5; - using the argv and envv - parameters to the policy setting. + ex - exec - + Audit program execution. Auditing of command line + arguments and environmental variables is controlled via + &man.audit.control.5; using the argv + and envv parameters to the + policy setting. - fa - file attribute access - - Audit the access of object attributes such as - &man.stat.1;, &man.pathconf.2; and similar events. + fa - + file attribute access - Audit the + access of object attributes such as &man.stat.1;, + &man.pathconf.2; and similar events. - fc - file create - - Audit events where a file is created as a result. + fc - + file create - Audit events where a + file is created as a result. - fd - file delete - - Audit events where file deletion occurs. + fd - + file delete - Audit events where file + deletion occurs. - fm - file attribute modify - - Audit events where file attribute modification occurs, - such as &man.chown.8;, &man.chflags.1;, &man.flock.2;, - etc. + fm - + file attribute modify - Audit events + where file attribute modification occurs, such as + &man.chown.8;, &man.chflags.1;, &man.flock.2;, etc. @@ -333,36 +344,40 @@ requirements. --> - fw - file write - - Audit events in which data is written, files are written - or modified, etc. + fw - + file write - Audit events in which + data is written, files are written or modified, + etc. - io - ioctl - Audit - use of the &man.ioctl.2; system call. + io - ioctl - + Audit use of the &man.ioctl.2; system call. - ip - ipc - Audit - various forms of Inter-Process Communication, including POSIX - pipes and System V IPC operations. + ip - ipc - + Audit various forms of Inter-Process Communication, + including POSIX pipes and System V IPC + operations. - lo - login_logout - - Audit &man.login.1; and &man.logout.1; events occurring - on the system. + lo - + login_logout - Audit &man.login.1; + and &man.logout.1; events occurring on the system. - na - non attributable - - Audit non-attributable events. + na - + non attributable - Audit + non-attributable events. - no - invalid class - - Match no audit events. + no - + invalid class - Match no audit + events. @@ -384,19 +399,19 @@ requirements. --> - These audit event classes may be customized by modifying the - audit_class and + These audit event classes may be customized by modifying + the audit_class and audit_event configuration files. Each audit class in the list is combined with a prefix - indicating whether successful/failed operations are matched, and - whether the entry is adding or removing matching for the class - and type. + indicating whether successful/failed operations are matched, + and whether the entry is adding or removing matching for the + class and type. - (none) Audit both successful and failed instances of the - event. + (none) Audit both successful and failed instances of + the event. @@ -410,45 +425,44 @@ requirements. --> - ^ Audit neither successful nor failed - events in this class. + ^ Audit neither successful nor + failed events in this class. - ^+ Do not audit successful events in this - class. + ^+ Do not audit successful events + in this class. - ^- Do not audit failed events in this - class. + ^- Do not audit failed events in + this class. - - The following example selection string selects both successful - and failed login/logout events, but only successful execution - events: + The following example selection string selects both + successful and failed login/logout events, but only successful + execution events: lo,+ex - Configuration Files - In most cases, administrators will need to modify only two files - when configuring the audit system: audit_control - and audit_user. The first controls system-wide - audit properties and policies; the second may be used to fine-tune - auditing by user. + In most cases, administrators will need to modify only two + files when configuring the audit system: + audit_control and + audit_user. The first controls + system-wide audit properties and policies; the second may be + used to fine-tune auditing by user. - The <filename>audit_control</filename> File + The <filename>audit_control</filename> File - The audit_control file specifies a number - of defaults for the audit subsystem. Viewing the contents of this - file, we see the following: + The audit_control file specifies a + number of defaults for the audit subsystem. Viewing the + contents of this file, we see the following: dir:/var/audit flags:lo @@ -457,71 +471,73 @@ naflags:lo policy:cnt filesz:0 - The option is used to set one or more - directories where audit logs will be stored. If more than one - directory entry appears, they will be used in order as they fill. - It is common to configure audit so that audit logs are stored on - a dedicated file system, in order to prevent interference between - the audit subsystem and other subsystems if the file system fills. - - - The field sets the system-wide default - preselection mask for attributable events. In the example above, - successful and failed login and logout events are audited for all - users. + The option is used to set one or + more directories where audit logs will be stored. If more + than one directory entry appears, they will be used in order + as they fill. It is common to configure audit so that audit + logs are stored on a dedicated file system, in order to + prevent interference between the audit subsystem and other + subsystems if the file system fills. + + The field sets the system-wide + default preselection mask for attributable events. In the + example above, successful and failed login and logout events + are audited for all users. The option defines the minimum - percentage of free space for the file system where the audit trail - is stored. When this threshold is exceeded, a warning will be - generated. The above example sets the minimum free space to - twenty percent. - - The option specifies audit classes to - be audited for non-attributed events, such as the login process - and system daemons. - - The option specifies a comma-separated - list of policy flags controlling various aspects of audit - behavior. The default cnt flag indicates that - the system should continue running despite an auditing failure - (this flag is highly recommended). Another commonly used flag is - argv, which causes command line arguments to - the &man.execve.2; system call to be audited as part of command - execution. + percentage of free space for the file system where the audit + trail is stored. When this threshold is exceeded, a warning + will be generated. The above example sets the minimum free + space to twenty percent. + + The option specifies audit + classes to be audited for non-attributed events, such as the + login process and system daemons. + + The option specifies a + comma-separated list of policy flags controlling various + aspects of audit behavior. The default + cnt flag indicates that the system should + continue running despite an auditing failure (this flag is + highly recommended). Another commonly used flag is + argv, which causes command line arguments + to the &man.execve.2; system call to be audited as part of + command execution. - The option specifies the maximum size - in bytes to allow an audit trail file to grow to before + The option specifies the maximum + size in bytes to allow an audit trail file to grow to before automatically terminating and rotating the trail file. The - default, 0, disables automatic log rotation. If the requested - file size is non-zero and below the minimum 512k, it will be - ignored and a log message will be generated. + default, 0, disables automatic log rotation. If the + requested file size is non-zero and below the minimum 512k, + it will be ignored and a log message will be + generated. The <filename>audit_user</filename> File The audit_user file permits the - administrator to specify further audit requirements for specific - users. - Each line configures auditing for a user via two fields: the - first is the alwaysaudit field, which specifies - a set of events that should always be audited for the user, and + administrator to specify further audit requirements for + specific users. Each line configures auditing for a user + via two fields: the first is the + alwaysaudit field, which specifies a set + of events that should always be audited for the user, and the second is the neveraudit field, which - specifies a set of events that should never be audited for the - user. + specifies a set of events that should never be audited for + the user. - The following example audit_user file - audits login/logout events and successful command execution for - the root user, and audits file creation and successful command - execution for the www user. - If used with the example audit_control file - above, the lo entry for root - is redundant, and login/logout events will also be audited for the - www user. + The following example audit_user + file audits login/logout events and successful command + execution for the root user, and audits + file creation and successful command execution for the + www user. If used with the example + audit_control file above, the + lo entry for root is + redundant, and login/logout events will also be audited for + the www user. root:lo,+ex:no www:fc,+ex:no - @@ -532,29 +548,32 @@ www:fc,+ex:no Viewing Audit Trails - Audit trails are stored in the BSM binary format, so tools must - be used to modify or convert to text. The &man.praudit.1; - command converts trail files to a simple text format; the - &man.auditreduce.1; command may be used to reduce the - audit trail file for analysis, archiving, or printing purposes. - auditreduce supports a variety of selection - parameters, including event type, event class, user, date or time of - the event, and the file path or object acted on. - - For example, the praudit utility will dump - the entire contents of a specified audit log in plain text: + Audit trails are stored in the BSM binary format, so tools + must be used to modify or convert to text. The + &man.praudit.1; command converts trail files to a simple text + format; the &man.auditreduce.1; command may be used to reduce + the audit trail file for analysis, archiving, or printing + purposes. auditreduce supports a variety + of selection parameters, including event type, event class, + user, date or time of the event, and the file path or object + acted on. + + For example, the praudit utility will + dump the entire contents of a specified audit log in plain + text: &prompt.root; praudit /var/audit/AUDITFILE - Where AUDITFILE is the audit log to - dump. - - Audit trails consist of a series of audit records made up of - tokens, which praudit prints sequentially one per - line. Each token is of a specific type, such as - header holding an audit record header, or - path holding a file path from a name - lookup. The following is an example of an + Where + AUDITFILE is + the audit log to dump. + + Audit trails consist of a series of audit records made up + of tokens, which praudit prints + sequentially one per line. Each token is of a specific type, + such as header holding an audit record + header, or path holding a file path from a + name lookup. The following is an example of an execve event: header,133,10,execve(2),0,Mon Sep 25 15:58:03 2006, + 384 msec @@ -565,112 +584,124 @@ subject,robert,root,wheel,root,wheel,384 return,success,0 trailer,133 - This audit represents a successful execve - call, in which the command finger doug has been run. The - arguments token contains both the processed command line presented - by the shell to the kernel. The path token holds the path to the - executable as looked up by the kernel. The attribute token - describes the binary, and in particular, includes the file mode - which can be used to determine if the application was setuid. - The subject token describes the subject process, and stores in - sequence the audit user ID, effective user ID and group ID, real - user ID and group ID, process ID, session ID, port ID, and login - address. Notice that the audit user ID and real user ID differ: - the user robert has switched to the - root account before running this command, but - it is audited using the original authenticated user. Finally, the - return token indicates the successful execution, and the trailer + This audit represents a successful + execve call, in which the command + finger doug has been run. The arguments + token contains both the processed command line presented by + the shell to the kernel. The path token + holds the path to the executable as looked up by the kernel. + The attribute token describes the binary, + and in particular, includes the file mode which can be used to + determine if the application was setuid. The + subject token describes the subject + process, and stores in sequence the audit user ID, effective + user ID and group ID, real user ID and group ID, process ID, + session ID, port ID, and login address. Notice that the audit + user ID and real user ID differ: the user + robert has switched to the + root account before running this command, + but it is audited using the original authenticated user. + Finally, the return token indicates the + successful execution, and the trailer concludes the record. praudit also supports an XML output format, which can be selected using the argument. - Reducing Audit Trails Since audit logs may be very large, an administrator will - likely want to select a subset of records for using, such as records - associated with a specific user: + likely want to select a subset of records for using, such as + records associated with a specific user: &prompt.root; auditreduce -u trhodes /var/audit/AUDITFILE | praudit This will select all audit records produced for the user trhodes stored in the - AUDITFILE file. + AUDITFILE + file. Delegating Audit Review Rights - Members of the audit group are given - permission to read audit trails in /var/audit; - by default, this group is empty, so only the root user may read - audit trails. Users may be added to the audit - group in order to delegate audit review rights to the user. As - the ability to track audit log contents provides significant insight - into the behavior of users and processes, it is recommended that the - delegation of audit review rights be performed with caution. + Members of the audit group are + given permission to read audit trails in + /var/audit; by default, this group is + empty, so only the root user may read + audit trails. Users may be added to the + audit group in order to delegate audit + review rights to the user. As the ability to track audit log + contents provides significant insight into the behavior of + users and processes, it is recommended that the delegation of + audit review rights be performed with caution. Live Monitoring Using Audit Pipes - Audit pipes are cloning pseudo-devices in the device file system - which allow applications to tap the live audit record stream. This - is primarily of interest to authors of intrusion detection and - system monitoring applications. However, for the administrator the - audit pipe device is a convenient way to allow live monitoring - without running into problems with audit trail file ownership or - log rotation interrupting the event stream. To track the live audit - event stream, use the following command line: + Audit pipes are cloning pseudo-devices in the device file + system which allow applications to tap the live audit record + stream. This is primarily of interest to authors of intrusion + detection and system monitoring applications. However, for + the administrator the audit pipe device is a convenient way to + allow live monitoring without running into problems with audit + trail file ownership or log rotation interrupting the event + stream. To track the live audit event stream, use the + following command line: &prompt.root; praudit /dev/auditpipe - By default, audit pipe device nodes are accessible only to the - root user. To make them accessible to the members of the - audit group, add a devfs rule - to devfs.rules: + By default, audit pipe device nodes are accessible only to + the root user. To make them accessible + to the members of the audit group, add + a devfs rule to + devfs.rules: add path 'auditpipe*' mode 0440 group audit - See &man.devfs.rules.5; for more information on configuring - the devfs file system. + See &man.devfs.rules.5; for more information on + configuring the devfs file system. - It is easy to produce audit event feedback cycles, in which - the viewing of each audit event results in the generation of more - audit events. For example, if all network I/O is audited, and - &man.praudit.1; is run from an SSH session, then a continuous stream of - audit events will be generated at a high rate, as each event - being printed will generate another event. It is advisable to run - praudit on an audit pipe device from sessions without fine-grained - I/O auditing in order to avoid this happening. + It is easy to produce audit event feedback cycles, in + which the viewing of each audit event results in the + generation of more audit events. For example, if all + network I/O is audited, and &man.praudit.1; is run from an + SSH session, then a continuous stream of audit events will + be generated at a high rate, as each event being printed + will generate another event. It is advisable to run + praudit on an audit pipe device from + sessions without fine-grained I/O auditing in order to avoid + this happening. Rotating Audit Trail Files - Audit trails are written to only by the kernel, and managed only - by the audit daemon, auditd. Administrators - should not attempt to use &man.newsyslog.conf.5; or other tools to - directly rotate audit logs. Instead, the audit - management tool may 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 + Audit trails are written to only by the kernel, and + managed only by the audit daemon, + auditd. Administrators should not + attempt to use &man.newsyslog.conf.5; or other tools to + directly rotate audit logs. Instead, the + audit management tool may 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 - If the auditd daemon is not currently - running, this command will fail and an error message will be - produced. + If the auditd daemon is not + currently running, this command will fail and an error + message will be produced. Adding the following line to @@ -682,23 +713,24 @@ trailer,133 The change will take effect once you have saved the new /etc/crontab. - Automatic rotation of the audit trail file based on file size is - possible via the option in - &man.audit.control.5;, and is described in the configuration files - section of this chapter. + Automatic rotation of the audit trail file based on file + size is possible via the option in + &man.audit.control.5;, and is described in the configuration + files section of this chapter. Compressing Audit Trails - As audit trail files can become very large, it is often desirable - to compress or otherwise archive trails once they have been closed by - the audit daemon. The audit_warn script can be - used to perform customized operations for a variety of audit-related - events, including the clean termination of audit trails when they are + As audit trail files can become very large, it is often + desirable to compress or otherwise archive trails once they + have been closed by the audit daemon. The + audit_warn script can be used to perform + customized operations for a variety of audit-related events, + including the clean termination of audit trails when they are rotated. For example, the following may be added to the - audit_warn script to compress audit trails on - close: + audit_warn script to compress audit + trails on close: # # Compress audit trail files on close. @@ -707,11 +739,12 @@ if [ "$1" = closefile ]; then gzip -9 $2 fi - Other archiving activities might include copying trail files to - a centralized server, deleting old trail files, or reducing the audit - trail to remove unneeded records. The script will be run only when - audit trail files are cleanly terminated, so will not be run on - trails left unterminated following an improper shutdown. + Other archiving activities might include copying trail + files to a centralized server, deleting old trail files, or + reducing the audit trail to remove unneeded records. The + script will be run only when audit trail files are cleanly + terminated, so will not be run on trails left unterminated + following an improper shutdown.