Selective Audit; filtering on message type; integration of operators

[Amy Griffis]

On Thu, Sep 29, 2005 at 03:00:31PM -0500, Dustin Kirkland wrote:
> The TSF shall be able to include or exclude auditable events from the
> set of audited events based on the following attributes:
> 
> (a) Object identity, user identity, subject identity, host identity, and
> ***event type***
> 
> I'm currently working on a design for a patch to the audit userspace and
> kernel subsystem that provides this functionality.  Additionally, I'm
> conducting this work in conjunction with trying to provide extended
> support for operators (such as > and <), as these would be useful in
> this context.

<snip>

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

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

Amy