RE: Suppress messages from /var/log/audit.log via audit.rules

After contacting DISA today, here is what they responded with: "The SRR script currently does not support RHEL 5, only 3 and 4. Also, the STIG for RHEL 5 is currently in draft form and a manual review would need to be performed on the assets: http://iase.disa.mil/stigs/os/unix/red_hat.html" So I took a look at the RHEL 5 draft and found this entry: Group ID (Vulid): V-814 Group Title: Audit failed file and program access attempts Rule ID: SV-27291r1_rule Severity: CAT II Rule Version (STIG-ID): GEN002720 Rule Title: The audit system must be configured to audit failed attempts to access files and programs. Vulnerability Discussion: If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. Responsibility: System Administrator IAControls: ECAR-1, ECAR-2, ECAR-3 Check Content: Check that auditd is configured to audit failed file access attempts. # cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a always,exit" | grep -i "open" If no results are returned, or the results do not contain "-S open" and "-F success=0", this is a finding. Fix Text: Edit the audit.rules file and add the following line to enable auditing of failed attempts to access files and programs: -a always,exit -F arch=<ARCH> -S open -F success=0 Restart the auditd service. The 'Fix Text' sounds like it will still spam the audit.log or am I missing something? -- Michael -----Original Message----- From: Steve Grubb [mailto:sgrubb@redhat.com] Sent: Wednesday, November 02, 2011 1:12 PM To: Worsham, Michael Cc: linux-audit(a)redhat.com Subject: Re: Suppress messages from /var/log/audit.log via audit.rules On Tuesday, November 01, 2011 11:45:51 AM Worsham, Michael wrote: This ^^^ is wrong. For example, it does not limit the syscall by the arch. So what this means is that it will look up the open syscall for the arch that auditctl is. So, lets see what that does: # ausyscall open open 2 OK, now what does the 32 bit API think of it? # ausyscall 2 i386 fork So, that rule will watch for all 32 bit forks and 64 bit opens. Is that what your security folks want? Additionally, the intent of the STIG is to catch failed opens due to permission problems. You are going to trap normal system activity when glibc goes looking around for library resolution information. This will waste space in your logs and make it hard to find actual problems. There are no docs that I know of. I could write one, but would that be authoritative? :) And the SRR is completely wrong. So, they need to have some understanding that you either want a system configured right but failing the SRR's or matching the SRR's but configured wrong. I'd hate to be in your position, but that's where you are. These rules are correct. You can contact DISA to verify. -Steve CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.