[RFC] programmatic IDS routing

[Steve Grubb]

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