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