Selective Audit; filtering on message type; integration of operators

[Steve Grubb]

On Thursday 06 October 2005 09:18, Amy Griffis wrote:
> The filter rules are designed to represent particular system events.

Not really. Syscall entry could become any kind of event. It could trigger a 
watch, syscall, or nothing at all.

> 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).

Right. Because we would always want to do this.

> 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.

Actually, this is the easiest thing to do. We need to make code to implement > 
< and range operators, so why not re-use that code? If we don't we will have 
duplicate code doing filtering. Besides, we need to be able to insert, list, 
and delete the filtering rules. So once again, this fits the pattern of a 
filter list. We would have to duplicate all that code if we don't consider it 
a filter.

> > 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.  

Maybe so, but not extensible.

> Checking the bitmask would require a single operation to 
> determine whether or not to generate the log message.  

It would take more than one op. We'd need to convert from message number to 
bit mask and then look it up. The message numbers range from 1000 to 2400 for 
now. We would obviously have to do some fixing up to use a bit mask.

> You could also define additional constants to represent groups of messages,
> which would remove the need to support ranges.

We want ranges anyways. What if you wanted to audit uid > 500. How would you 
do it?

-Steve