From: LC Bruzenak <lenny@magitekltd.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: need rules help
Date: Sun, 09 Aug 2009 10:10:53 -0500 [thread overview]
Message-ID: <1249830653.3048.194.camel@homeserver> (raw)
In-Reply-To: <200908090937.31217.sgrubb@redhat.com>
On Sun, 2009-08-09 at 09:37 -0400, Steve Grubb wrote:
> On Saturday 08 August 2009 01:59:53 pm LC Bruzenak wrote:
> > > 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.
> >
> > 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.
>
> Did some more digging on this and found I missed a line of code.
>
> http://lxr.linux.no/linux+v2.6.30.4/kernel/audit.c#L1167
>
> When audit_log_start is called to create an AVC, it calls audit_filter_type()
> which is the exclude filter.
>
> http://lxr.linux.no/linux+v2.6.30.4/kernel/auditfilter.c#L1743
>
> At line 1757, you can see that it only cares about the event type field. It
> does not check any other fields that you might have in the rule such as
> subjects. Originally there was some discussion about not allowing the audit
> system to suppress AVC's since correcting policy is really the best way to go.
It may be the best way to go in theory, but in practice, IIUC, the
policy rules are not granular enough to specify what the audit rules
potentially can.
Also I still think my aggregation-filter ideas have merit eventually and
policy won't help this.
>
> So, I think yes you can suppress AVC's. But its all AVC's and not any
> particular one. It seems like it would be trivial to add some more checking to
> the type filter to better tune what is being thrown away.
This would be a huge help to me; I think others would find it useful
also. I don't see it as a lesser security stance; there is precedence in
legacy systems in the field where this behavior is SOP (although not as
elegant as the linux audit rules).
Ideally the complete scontext/tcontext fields (incl. level) in AVC lines
are would be what should be filterable.
Thanks for the time/effort to look into this Steve; I really appreciate
it!
LCB.
--
LC (Lenny) Bruzenak
lenny@magitekltd.com
prev parent reply other threads:[~2009-08-09 15:10 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
2009-08-09 13:37 ` Steve Grubb
2009-08-09 15:10 ` LC Bruzenak [this message]
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=1249830653.3048.194.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