8:38 a.m.
Thought you might like to know that I contacted DISA on this error and got a response:
Michael,
Thank you for bringing this issue to our attention it will be corrected in the final
version of the STIG:
Action Description: GEN000460 :: INCORRECT AUDIT.RULES FINDING IN SRR SCRIPT FOR LINUX.
ISSUE FOUND IN DRAFT RHEL 5 AS WELL, SEE ATTACHED EMAIL
AR Number: CSD-AR003085626
Assigned Group: CH-STIG-UNIX
Assigned Priority: 4
Assigned Technician: ADAMS, GARY
First Name: MICHAEL
Last Name: WORSHAM
Last Update User: ADAMSG
Organization: ND REGIONAL SUPPLY OFFICE COM/PRIVATE INDUSTRY
Element Id: FS-STIG : STIG Service 1: COMPUTING Service 2: FSO Service 3: UNIX Status or
Resolution Summary: 11/7 - DEFER TO CORRECT IN RHEL5 STIG.
Status: DEFERRED
Zulu Date Time Out: 11/3/2011 18:05:53
Zulu Last Update Time: 11/7/2011 17:44:43
Gary Adams CISSP, Security+
DISA FSO
HP Enterprise Services
COMM: 703-742-2929
-- Michael
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Thursday, November 03, 2011 1:33 PM
To: Worsham, Michael
Cc: linux-audit(a)redhat.com
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules
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(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:
> 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.
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.