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

Steve Grubb
2011-11-03T17:33:19Z

On Thursday, November 03, 2011 01:06:52 PM Worsham, Michael wrote:
> 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"

Yes, its in draft which means there are no STIGs for RHEL5 or 6. However, I have met
with them and there is an agreement that the stig file is correct until new
requirements are levied.

> 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.

Which is slightly better, but still wrong.

> The 'Fix Text' sounds like it will still spam the audit.log or am I missing
> something?

It would, which is a good reason its still a draft. This also doesn't cover the openat
syscall which glibc uses. The NSA publishes a SNAC guide for RHEL5. You can find the
latest at this location:

http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf

If you look in section 2.6.2.4.8, you will see the correct audit rule listed as CCE
14917-9. This is what the RHEL5 STIG should map to in its XCCDF.

-Steve

> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, November 02, 2011 1:12 PM
> To: Worsham, Michael
> Cc: linux-audit@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:
> > SRR still shows this as a failure, using stig.rules contents for
> > audit.rules:
> >
> > GEN002720: UNIX STIG: 3.16 - The audit system is not configured to audit
> > failed attempts to access files and programs. AUDITING is NOT correctly
> > CONFIGURED on va33-time.
> > Ensure that -a exit,always -S open -F success=0 is in
> > /etc/audit/audit.rules
>
> 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.
>
> > PDI Number: GEN002720
> > Finding Category: CAT II
> > Reference: UNIX STIG: 3.16
> > Description: The audit system is not configured to audit failed attempts
> > to access files and programs. Status: Open
> >
> >
> > Is there any documentation that says that the stig.rules file is
> > compliant for GEN002720?
>
> There are no docs that I know of. I could write one, but would that be
> authoritative?
>
> :)
> :
> > The project security folks will only be looking at the SRR
> > output, which says it's not.
>
> 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.
>
> > We are using the rules as found here:
> > https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules
>
> These rules are correct. You can contact DISA to verify.