From: Steve Grubb <sgrubb@redhat.com>
To: "Worsham, Michael" <mworsham@scires.com>
Cc: "linux-audit@redhat.com" <linux-audit@redhat.com>
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules
Date: Wed, 2 Nov 2011 13:11:56 -0400 [thread overview]
Message-ID: <201111021311.56333.sgrubb@redhat.com> (raw)
In-Reply-To: <F52537DA8635C941B5CB6455ACA1EA5820ADDCE01A@chsex02-srv>
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.
-Steve
next prev parent reply other threads:[~2011-11-02 17:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 14:31 Suppress messages from /var/log/audit.log via audit.rules Worsham, Michael
2011-09-29 14:54 ` Vipin Rathor
2011-09-29 15:12 ` Worsham, Michael
2011-09-29 15:41 ` Steve Grubb
2011-09-29 15:51 ` Worsham, Michael
2011-09-30 1:51 ` Steve Grubb
2011-10-04 2:36 ` Worsham, Michael
2011-10-04 13:18 ` Steve Grubb
2011-11-01 15:45 ` Worsham, Michael
2011-11-02 17:11 ` Steve Grubb [this message]
2011-11-03 17:06 ` Worsham, Michael
2011-11-03 17:33 ` Steve Grubb
2011-11-08 14:38 ` Worsham, Michael
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201111021311.56333.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=mworsham@scires.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox