[PATCH] (0/2) new audit filter allows excluding messages by type

[Dustin Kirkland]

I see now that Steve has responded as well, But I was in the middle of drafting a response, so some of this may have already been covered.

On 11/3/05, Amy Griffis <amy.griffis at hp.com> wrote:
> On Wed, Nov 02, 2005 at 04:27:34AM -0500, Dustin Kirkland wrote:
> > On 11/1/05, Dustin Kirkland <dustin.kirkland at us.ibm.com> wrote:
> > > The interface to exclude messages of IPC type looks like:
> > > auditctl -a exclude,always -F "msgtype=IPC"
> >
> > Just now thinking about this...  This might be a bit verbose for what
> > is truly needed.  That is, the "always" part, and even the "msgtype"
> > should probably be implicit.
> 
> Yes, definitely.  I am in favor of a separate option.

Agreed.  That's easy enough to do, even if the underlying implementation
is actually the rules functionality.

> > In which case, we might offer a shortcut interface for excluding
> > audit messages by type to use a new "-E" parameter:
> >
> > auditctl -E "type=IPC" -E "type>1400"
> 
> Using the hard numbers is not a good idea.  We want to abstract that
> from the user.  It would be better to define an alias that comprises
> an event group.  For example:
> 
>     auditctl -E user

I agree with aliasing.  I think we should make it as easy as possible on
the user.  But there's no reason to cripple the user's ability to
specify the numbers as well.  There are several other places in the
auditctl code that accepts numbers or strings (user/uid, group/gid), so
I think we should continue to provide this flexibility in these cases as
well.
 
> > If you want to support excluding a specific message type, then you
> could accept the syntax:
> 
>     auditctl -E AUDIT_AVC
> 
> or perhaps more preferably:
> 
>     auditctl -E avc
> 
> where avc translates to message type AUDIT_AVC.

I say that we just drop the AUDIT_ from any message types and use that.
The AUDIT_ is understood.

> Providing the capability to exclude single messages or larger groups
> of messages should suffice.  I don't think it benefits the user to
> support the >,< operators in this case.

I agree that it 'should' suffice to most users, but the audit_operators
code is already there for our use and it really provides infinite
flexibility and range specification beyond what few use cases you and I
can foresee today.  It doesn't cost us anything extra to give >,<,>=,<=
so I think we should give the admin as much flexibility as possible.

> Additionally, I don't think it makes sense to support the exclusion of
> any single message type defined in the header file.  Some message
> types, like AUDIT_PATH, don't stand on their own, but belong to a
> greater subset.  If we can identify message types that stand on their
> own, then we can support excluding those on their own, as well as in
> part of an event group.

Again, it doesn't cost us anything to offer this as a possibility.  In
fact, it would take more code to forbid users from excluding a single
message type.


:-Dustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20051103/00e8bcc1/attachment.sig>