From: LC Bruzenak <lenny@magitekltd.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: need rules help
Date: Sat, 08 Aug 2009 12:59:53 -0500 [thread overview]
Message-ID: <1249754393.3048.173.camel@homeserver> (raw)
In-Reply-To: <200908081134.51817.sgrubb@redhat.com>
On Sat, 2009-08-08 at 11:34 -0400, Steve Grubb wrote:
> On Thursday 06 August 2009 05:17:36 pm LC Bruzenak wrote:
> > So it appears that the "never" rule is not firing...right?
>
> No, its actually something else
>
>
> > I'm not sure if the rule applies to only the info in the "type=syscall"
> > line. Really I want to compare against the specific scontext/tcontext
> > pair in the "type=AVC" line.
>
> The issue is that SE Linux AVCs travel a different path. When an AVC denial
> occurs and there is not a dontaudit associated with it, it sends the event
> straight to the netlink queue. To suppress an AVC, you would need to make a
> change to SE Linux policy. The SE Linux folks wanted to make sure there was no
> way to suppress an AVC without explicitly stating so in policy.
>
> -Steve
Bummer. But thanks for the explanation; that makes sense...sort of.
Does the "exclude" rule then work for msgtype=AVC (as the manpage says)?
If so, seems like a broad stroke is allowed whereas detailed exclusion
isn't.
I realize this may be out of your hands, but it might have implications
for event aggregation as this feature matures. At the event generation
level, this might be desired behavior whereas the collecting machine
might not want this detail.
At some point, would it be possible to instantiate filters at either the
sending side (audisp-remote) or the receiving side (auditd) to narrow
the event collection?
For SElinux then, the "never" flag seems to me almost useless. The vast
majority of events I see (YMMV) are either those I explicitly specify in
the rules, or else AVCs; e.g.:
[root@audit ~]# aureport -ts today -e -i --summary
Event Summary Report
======================
total type
======================
23851 AVC
121 SYSCALL
60 CRED_DISP
60 USER_END
59 CRED_ACQ
59 USER_ACCT
59 LOGIN
59 USER_START
18 TRUSTED_APP
2 USER_ROLE_CHANGE
1 DAEMON_RESUME
1 CRED_REFR
1 USER_LOGIN
1 USER_AUTH
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny@magitekltd.com
next prev parent reply other threads:[~2009-08-08 17:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-06 2:45 need rules help LC Bruzenak
2009-08-06 15:10 ` need rules help - solved LC Bruzenak
2009-08-06 21:17 ` need rules help LC Bruzenak
2009-08-08 2:23 ` LC Bruzenak
2009-08-08 15:34 ` Steve Grubb
2009-08-08 17:59 ` LC Bruzenak [this message]
2009-08-09 13:37 ` Steve Grubb
2009-08-09 15:10 ` LC Bruzenak
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=1249754393.3048.173.camel@homeserver \
--to=lenny@magitekltd.com \
--cc=linux-audit@redhat.com \
--cc=sgrubb@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