Filter approaches (was: Re: [PATCH] enable /proc/$$/loginuid)
On Mon, 2005-01-17 at 12:51 -0600, Timothy R. Chavez wrote:
Also,
We may or someone else may want to provide advanced filtering
(anything more advanced then what is already provided) of audit
records before they reach an audit log. Better to do this filtering
in userspace via a daemon then in the kernel. We should keep the
in-kernel audit subsystem as small and efficient as possible.
Anything that can be delegated to userspace should be delegated to
userspace.
I think this is a pretty good idea - there are consequences though..
The number of events that need to be sent across to userspace for
processing may be significantly higher than what is finally delivered to
the log file, which could be considered by some to be a waste of
resources. Eg: If a user is only interested in files
in /data/secretstuff, then all the 'normal' file opens conducted by the
operating system (which may comprise 99% of events delivered to the
daemon), will be dropped by userspace pretty-much instantly - so much of
the effort the kernel goes through to write the info to userspace, might
be perceived to be wasted.
In snare, we generally see single-figure-percentage CPU resource
increases in normal operations using this exact approach - however, for
some operations (file-open auditing turned on, with many many small-file
opens occuring), this can increase to 30% or more. On the other hand,
much of that CPU work will have to be done somewhere - the kernel-
userspace comms are likely to occupy only a small percentage of that
work.
So, we have four alternative approaches here I think:
1) Dumb kernel, smart daemon. (this is the way Snare currently operates)
- Audit daemon turns on particular events (eg: file opens)
- Kernel sends ANY events that are file-open related to kernel.
- Daemon does all the filtering work
2) Semi-intelligent kernel, dumb daemon (Current implementation / LAUS).
- Audit daemon turns on particular events, plus some additional event
filters (eg: userid, success/failure)
- Kernel sends matching events to daemon, which writes the data out
appropriately.
3) Intelligent kernel / dumb daemon
- Audit daemon turns on particular events, plus some additional event
filters: userid, success/failure, wildcard-matched filenames?
- Kernel works out fully-qualified file paths, and matches against
wildcard match.
4) Semi-intelligent kernel, smart daemon
- Audit daemon turns on particular events, plus some additional event
filters (eg: userid, success/failure)
- Kernel works out fully-qualified file paths, but does not match
against wildcard filters.
- Kernel sends matching events to daemon, which writes the data out
appropriately.
- Daemon does MOST of the filtering work - particularly filenames.
Sounds like option 4 might be roughly what you're proposing?
L.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/