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:[email protected]] > Sent: Wednesday, November 02, 2011 1:12 PM > To: Worsham, Michael > Cc: [email protected] > 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. -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
