- Some SGML fixes (use of the right attribute for directories);
- Add missing application, command, username, etc. tags; - Add some manual page entities; - For the audit_class content I changed some tags and used the description fields used in /etc/security/audit_class to make this part easier to read and closer to what the user will find on his machine; - Contraction removal; - Add missing words and fix typos and punctuation.
This commit is contained in:
Marc Fonvieille
parent
c674e516f8
commit
adc8e4d736
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=30428
1 changed files with 41 additions and 41 deletions
|
|
@ -216,7 +216,7 @@ requirements. -->
|
|||
<title>Audit Configuration</title>
|
||||
|
||||
<para>All configuration files for security audit are found in
|
||||
<filename role="directory">/etc/security</filename>. The following
|
||||
<filename class="directory">/etc/security</filename>. The following
|
||||
files must be present before the audit daemon is started:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
|
@ -246,7 +246,7 @@ requirements. -->
|
|||
|
||||
<listitem>
|
||||
<para><filename>audit_warn</filename> - A customizable shell script
|
||||
used by auditd to generate warning messages in exceptional
|
||||
used by <application>auditd</application> 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.</para>
|
||||
</listitem>
|
||||
|
|
@ -275,29 +275,29 @@ requirements. -->
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><option>all</option> - <literal>all</literal> - Match all
|
||||
<para><literal>all</literal> - <emphasis>all</emphasis> - Match all
|
||||
event classes.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>ad</option> - <literal>administrative</literal>
|
||||
<para><literal>ad</literal> - <emphasis>administrative</emphasis>
|
||||
- Administrative actions performed on the system as a
|
||||
whole.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>ap</option> - <literal>application</literal> -
|
||||
<para><literal>ap</literal> - <emphasis>application</emphasis> -
|
||||
Application defined action.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>cl</option> - <literal>file_close</literal> -
|
||||
<para><literal>cl</literal> - <emphasis>file close</emphasis> -
|
||||
Audit calls to the <function>close</function> system
|
||||
call.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>ex</option> - <literal>exec</literal> - Audit
|
||||
<para><literal>ex</literal> - <emphasis>exec</emphasis> - Audit
|
||||
program execution. Auditing of command line arguments and
|
||||
environmental variables is controlled via &man.audit.control.5;
|
||||
using the <literal>argv</literal> and <literal>envv</literal>
|
||||
|
|
@ -305,80 +305,80 @@ requirements. -->
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>fa</option> - <literal>file_attr_acc</literal>
|
||||
<para><literal>fa</literal> - <emphasis>file attribute access</emphasis>
|
||||
- Audit the access of object attributes such as
|
||||
&man.stat.1;, &man.pathconf.2; and similar events.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>fc</option> - <literal>file_creation</literal>
|
||||
<para><literal>fc</literal> - <emphasis>file create</emphasis>
|
||||
- Audit events where a file is created as a result.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>fd</option> - <literal>file_deletion</literal>
|
||||
<para><literal>fd</literal> - <emphasis>file delete</emphasis>
|
||||
- Audit events where file deletion occurs.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>fm</option> - <literal>file_attr_mod</literal>
|
||||
<para><literal>fm</literal> - <emphasis>file attribute modify</emphasis>
|
||||
- Audit events where file attribute modification occurs,
|
||||
such as &man.chown.8;, &man.chflags.1;, &man.flock.2;,
|
||||
etc.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>fr</option> - <literal>file_read</literal>
|
||||
<para><literal>fr</literal> - <emphasis>file read</emphasis>
|
||||
- Audit events in which data is read, files are opened for
|
||||
reading, etc.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>fw</option> - <literal>file_write</literal> -
|
||||
<para><literal>fw</literal> - <emphasis>file write</emphasis> -
|
||||
Audit events in which data is written, files are written
|
||||
or modified, etc.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>io</option> - <literal>ioctl</literal> - Audit
|
||||
<para><literal>io</literal> - <emphasis>ioctl</emphasis> - Audit
|
||||
use of the &man.ioctl.2; system call.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>ip</option> - <literal>ipc</literal> - Audit
|
||||
<para><literal>ip</literal> - <emphasis>ipc</emphasis> - Audit
|
||||
various forms of Inter-Process Communication, including POSIX
|
||||
pipes and System V <acronym>IPC</acronym> operations.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>lo</option> - <literal>login_logout</literal> -
|
||||
<para><literal>lo</literal> - <emphasis>login_logout</emphasis> -
|
||||
Audit &man.login.1; and &man.logout.1; events occurring
|
||||
on the system.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>na</option> - <literal>non_attrib</literal> -
|
||||
<para><literal>na</literal> - <emphasis>non attributable</emphasis> -
|
||||
Audit non-attributable events.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>no</option> - <literal>no_class</literal> -
|
||||
<para><literal>no</literal> - <emphasis>invalid class</emphasis> -
|
||||
Match no audit events.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>nt</option> - <literal>network</literal> -
|
||||
<para><literal>nt</literal> - <emphasis>network</emphasis> -
|
||||
Audit events related to network actions, such as
|
||||
&man.connect.2; and &man.accept.2;.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>ot</option> - <literal>other</literal> -
|
||||
<para><literal>ot</literal> - <emphasis>other</emphasis> -
|
||||
Audit miscellaneous events.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>pc</option> - <literal>process</literal> -
|
||||
<para><literal>pc</literal> - <emphasis>process</emphasis> -
|
||||
Audit process operations, such as &man.exec.3; and
|
||||
&man.exit.3;.</para>
|
||||
</listitem>
|
||||
|
|
@ -416,12 +416,12 @@ requirements. -->
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>^+</literal> Don't audit successful events in this
|
||||
<para><literal>^+</literal> Do not audit successful events in this
|
||||
class.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>^-</literal> Don't audit failed events in this
|
||||
<para><literal>^-</literal> Do not audit failed events in this
|
||||
class.</para>
|
||||
</listitem>
|
||||
|
||||
|
|
@ -487,7 +487,7 @@ filesz:0</programlisting>
|
|||
the system should continue running despite an auditing failure
|
||||
(this flag is highly recommended). Another commonly used flag is
|
||||
<literal>argv</literal>, which causes command line arguments to
|
||||
the &man.execve.2; system call to audited as part of command
|
||||
the &man.execve.2; system call to be audited as part of command
|
||||
execution.</para>
|
||||
|
||||
<para>The <option>filesz</option> option specifies the maximum size
|
||||
|
|
@ -513,12 +513,12 @@ filesz:0</programlisting>
|
|||
|
||||
<para>The following example <filename>audit_user</filename> 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.
|
||||
the <username>root</username> user, and audits file creation and successful command
|
||||
execution for the <username>www</username> user.
|
||||
If used with the example <filename>audit_control</filename> file
|
||||
above, the <literal>lo</literal> entry for <literal>root</literal>
|
||||
above, the <literal>lo</literal> entry for <username>root</username>
|
||||
is redundant, and login/logout events will also be audited for the
|
||||
<literal>www</literal> user.</para>
|
||||
<username>www</username> user.</para>
|
||||
|
||||
<programlisting>root:lo,+ex:no
|
||||
www:fc,+ex:no</programlisting>
|
||||
|
|
@ -534,9 +534,9 @@ www:fc,+ex:no</programlisting>
|
|||
<title>Viewing Audit Trails</title>
|
||||
|
||||
<para>Audit trails are stored in the BSM binary format, so tools must
|
||||
be used to modify or convert to text. The <command>praudit</command>
|
||||
command convert trail files to a simple text format; the
|
||||
<command>auditreduce</command> command may be used to reduce the
|
||||
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.
|
||||
<command>auditreduce</command> supports a variety of selection
|
||||
parameters, including event type, event class, user, date or time of
|
||||
|
|
@ -547,7 +547,7 @@ www:fc,+ex:no</programlisting>
|
|||
|
||||
<screen>&prompt.root; <userinput>praudit /var/audit/AUDITFILE</userinput></screen>
|
||||
|
||||
<para>Where <replaceable>AUDITFILE</replaceable> is the audit log to
|
||||
<para>Where <filename><replaceable>AUDITFILE</replaceable></filename> is the audit log to
|
||||
dump.</para>
|
||||
|
||||
<para>Audit trails consist of a series of audit records made up of
|
||||
|
|
@ -569,18 +569,18 @@ trailer,133</programlisting>
|
|||
<para>This audit represents a successful <literal>execve</literal>
|
||||
call, in which the command <literal>finger doug</literal> 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
|
||||
by the shell to the kernel. The <literal>path</literal> token holds the path to the
|
||||
executable as looked up by the kernel. The <literal>attribute</literal> 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
|
||||
The <literal>subject</literal> 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 <literal>robert</literal> has switched to the
|
||||
<literal>root</literal> account before running this command, but
|
||||
the user <username>robert</username> has switched to the
|
||||
<username>root</username> 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
|
||||
<literal>return</literal> token indicates the successful execution, and the <literal>trailer</literal>
|
||||
concludes the record.</para>
|
||||
|
||||
</sect2>
|
||||
|
|
@ -622,7 +622,7 @@ trailer,133</programlisting>
|
|||
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</para>
|
||||
event stream, use the following command line:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>praudit /dev/auditpipe</userinput></screen>
|
||||
|
||||
|
|
@ -640,10 +640,10 @@ trailer,133</programlisting>
|
|||
<para>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
|
||||
praudit is run from an SSH session, then a continuous stream of
|
||||
&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
|
||||
<command>praudit</command> on an audit pipe device from sessions without fine-grained
|
||||
I/O auditing in order to avoid this happening.</para>
|
||||
</warning>
|
||||
</sect2>
|
||||
|
|
|
|||
Loading…
Reference in a new issue