Re: Selective Audit; filtering on message type; integration of operators
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