[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC] programmatic IDS routing

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 Heinrich Kiwi
Security Development - IBM Linux Technology Center

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]