Selective Audit; filtering on message type; integration of operators

[Amy Griffis]

Dustin & Steve,

I'm sorry if my first explanation was unclear.  Hopefully this email
will be more understandable.

On Thu, Oct 06, 2005 at 02:21:02PM -0500, Dustin Kirkland wrote:
> > 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.

Space constraints shouldn't be an issue.  On second look, I think
providing the capability to suppress groups of messages is sufficient.
Most of the message types within a given block don't provide a
complete picture without their counterparts.  When would an admin want
AUDIT_SYSCALL records logged without AUDIT_PATH records?  If any
message types within a block make sense on their own, they could have
their own bit in the bitmask.

Based on the current header file plus Steve's recent posting of future
message blocks, I see a total of under 20.  Several of these are
reserved for future use.  Even with future development, we are not
approaching 64 bits.

On Thu, Oct 06, 2005 at 03:42:21PM -0400, Steve Grubb wrote:
> 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.

I don't understand what you are trying to say.  The events described
by filter rules would occur whether or not audit was running.  The
"event" you are referring to -- the generation of an audit record --
is something that is specific to the audit system.  It would not occur
if there were no audit system.  So we are talking about two different
things, and the concepts should not be mixed.  What you are suggesting
is like adding filter rules to set the audit backlog and such.

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

Adding a range concept to the filter rules improves performance by
requiring fewer rules to express an event.  There is nothing requiring
a specific type of operator.  These are all possible implementations.

> so why not re-use that code? 

It doesn't make sense to re-use code when the solution does not fit
the problem.

> If we don't we will have duplicate code doing filtering. 

Not if message suppression is implemented with a bitmask.

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

There could be a single setting determining which message types will
be output to the logs.  At a minimum, this requires a set and a clear
operation.

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

Each call to either audit_log or audit_log_start occurs from a point
at which we could determine the message group.  So you could add a
message group parameter to audit_log and audit_log_start.

I don't think a lookup table would be any easier to maintain than two
well-commented blocks of #defines.

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

This should be a different code path.  See:
https://www.redhat.com/archives/linux-audit/2005-October/msg00017.html

Amy