Re: [RFC] programmatic IDS routing
On Friday 21 March 2008 10:14:04 LC Bruzenak wrote:
On Fri, 2008-03-21 at 08:50 -0400, Steve Grubb wrote:
> On Friday 21 March 2008 06:28:42 Klaus Heinrich Kiwi wrote:
> > If it's desirable to support the general case, instead of putting
> > everything in one single 'key' field, maybe having an index just like
> > execve arguments:
> > type=USER_ACCT msg=... key[0]=ids-file-high key[1]=sox-fault-med
> > key[2]=actual_key
>
> That's a thought. In a way, I'd rather stay in one key field so that we
> have a path forward right now. It won't complicate any existing kernel
> code. Besides, doing any kernel change means waiting about 3-4 months for
> 2.6.26 to be released. If we work out a standard that is backwards
> compatible, it should work all the way back to about 2.6.16.
I prefer this approach - NOT putting more than 1 key item in the key
field. I see order issues.
What if it were the duty of the plugins or even log analysis tools to be order
independent? IOW, you can put things in any order you wish?
My first thought was to overload the key field based on the
event. For IDS events one would specify "-K" (for example) and the IDS
triple Steve proposed as appropriate in the 31-byte text area. For
another plugin need, choose a different constant - "-I" - or whatever.
I'd rather treat this like the -S option where it can be given multiple times
if we go this route. Given the code in the kernel, having multiple key fields
will require some significant patching.
If we felt like we wanted to keep this in one field, but thought 32 bytes was
to restrictive we could easily extend the size.
struct audit_context {
...
char * filterkey; /* key for rule that triggered record */
So, it is virtually unlimited in size since its allocated. The only
restriction is a check in auditfilter.c.
if (entry->rule.filterkey || f->val > AUDIT_MAX_KEY_LEN)
goto exit_free;
So, it would be a simple matter of just changing the define from 32 to 48 or
whatever.
But the important part to me is that the auditctl take care of any
ordering issues, rather than faulty people.
I could even fix auditctl to allow multiple -k fields, but glue them together
with commas if that were helpful. I could event fix auditctl to split them
back out for rule listing purposes. We could also fix auparse to be able to
do the splitting in the key field too so that this paradigm is supported and
enforced by the whole toolchain.
So, I could give the illusion of multiple key fields but without making any
drastic kernel changes. Would this be acceptable?
-Steve