public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Brian LaMere <brianl@clinicomp.com>
Cc: linux-audit@redhat.com
Subject: Re: no logging of successful events?
Date: Mon, 18 Aug 2008 16:52:24 -0400	[thread overview]
Message-ID: <200808181652.24871.sgrubb@redhat.com> (raw)
In-Reply-To: <1219092199.6522.48.camel@orpheus.clinicomp.com>

On Monday 18 August 2008 16:43:19 Brian LaMere wrote:
> -w /etc/auditd.conf
> -w /etc/audit.rules
> -a exit,always -S open -F success=0

Note that openat is being used more and more for secure apps that need to 
ensure that a directory is not switched out during an operation.


> -a exit,always -S rmdir -S unlink -S chmod -S fchmod -S chown -S fchown
> -S lchown -F success!=0
> -a exit,always -S settimeofday -S setrlimit -S setdomainname -S
> sched_setparam -S sched_setscheduler -S acct -S reboot -S swapon
> -------------------------------------------------
>
> Was grouping by failed, successful, and both.  Did this due to reading
> that every audit rule is tested for every syscall, which...yeah, makes
> me want to group things.

Yes. You can do that. In the stig.rules file I add a key so that you can see 
exactly what part of the stig is being met whenever you encounter an event. 
And its also because sometimes it takes more than one rule to meet a 
requirement fully.


> That being said, stig.rules is extensive; any warning on what the
> performance impact will be?

No idea. If you have to meet the letter of the law...not a whole lot you can 
do but throw hardware at it. Depending on your situation, you may be able to 
do it with less rules. I wanted to illustrate as complete coverage as 
possible with a real life security target people have to meet. I don't have 
any feedback from disa as to whether or not they like it. :)


> Also, when looking for the newer builds on your site
> http://people.redhat.com/sgrubb/audit/ - I noticed "1.7 -> 1.8 Remote
> logging and finishing up IDS/IPS plugin."  That would be wonderously
> fabulous, and I look forward to it.   Any thoughts on whether it will be
> pulled into RHEL5, or whether I'd have to wait until RHEL6?

Remote logging should be in RHEL5.3/Fedora 10. IDS work is in Fedora 9.

-Steve

  reply	other threads:[~2008-08-18 20:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-18 19:09 no logging of successful events? Brian LaMere
2008-08-18 19:18 ` Steve Grubb
2008-08-18 19:25   ` Eric Paris
2008-08-18 19:49     ` Brian LaMere
2008-08-18 19:51       ` Eric Paris
2008-08-18 19:39   ` Brian LaMere
2008-08-18 20:07     ` Steve Grubb
2008-08-18 20:43       ` Brian LaMere
2008-08-18 20:52         ` Steve Grubb [this message]
2008-08-18 22:13           ` Brian LaMere

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=200808181652.24871.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=brianl@clinicomp.com \
    --cc=linux-audit@redhat.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