<Group id="auditing">
<title>System Accounting with <tt>auditd</tt></title>
<description>The audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, <tt>auditd</tt> has modest disk space
requirements, and should not noticeably impact system performance.
<br /><br />
Government networks often have substantial auditing
requirements and <tt>auditd</tt> can be configured to meet these
requirements.
Examining some example audit records demonstrates how the Linux audit system
satisfies common requirements.  
The following example from Fedora Documentation available at 
<tt>http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html</tt>
shows the substantial amount of information captured in a
two typical "raw" audit messages, followed by a breakdown of the most important
fields. In this example the message is SELinux-related and reports an AVC
denial (and the associated system call) that occurred when the Apache HTTP
Server attempted to access the <tt>/var/www/html/file1</tt> file (labeled with
the <tt>samba_share_t</tt> type):
<pre>type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
</pre>
<ul>
<li><tt>msg=audit(1226874073.147:96)</tt>
<ul><li>The number in parentheses is the unformatted time stamp (Epoch time)
for the event, which can be converted to standard time by using the
<tt>date</tt> command.
</li></ul>
</li>
<li><tt>{ getattr }</tt>
<ul><li>The item in braces indicates the permission that was denied. <tt>getattr</tt>
indicates the source process was trying to read the target file's status information.
This occurs before reading files. This action is denied due to the file being
accessed having the wrong label. Commonly seen permissions include <tt>getattr</tt>,
<tt>read</tt>, and <tt>write</tt>.</li></ul>
</li>
<li><tt>comm="httpd"</tt>
<ul><li>The executable that launched the process. The full path of the executable is
found in the <tt>exe=</tt> section of the system call (<tt>SYSCALL</tt>) message,
which in this case, is <tt>exe="/usr/sbin/httpd"</tt>.
</li></ul>
</li>
<li><tt>path="/var/www/html/file1"</tt>
<ul><li>The path to the object (target) the process attempted to access.
</li></ul>
</li>
<li><tt>scontext="unconfined_u:system_r:httpd_t:s0"</tt>
<ul><li>The SELinux context of the process that attempted the denied action. In
this case, it is the SELinux context of the Apache HTTP Server, which is running
in the <tt>httpd_t</tt> domain.
</li></ul>
</li>
<li><tt>tcontext="unconfined_u:object_r:samba_share_t:s0"</tt>
<ul><li>The SELinux context of the object (target) the process attempted to access.
In this case, it is the SELinux context of <tt>file1</tt>. Note: the <tt>samba_share_t</tt>
type is not accessible to processes running in the <tt>httpd_t</tt> domain.</li>
</ul>
</li>
<li> From the system call (<tt>SYSCALL</tt>) message, two items are of interest:
<ul><li><tt>success=no</tt>: indicates whether the denial (AVC) was enforced or not.
<tt>success=no</tt> indicates the system call was not successful (SELinux denied
access). <tt>success=yes</tt> indicates the system call was successful - this can
be seen for permissive domains or unconfined domains, such as <tt>initrc_t</tt>
and <tt>kernel_t</tt>.
</li>
<li><tt>exe="/usr/sbin/httpd"</tt>: the full path to the executable that launched
the process, which in this case, is <tt>exe="/usr/sbin/httpd"</tt>.
</li></ul>
</li></ul>
</description>

<Rule id="service_auditd_enabled" severity="medium">
<title>Enable auditd Service</title>
<description>The <tt>auditd</tt> service is an essential userspace component of
the Linux Auditing System, as it is responsible for writing audit records to
disk.
<service-enable-macro service="auditd" />
</description>
<ocil><service-enable-check-macro service="auditd" /></ocil>
<rationale>Ensuring the <tt>auditd</tt> service is active ensures 
audit records generated by the kernel can be written to disk, or that appropriate
actions will be taken if other obstacles exist.
</rationale>
<ident stig="GEN002660" />
<oval id="service_auditd_enabled" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="169" />
</Rule>

<Rule id="bootloader_audit_argument" severity="low">
<title>Enable Auditing for Processes Which Start Prior to the Audit Daemon</title>
<description>To ensure all processes can be audited, even
those which start prior to the audit daemon, add the argument
<tt>audit=1</tt> to the kernel line in <tt>/etc/grub.conf</tt>, in the manner below:
<pre>kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1</pre>
</description>
<ocil clause="auditing is not enabled at boot time">
Inspect the kernel boot arguments (which follow the word <tt>kernel</tt>) in
<tt>/etc/grub.conf</tt>. If they include <tt>audit=1</tt>, then
auditing is enabled at boot time.
</ocil>
<rationale>
Each process on the system carries an "auditable" flag which
indicates whether its activities can be audited. Although <tt>auditd</tt>
takes care of enabling this for all processes which launch after it
does, adding the kernel argument ensures it is set for every
process during boot.
</rationale>
<ident stig="GEN000000-LNX00720" />
<oval id="bootloader_audit_argument" />
<ref nist="ECSC-1" disa="366" />
</Rule>

<Group id="configure_auditd_data_retention">
<title>Configure <tt>auditd</tt> Data Retention</title>
<description>
The audit system writes data to <tt>/var/log/audit/audit.log</tt>. By default,
<tt>auditd</tt> rotates 5 logs by size (6MB), retaining a maximum of 30MB of
data in total, and refuses to write entries when the disk is too
full. This minimizes the risk of audit data filling its partition
and impacting other services. This also minimizes the risk of the audit
daemon temporarily disabling the system if it cannot write audit log (which
it can be configured to do).

For a busy
system or a system which is thoroughly auditing system activity, the default settings
for data retention may be
 insufficient. The log file size needed will depend heavily on what types
of events are being audited. First configure auditing to log all the events of
interest. Then monitor the log size manually for awhile to determine what file
size will allow you to keep the required data for the correct time period.
<br/><br/>
Using a dedicated partition for <tt>/var/log/audit</tt> prevents the
<tt>auditd</tt> logs from disrupting system functionality if they fill, and,
more importantly, prevents other activity in <tt>/var</tt> from filling the
partition and stopping the audit trail. (The audit logs are size-limited and
therefore unlikely to grow without bound unless configured to do so.) Some
machines may have requirements that no actions occur which cannot be audited.
If this is the case, then <tt>auditd</tt> can be configured to halt the machine
if it runs out of space. <b>Note:</b> Since older logs are rotated,
configuring <tt>auditd</tt> this way does not prevent older logs from being
rotated away before they can be viewed.

<i>If your system is configured to halt when logging cannot be performed, make
sure this can never happen under normal circumstances! Ensure that
<tt>/var/log/audit</tt> is on its own partition, and that this partition is
larger than the maximum amount of data <tt>auditd</tt> will retain
normally.</i>
</description>
<ref nist="AU-11" disa="138" />

<Value id="var_auditd_num_logs" type="number" >
<title>Number of log files for auditd to retain</title>
<description>The setting for num_logs in /etc/audit/auditd.conf</description>
<value selector="">5</value>
<value selector="5">5</value>
<value selector="4">4</value>
<value selector="3">3</value>
<value selector="2">2</value>
<value selector="1">1</value>
<value selector="0">0</value>
</Value>

<Value id="var_auditd_max_log_file" type="number" >
<title>Maximum audit log file size for auditd</title>
<description>The setting for max_log_size in /etc/audit/auditd.conf</description>
<value selector="">6</value>
<value selector="20">20</value>
<value selector="10">10</value>
<value selector="6">6</value>
<value selector="5">5</value>
<value selector="1">1</value>
</Value>

<Value id="var_auditd_max_log_file_action" type="string" >
<title>Action for auditd to take when log files reach their maximum size</title>
<description>The setting for max_log_file_action in /etc/audit/auditd.conf</description>
<value selector="">rotate</value>
<value selector="ignore">ignore</value>
<value selector="syslog">syslog</value>
<value selector="suspend">suspend</value>
<value selector="rotate">rotate</value>
<value selector="keep_logs">keep_logs</value>
</Value>

<Value id="var_auditd_space_left_action" type="string" >
<title>Action for auditd to take when disk space just starts to run low</title>
<description>The setting for space_left_action in /etc/audit/auditd.conf</description>
<value selector="">email</value>
<value selector="ignore">ignore</value>
<value selector="syslog">syslog</value>
<value selector="email">email</value>
<value selector="exec">exec</value>
<value selector="suspend">suspend</value>
<value selector="single">single</value>
<value selector="halt">halt</value>
</Value>

<Value id="var_auditd_admin_space_left_action" type="string" >
<title>Action for auditd to take when disk space just starts to run low</title>
<description>The setting for space_left_action in /etc/audit/auditd.conf</description>
<value selector="">single</value>
<value selector="ignore">ignore</value>
<value selector="syslog">syslog</value>
<value selector="email">email</value>
<value selector="exec">exec</value>
<value selector="suspend">suspend</value>
<value selector="single">single</value>
<value selector="halt">halt</value>
</Value>

<Value id="var_auditd_disk_error_action" type="string" >
<title>Action for auditd to take when disk reports errors</title>
<description>The setting for disk_error_action in /etc/audit/auditd.conf</description>
<value selector="">single</value>
<value selector="ignore">ignore</value>
<value selector="syslog">syslog</value>
<value selector="email">email</value>
<value selector="exec">exec</value>
<value selector="suspend">suspend</value>
<value selector="single">single</value>
<value selector="halt">halt</value>
</Value>

<Value id="var_auditd_disk_full_action" type="string" >
<title>Action for auditd to take when disk space is empty</title>
<description>The setting for disk_full_action in /etc/audit/auditd.conf</description>
<value selector="">single</value>
<value selector="ignore">ignore</value>
<value selector="syslog">syslog</value>
<value selector="email">email</value>
<value selector="exec">exec</value>
<value selector="suspend">suspend</value>
<value selector="single">single</value>
<value selector="halt">halt</value>
</Value>

<Value id="var_auditd_action_mail_acct" type="string" >
<title>Account for auditd to send email when actions occurs</title>
<description>The setting for action_mail_acct in /etc/audit/auditd.conf</description>
<value selector="">root</value>
<value selector="root">root</value>
<value selector="admin">admin</value>
</Value>

<Rule id="auditd_data_retention_audit_storage_failure" severity="medium">
<title>Configure auditd space_left Action on Low Disk Space</title>
<description>The <tt>auditd</tt> service can be configured to take an action
when disk space <i>starts</i> to run low. 
Edit the file <tt>/etc/audit/auditd.conf</tt>. Modify the following line,
substituting <i>ACTION</i> appropriately:
<pre>space_left_action = <i>ACTION</i></pre>
Possible values for <i>ACTION</i> are described in the <tt>auditd.conf</tt> man page.
These include:
<ul>
<li><tt>ignore</tt></li>
<li><tt>syslog</tt></li>
<li><tt>email</tt></li>
<li><tt>exec</tt></li>
<li><tt>suspend</tt></li>
<li><tt>single</tt></li>
<li><tt>halt</tt></li>
</ul>
Set this to <tt>email</tt> (instead of the default,
which is <tt>suspend</tt>) as it is more likely to get prompt attention. Acceptable values
also include <tt>suspend</tt>, <tt>single</tt>, and <tt>halt</tt>.
</description>
<ocil clause="the system is not configured to send an email to the system administrator when
disk space is starting to run low">
Inspect <tt>/etc/audit/auditd.conf</tt> and locate the following line to
determine if the system is configured to email the administrator when
disk space is starting to run low:
<tt># grep space_left_action /etc/audit/auditd.conf</tt>
<pre>space_left_action</pre>
Acceptable values are <tt>email</tt>, <tt>suspend</tt>, <tt>single</tt>, and <tt>halt</tt>.
</ocil>
<rationale>Notifying administrators of an impending disk space problem may
allow them to take corrective action prior to any disruption.</rationale>
<ident stig="GEN002730" />
<oval id="auditd_data_retention_audit_storage_failure" value="var_auditd_space_left_action"/>
<ref nist="ECSC-1" disa="143" />
</Rule>

<Rule id="auditd_data_retention_audit_processing_failure" severity="low">
<title>Configure auditd disk_error_action and disk_full_action on Storage Failures</title>
<description>The <tt>auditd</tt> service can be configured to take an action
when the disk errors or becomes full. 
Edit the file <tt>/etc/audit/auditd.conf</tt>. Add or modify the following lines,
substituting <i>ACTION</i> appropriately:
<pre>disk_error_action = <i>ACTION</i></pre>
<pre>disk_full_action = <i>ACTION</i></pre>
Set this value to <tt>single</tt> to cause the system to switch to single user
mode for corrective action. Acceptable values also include <tt>syslog</tt>, <tt>exec</tt>, and
<tt>halt</tt>. For certain systems, the need for availability
outweighs the need to log all actions, and a different setting should be
determined. Details regarding all possible values for <i>ACTION</i> are described in the
<tt>auditd.conf</tt> man page.
</description>
<ocil clause="the system is not configured to switch to single user
mode for corrective action">
Inspect <tt>/etc/audit/auditd.conf</tt> and locate the following line to
determine if the system is configured to either log the event to syslog, execute a custom action, switch to single user mode,
or halt when disk errors occur:
<pre>disk_error_action single</pre>
</ocil>
<rationale>Administrators should be made aware of an inability to write to disk.
</rationale>
<ident stig="GEN002719" />
<oval id="auditd_data_retention_audit_processing_failure" value="var_auditd_disk_error_action" />
<ref nist="ECAT-1" disa="139" />
</Rule>

<Rule id="auditd_audispd_syslog_plugin_activated" severity="low">
<title>Configure auditd to use audispd's syslog plugin</title>
<description>To configure the <tt>auditd</tt> service to use the
<tt>syslog</tt> plug-in of the <tt>audispd</tt> audit event multiplexor, set
the <tt>active</tt> line in <tt>/etc/audisp/plugins.d/syslog.conf</tt> to
<tt>yes</tt>. Restart the <tt>auditd</tt> service:
<pre># service auditd restart</pre>
</description>
<ocil clause="it is not">
To verify the audispd's syslog plugin is active, run the following command:
<pre># grep active /etc/audisp/plugins.d/syslog.conf</pre>
If the plugin is active, the output will show <tt>yes</tt>.
</ocil>
<rationale>The auditd service does not include the ability to send audit
records to a centralized server for management directly. It does, however,
include a plug-in for audit event multiplexor (audispd) to pass audit records
to the local syslog server</rationale>
<ref nist="ECTB-1" disa="136" />
<oval id="auditd_audispd_syslog_plugin_activated" />
<ident stig="GEN002870" />
</Rule>

</Group>

<Group id="auditd_configure_rules">
<title>Configure <tt>auditd</tt> Rules for Comprehensive Auditing</title>
<description>The <tt>auditd</tt> program can perform comprehensive
monitoring of system activity. This section describes recommended
configuration settings for comprehensive auditing, but a full
description of the auditing system's capabilities is beyond the
scope of this guide. The mailing list <i>linux-audit@redhat.com</i> exists
to facilitate community discussion of the auditing system.
<br /><br />
The audit subsystem supports extensive collection of events, including:
<br />
<ul>
<li>Tracing of arbitrary system calls (identified by name or number)
on entry or exit.</li>
<li>Filtering by PID, UID, call success, system call argument (with
some limitations), etc.</li>
<li>Monitoring of specific files for modifications to the file's
contents or metadata.</li>
</ul>
<br />
Auditing rules at startup are controlled by the file <tt>/etc/audit/audit.rules</tt>.
Add rules to it to meet the auditing requirements for your organization.
Each line in <tt>/etc/audit/audit.rules</tt> represents a series of arguments
that can be passed to <tt>auditctl</tt> and can be individually tested
during runtime. See documentation in <tt>/usr/share/doc/audit-<i>VERSION</i></tt> and
in the related man pages for more details.
<br /><br />
If copying any example audit rulesets from <tt>/usr/share/doc/audit-VERSION</tt>,
be sure to comment out the
lines containing <tt>arch=</tt> which are not appropriate for your system's
architecture. Then review and understand the following rules,
ensuring rules are activated as needed for the appropriate
architecture.
<br /><br />
After reviewing all the rules, reading the following sections, and
editing as needed, the new rules can be activated as follows:
<pre># service auditd restart</pre>
</description>

<Group id="audit_time_rules">
<title>Records Events that Modify Date and Time Information</title>
<description>Arbitrary changes to the system time can be used to obfuscate 
nefarious activities in log files, as well as to confuse network services that 
are highly dependent upon an accurate system time. All changes to the system 
time should be audited.</description>

<Rule id="audit_rules_time_adjtimex">
<title>Record attempts to alter time through adjtimex</title>
<description>On a 32-bit system, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre># audit_time_rules
-a exit,always -F arch=b32 -S adjtimex -k audit_time_rules</pre>
On a 64-bit system, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre># audit_time_rules
-a exit,always -F arch=b64 -S adjtimex -k audit_time_rules</pre>
The -k option allows for the specification of a key in string form that can 
be used for better reporting capability through ausearch and aureport.
Multiple system calls can be defined on the same line to save space if 
desired, but is not required. See an example of multiple combined syscalls:
<pre>-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules</pre>
</description>
<ocil clause="the system is not configured to audit time changes">
<audit-syscall-check-macro syscall="adjtimex" />
</ocil>
<rationale>Arbitrary changes to the system time can be used to obfuscate 
nefarious activities in log files, as well as to confuse network services that 
are highly dependent upon an accurate system time (such as sshd). All changes 
to the system time should be audited.</rationale>
<ident stig="GEN002760-3" />
<oval id="audit_rules_time_adjtimex" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>

<Rule id="audit_rules_time_settimeofday">
<title>Record attempts to alter time through settimeofday</title>
<description>On a 32-bit system, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre># audit_time_rules
-a exit,always -F arch=b32 -S settimeofday -k audit_time_rules</pre>
On a 64-bit system, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre># audit_time_rules
-a exit,always -F arch=b64 -S settimeofday -k audit_time_rules</pre>
The -k option allows for the specification of a key in string form that can 
be used for better reporting capability through ausearch and aureport.
Multiple system calls can be defined on the same line to save space if 
desired, but is not required. See an example of multiple combined syscalls:
<pre>-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules</pre>
</description>
<ocil clause="the system is not configured to audit time changes">
<audit-syscall-check-macro syscall="settimeofday" />
</ocil>
<rationale>Arbitrary changes to the system time can be used to obfuscate 
nefarious activities in log files, as well as to confuse network services that 
are highly dependent upon an accurate system time (such as sshd). All changes 
to the system time should be audited.</rationale>
<ident stig="GEN002760-4" />
<oval id="audit_rules_time_settimeofday" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>

<Rule id="audit_rules_time_stime">
<title>Record Attempts to Alter Time Through stime</title>
<description>On a 32-bit system, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre># audit_time_rules
-a exit,always -F arch=b32 -S stime -k audit_time_rules</pre>
On a 64-bit system, the "-S stime" is not necessary. The -k option allows for 
the specification of a key in string form that can be used for better 
reporting capability through ausearch and aureport. Multiple system calls 
can be defined on the same line to save space if desired, but is not required.
See an example of multiple combined syscalls:
<pre>-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules</pre>
</description>
<ocil clause="the system is not configured to audit time changes">
<audit-syscall-check-macro syscall="stime" />
</ocil>
<rationale>Arbitrary changes to the system time can be used to obfuscate 
nefarious activities in log files, as well as to confuse network services that 
are highly dependent upon an accurate system time (such as sshd). All changes 
to the system time should be audited.</rationale>
<ident stig="GEN002760-5" />
<oval id="audit_rules_time_stime" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>

<Rule id="audit_rules_time_clock_settime">
<title>Record Attempts to Alter Time Through clock_settime</title>
<description>On a 32-bit system, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre># audit_time_rules
-a exit,always -F arch=b32 -S clock_settime -k audit_time_rules</pre>
On a 64-bit system, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre># audit_time_rules
-a exit,always -F arch=b64 -S clock_settime -k audit_time_rules</pre>
The -k option allows for the specification of a key in string form that can 
be used for better reporting capability through ausearch and aureport.
Multiple system calls can be defined on the same line to save space if 
desired, but is not required. See an example of multiple combined syscalls:
<pre>-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules</pre>
</description>
<ocil clause="the system is not configured to audit time changes">
<audit-syscall-check-macro syscall="clock_settime" />
</ocil>
<rationale>Arbitrary changes to the system time can be used to obfuscate 
nefarious activities in log files, as well as to confuse network services that 
are highly dependent upon an accurate system time (such as sshd). All changes 
to the system time should be audited.</rationale>
<ident stig="GEN002760-6" />
<oval id="audit_rules_time_clock_settime" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>
</Group><!--End <Group id="audit_time_rules"> -->

<Rule id="audit_rules_usergroup_creation">
<title>Record Events that Create User/Group Information</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt>, in order
to capture events that create accounts:
<pre># audit_account_creation
-w /usr/sbin/groupadd -p x -k audit_account_changes
-w /usr/sbin/useradd -p x -k audit_account_changes
-w /etc/group -p a -k audit_account_changes
-w /etc/passwd -p a -k audit_account_changes
-w /etc/gshadow -p a -k audit_account_changes
-w /etc/shadow -p a -k audit_account_changes
</pre>
</description>
<ocil clause="the system is not configured to audit account creation">
To determine if the system is configured to audit account creation,
run the following command:
<pre>auditctl -l | egrep '(/usr/sbin/groupadd|/usr/sbin/useradd|/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)'</pre>
If the system is configured to watch for account changes, lines should be returned for
each file specified (and with <tt>perm=a</tt> for each).
</ocil>
<rationale>In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any
unexpected users, groups, or modifications should be investigated for
legitimacy.</rationale>
<ident stig="GEN002750" />
<oval id="audit_rules_usergroup_creation" />
<ref nist="ECAT-1" disa="18" />
</Rule>

<Rule id="audit_rules_usergroup_disabling">
<title>Record Events that Disable User Accounts</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt>, in order
to capture events that disable accounts:
<pre># audit_account_disabling
-w /usr/bin/passwd -p x -k audit_account_disabling
</pre>
</description>
<ocil clause="the system is not configured to audit accountdisabling">
To determine if the system is configured to audit account disabling,
run the following command:
<pre>auditctl -l | egrep /usr/bin/passwd</pre>
If the system is configured to watch for account changes, lines should be returned for
each file specified (and with <tt>perm=x</tt> for each).
</ocil>
<rationale>In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any
unexpected users, groups, or modifications should be investigated for
legitimacy.</rationale>
<ident stig="GEN002752" />
<oval id="audit_rules_usergroup_disabling" />
<ref nist="ECAT-1" disa="1404" />
</Rule>

<Rule id="audit_rules_usergroup_modification">
<title>Record Events that Modify User/Group Information</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt>, in order
to capture events that modify account changes:
<pre># audit_account_changes
-w /usr/sbin/groupmod -p x -k audit_account_changes
-w /usr/sbin/usermod -p x -k audit_account_changes
-w /etc/group -p w -k audit_account_changes
-w /etc/passwd -p w -k audit_account_changes
-w /etc/gshadow -p w -k audit_account_changes
-w /etc/shadow -p w -k audit_account_changes
</pre>
</description>
<ocil clause="the system is not configured to audit account changes">
To determine if the system is configured to audit account changes,
run the following command:
<pre>auditctl -l | egrep '(/usr/sbin/groupmod|/usr/sbin/usermod|/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)'</pre>
If the system is configured to watch for account changes, lines should be returned for
each file specified (and with <tt>perm=w</tt> for each).
</ocil>
<rationale>In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any
unexpected users, groups, or modifications should be investigated for
legitimacy.</rationale>
<ident stig="GEN002751" />
<oval id="audit_rules_usergroup_modification" />
<ref nist="ECAT-1" disa="1403" />
</Rule>

<Rule id="audit_rules_usergroup_termination">
<title>Record Events that Terminate Users/Groups</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt>, in order
to capture events that terminate accounts:
<pre># audit_account_termination
-w /usr/sbin/groupdel -p x -k audit_account_termination
-w /usr/sbin/userdel -p x -k audit_account_termination
</pre>
</description>
<ocil clause="the system is not configured to audit account termination">
To determine if the system is configured to audit account termination,
run the following command:
<pre>auditctl -l | egrep '(/usr/sbin/groupdel|/usr/sbin/userdel)'</pre>
If the system is configured to watch for account termination, lines should be returned for
each file specified (and with <tt>perm=x</tt> for each).
</ocil>
<rationale>In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any
unexpected users, groups, or modifications should be investigated for
legitimacy.</rationale>
<ident stig="GEN002753" />
<oval id="audit_rules_usergroup_termination" />
<ref nist="ECAT-1" disa="1405" />
</Rule>

<Rule id="audit_rules_sethostname">
<title>Record Events that Modify the System's Host Name</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt>, setting
ARCH to either b32 or b64 as appropriate for your system:
<pre># audit_network_sethostname
-a exit,always -F arch=ARCH -S sethostname -k audit_network_modifications</pre>
</description>
<ocil clause="the system is not configured to audit changes of the network configuration">
To determine if the system is configured to audit changes to its network configuration,
run the following command:
<pre>auditctl -l | grep sethostname</pre>
If the system is configured to watch for host name changes, a line should be returned for
sethostname.
</ocil>
<rationale>The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited.</rationale>
<ident stig="GEN002760-7" />
<oval id="audit_rules_sethostname" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>

<Rule id="audit_rules_setdomainname">
<title>Record Events that Modify the System's Domain Name</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt>, setting
ARCH to either b32 or b64 as appropriate for your system:
<pre># audit_network_setdomainname
-a exit,always -F arch=ARCH -S setdomainname -k audit_network_modifications</pre>
</description>
<ocil clause="the system is not configured to audit changes of the network configuration">
To determine if the system is configured to audit changes to its network configuration,
run the following command:
<pre>auditctl -l | grep setdomainname</pre>
If the system is configured to watch for domain name changes, a line should be returned for
setdomainname.
</ocil>
<rationale>The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited.</rationale>
<ident stig="GEN002760-8" />
<oval id="audit_rules_setdomainname" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>

<Rule id="audit_rules_sched_setparam">
<title>Record Events that Modify the System's Scheduler Parameters</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt>, setting
ARCH to either b32 or b64 as appropriate for your system:
<pre># audit_network_sethostname
-a exit,always -F arch=ARCH -S sched_setparam -k scheduler</pre>
</description>
<ocil clause="the system is not configured to audit changes of the scheduler parameters">
To determine if the system is configured to audit changes to its scheduler parameters,
run the following command:
<pre>auditctl -l | grep sched_setparam</pre>
If the system is configured to watch for host name changes, a line should be returned for
sched_setparam.
</ocil>
<rationale>The scheduler parameters should not be modified by anything other
than administrator action. Any change to network parameters should be
audited.</rationale>
<ident stig="GEN002760-9" />
<oval id="audit_rules_sched_setparam" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>

<Rule id="audit_rules_sched_setscheduler">
<title>Record Events that Modify the System's Scheduler Priorities</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt>, setting
ARCH to either b32 or b64 as appropriate for your system:
<pre># audit_network_sethostname
-a exit,always -F arch=ARCH -S sched_setscheduler -k scheduler</pre>
</description>
<ocil clause="the system is not configured to audit changes of the scheduler priorities">
To determine if the system is configured to audit changes to its scheduler priorities,
run the following command:
<pre>auditctl -l | grep sched_setscheduler</pre>
If the system is configured to watch for host name changes, a line should be returned for
sched_setscheduler.
</ocil>
<rationale>The scheduler priorities should not be modified by anything other
than administrator action. Any change to network parameters should be
audited.</rationale>
<ident stig="GEN002760-10" />
<oval id="audit_rules_sched_setscheduler" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>

<Group id="audit_dac_actions">
<title>Record Events that Modify the System's Discretionary Access Controls</title>
<description>At a minimum the audit system should collect file permission 
changes for all users and root.  Note that the "-F arch=b32" lines should be 
present even on a 64 bit system.  These commands identify system calls for 
auditing.  Even if the system is 64 bit it can still execute 32 bit system 
calls.  Additionally, these rules can be configured in a number of ways while 
still achieving the desired effect.  An example of this is that the "-S" calls 
could be split up and placed on separate lines, however, this is less efficient.
Add the following to <tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid&gt;=500 -F auid!=4294967295 -k perm_mod
    -a exit,always -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid&gt;=500 -F auid!=4294967295 -k perm_mod
    -a exit,always -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If your system is 64 bit then these lines should be duplicated and the 
arch=b32 replaced with arch=b64 as follows:
<pre>-a exit,always -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid&gt;=500 -F auid!=4294967295 -k perm_mod
    -a exit,always -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid&gt;=500 -F auid!=4294967295 -k perm_mod
    -a exit,always -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<rationale>The changing of file permissions could indicate that a user is 
attempting to gain access to information that would otherwise be disallowed. 
Auditing DAC modifications can facilitate the identification of patterns of 
abuse among both authorized and unauthorized users.</rationale>

<Rule id="audit_rules_dac_modification_chmod">
<title>Record Events that Modify the System's Discretionary Access Controls - chmod</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S chmod -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S chmod  -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<ocil clause="the system is not configured to audit permission changes">
<audit-syscall-check-macro syscall="chmod" />
</ocil>
<warning category="general">Note that these rules can be configured in a 
number of ways while still achieving the desired effect.  Here the system calls 
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820" />
<oval id="audit_rules_dac_modification_chmod" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_chown">
<title>Record Events that Modify the System's Discretionary Access Controls - chown</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S chown -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S chown -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="chown" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a 
number of ways while still achieving the desired effect.  Here the system calls 
have been placed independent of other system calls.  Grouping these system 
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-4" />
<oval id="audit_rules_dac_modification_chown" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_fchmod">
<title>Record Events that Modify the System's Discretionary Access Controls - fchmod</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S fchmod -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S fchmod -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="fchmod" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-2" />
<oval id="audit_rules_dac_modification_fchmod" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_fchmodat">
<title>Record Events that Modify the System's Discretionary Access Controls - fchmodat</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S fchmodat -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S fchmodat -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="fchmodat" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-3" />
<oval id="audit_rules_dac_modification_fchmodat" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_fchown">
<title>Record Events that Modify the System's Discretionary Access Controls - fchown</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S fchown -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S fchown -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="fchown" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-5" />
<oval id="audit_rules_dac_modification_fchown" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_fchownat">
<title>Record Events that Modify the System's Discretionary Access Controls - fchownat</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S fchownat -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S fchownat -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="fchownat" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-6" />
<oval id="audit_rules_dac_modification_fchownat" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_fremovexattr">
<title>Record Events that Modify the System's Discretionary Access Controls - fremovexattr</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S fremovexattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S fremovexattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="fremovexattr" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-13" />
<oval id="audit_rules_dac_modification_fremovexattr" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_fsetxattr">
<title>Record Events that Modify the System's Discretionary Access Controls - fsetxattr</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S fsetxattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S fsetxattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="fsetxattr" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-10" />
<oval id="audit_rules_dac_modification_fsetxattr" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_lchown">
<title>Record Events that Modify the System's Discretionary Access Controls - lchown</title>
<description>At a minimum the audit system should collect file 
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S lchown -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S lchown -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="lchown" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-7" />
<oval id="audit_rules_dac_modification_lchown" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_lremovexattr">
<title>Record Events that Modify the System's Discretionary Access Controls - lremovexattr</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S lremovexattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S lremovexattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="lremovexattr" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-12" />
<oval id="audit_rules_dac_modification_lremovexattr" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_lsetxattr">
<title>Record Events that Modify the System's Discretionary Access Controls - lsetxattr</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S lsetxattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S lsetxattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="lsetxattr" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-9" />
<oval id="audit_rules_dac_modification_lsetxattr" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="" />
</Rule>

<Rule id="audit_rules_dac_modification_removexattr">
<title>Record Events that Modify the System's Discretionary Access Controls - removexattr</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S removexattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S removexattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="removexattr" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-11" />
<oval id="audit_rules_dac_modification_removexattr" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_dac_modification_setxattr">
<title>Record Events that Modify the System's Discretionary Access Controls - setxattr</title>
<description>At a minimum the audit system should collect file
permission changes for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>:
<pre>-a exit,always -F arch=b32 -S setxattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
If the system is 64 bit then also add the following:
<pre>-a exit,always -F arch=b64 -S setxattr -F auid&gt;=500 -F auid!=4294967295 -k perm_mod</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="setxattr" />
</ocil>
<rationale>The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users.</rationale>
<warning category="general">Note that these rules can be configured in a
number of ways while still achieving the desired effect.  Here the system calls
have been placed independent of other system calls.  Grouping these system
calls with others as identifying earlier in this guide is more efficient.
</warning>
<ident stig="GEN002820-8" />
<oval id="audit_rules_dac_modification_setxattr" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

</Group> <!-- <Group id="audit_dac_actions"> -->

<Rule id="audit_rules_login_events">
<title>Record Attempts to Alter Logon and Logout Events</title>
<description> 
The audit system already collects login info for all users and root. To watch for attempted manual edits of
files involved in storing logon events, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre>-w /var/log/faillog -p wa -k logins 
-w /var/log/lastlog -p wa -k logins</pre>
</description> 
<rationale>Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion.</rationale>
<ident stig="GEN002800" />
<oval id="audit_rules_login_events" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_audit_rules">
<title>Record Attempts to Alter Audit Rules</title>
<description> 
To watch for attempted manual edits of audit rules, add the following to <tt>/etc/audit/audit.rules</tt>:
<pre>-w /etc/audit/audit.rules -p w -k audit_rules</pre>
</description> 
<rationale>Manual editing of audit rules may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion.</rationale>
<ident stig="GEN002760-2" />
<oval id="audit_rules_audit_rules" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="347" />
</Rule>

<Rule id="audit_rules_unsuccessful_file_creat">
<title>Ensure <tt>auditd</tt> Collects Unauthorized Access Attempts to Files (unsuccessful) Via creat</title>
<description>At a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to <tt>/etc/audit/audit.rules</tt>, setting ARCH to either b32 or b64 as
appropriate for your system with either:
<pre>-a exit,always -F arch=ARCH -S creat -F success=0 -k access</pre>
or
<pre>-a exit,always -F arch=ARCH -S creat -F exit=-EPERM -k access
-a exit,always -F arch=ARCH -S creat -F exit=-EACCES -k access</pre>
</description>
<ocil clause="either command lacks output">
To verify that the audit system collects unauthorized file accesses, run the following commands:
<pre># grep creat /etc/audit/audit.rules</pre>
</ocil>
<rationale>Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise.</rationale>
<ident stig="GEN002720" />
<oval id="audit_rules_unsuccessful_file_creat" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_unsuccessful_file_ftruncate">
<title>Ensure <tt>auditd</tt> Collects Unauthorized Access Attempts to Files (unsuccessful) Via ftruncate</title>
<description>At a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to <tt>/etc/audit/audit.rules</tt>, setting ARCH to either b32 or b64 as
appropriate for your system with either:
<pre>-a exit,always -F arch=ARCH -S ftruncate -F success=0 -k access</pre>
or
<pre>-a exit,always -F arch=ARCH -S ftruncate -F exit=-EPERM -k access
-a exit,always -F arch=ARCH -S ftruncate -F exit=-EACCES -k access</pre>
</description>
<ocil clause="either command lacks output">
To verify that the audit system collects unauthorized file accesses, run the following commands:
<pre># grep ftruncate /etc/audit/audit.rules</pre>
</ocil>
<rationale>Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise.</rationale>
<ident stig="GEN002720-5" />
<oval id="audit_rules_unsuccessful_file_ftruncate" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_unsuccessful_file_open">
<title>Ensure <tt>auditd</tt> Collects Unauthorized Access Attempts to Files (unsuccessful) Via open</title>
<description>At a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to <tt>/etc/audit/audit.rules</tt>, setting ARCH to either b32 or b64 as
appropriate for your system with either:
<pre>-a exit,always -F arch=ARCH -S open -F success=0 -k access</pre>
or
<pre>-a exit,always -F arch=ARCH -S open -F exit=-EPERM -k access
-a exit,always -F arch=ARCH -S open -F exit=-EACCES -k access</pre>
</description>
<ocil clause="either command lacks output">
To verify that the audit system collects unauthorized file accesses, run the following commands:
<pre># grep open /etc/audit/audit.rules</pre>
</ocil>
<rationale>Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise.</rationale>
<ident stig="GEN002720-2" />
<oval id="audit_rules_unsuccessful_file_open" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_unsuccessful_file_openat">
<title>Ensure <tt>auditd</tt> Collects Unauthorized Access Attempts to Files (unsuccessful) Via openat</title>
<description>At a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to <tt>/etc/audit/audit.rules</tt>, setting ARCH to either b32 or b64 as
appropriate for your system with either:
<pre>-a exit,always -F arch=ARCH -S openat -F success=0 -k access</pre>
or
<pre>-a exit,always -F arch=ARCH -S openat -F exit=-EPERM -k access
-a exit,always -F arch=ARCH -S openat -F exit=-EACCES -k access</pre>
</description>
<ocil clause="either command lacks output">
To verify that the audit system collects unauthorized file accesses, run the following commands:
<pre># grep openat /etc/audit/audit.rules</pre>
</ocil>
<rationale>Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise.</rationale>
<ident stig="GEN002720-3" />
<oval id="audit_rules_unsuccessful_file_openat" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_unsuccessful_file_truncate">
<title>Ensure <tt>auditd</tt> Collects Unauthorized Access Attempts to Files (unsuccessful) Via truncate</title>
<description>At a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to <tt>/etc/audit/audit.rules</tt>, setting ARCH to either b32 or b64 as
appropriate for your system with either:
<pre>-a exit,always -F arch=ARCH -S truncate -F success=0 -k access</pre>
or
<pre>-a exit,always -F arch=ARCH -S truncate -F exit=-EPERM -k access
-a exit,always -F arch=ARCH -S truncate -F exit=-EACCES -k access</pre>
</description>
<ocil clause="either command lacks output">
To verify that the audit system collects unauthorized file accesses, run the following commands:
<pre># grep truncate /etc/audit/audit.rules</pre>
</ocil>
<rationale>Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise.</rationale>
<ident stig="GEN002720-4" />
<oval id="audit_rules_unsuccessful_file_truncate" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_file_deletion_events">
<title>Ensure <tt>auditd</tt> Collects File Deletion Events by User</title>
<description>At a minimum the audit system should collect file
deletion events for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>, setting ARCH to either b32 or b64 as
appropriate for your system:
<pre>-a exit,always -F arch=ARCH -S unlink -S unlinkat -S rename -S renameat -F auid&gt;=500 -F auid!=4294967295 -k delete</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="unlink" />
<audit-syscall-check-macro syscall="rename" />
</ocil>
<rationale>Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence.</rationale>
<ident stig="GEN002740" />
<oval id="audit_rules_file_deletion_events" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_file_deletion_events_rmdir">
<title>Ensure <tt>auditd</tt> Collects Directory Deletion Events by User</title>
<description>At a minimum the audit system should collect directory
deletion events for all users and root. Add the following to
<tt>/etc/audit/audit.rules</tt>, setting ARCH to either b32 or b64 as
appropriate for your system:
<pre>-a exit,always -F arch=ARCH -S rmdir -k delete</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="rmdir" />
</ocil>
<rationale>Auditing directory deletions will create an audit trail for directories that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log directories to conceal their presence.</rationale>
<ident stig="GEN002740-2" />
<oval id="audit_rules_file_deletion_events_rmdir" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>

<Rule id="audit_rules_kernel_module_loading">
<title>Ensure <tt>auditd</tt> Collects Information on Kernel Module Loading and Unloading</title>
<description>Add the following to <tt>/etc/audit/audit.rules</tt> in order
to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:
<pre>-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a exit,always -F arch=<i>ARCH</i> -S init_module -S delete_module -k modules</pre>
</description>
<ocil>
<audit-syscall-check-macro syscall="init_module" />
<audit-syscall-check-macro syscall="delete_module" />
</ocil>
<rationale>The addition/removal of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel.</rationale>
<ident stig="GEN002825-2" />
<oval id="audit_rules_kernel_module_loading" />
<ref nist="ECAR-1,ECAR-2,ECAR-3" disa="126" />
</Rule>
</Group>

</Group>
