Re: [RFC] programmatic IDS routing

[Klaus Heinrich Kiwi <klausk@linux.vnet.ibm.com>]

On Fri, 2008-03-21 at 11:01 -0400, Steve Grubb wrote:
> > 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.
> 

I like the idea of having a stackable key field with tools and libraries
hiding the complexity of overloading the field, without deep changes to
the kernel.


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

Yes, I assume it would. Maybe specialized interfaces (besides the legacy
ones) to add, remove and iterate through the keys would be desirable,
both to libauparse and auditctl.


 -Klaus


-- 
Klaus Heinrich Kiwi
Security Development - IBM Linux Technology Center