[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 hp com> wrote:
> On Wed, Nov 02, 2005 at 04:27:34AM -0500, Dustin Kirkland wrote:
> > On 11/1/05, Dustin Kirkland <dustin kirkland 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

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]