Selective Audit; filtering on message type; integration of operators

[Dustin Kirkland]

On 10/6/05, Amy Griffis <amy.griffis at hp.com> wrote:
> On Thu, Sep 29, 2005 at 03:00:31PM -0500, Dustin Kirkland wrote:
> > I'm suggesting the ability to add new rules via auditctl to a new list,
> > perhaps called "exclude".  The proposed interface would look like:
> >
> > Exclude messages of a specific type:
> >       auditctl -a exclude,always -F "type=AUDIT_IPC"
> 
> I don't think the exclude list should be a filter list, for a couple
> of reasons.  The filter rules are designed to represent particular
> system events.  Audit message types don't have anything to do with
> what's going on in the system.  Additionally, you are only making use
> of one of the three possible actions (always).  The others don't make
> any sense in this context.  This is a good indication that this
> feature is not what the filter lists were designed for.

So your vote would be for something more like:

	auditctl -E "type=AUDIT_IPC"
	auditctl -E "uid>500"

I think I like that ^

Steve: What do you think about this?  I know you and I talked about
doing it this way earlier and you pointed me toward the filter list
input methodology...


> > KERNEL_SPACE
> >
> > The kernel piece of this is pretty straightforward, actually...  Near
> > the very top of audit_log_start(), we basically do something like:
> >   if (unlikely(audit_exclude_type(type)))
> >     return NULL;
> >
> > Where audit_exclude_type() traverses our list of ranges looking for
> > a match, returning 1 if is to be excluded, 0 if no matches found.
> > Remember, this is ordered such that we can end the traversal as soon
> > as possible.
> 
> The cleanest implementation would be a bitmask of all audit message
> types.  Checking the bitmask would require a single operation to
> determine whether or not to generate the log message.  You could also
> define additional constants to represent groups of messages, which
> would remove the need to support ranges.

Agreed that it would be simplest.  But it's neither scalable nor
flexible.  32-bits or 64-bits just won't support very many different
types of messages.  There's been some discussion on this list about
increasing the message blocks from the current 100 to something much
larger to allow particular vendors to create message types of their own.

:-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/20051006/6b819fb6/attachment.sig>