[RFC] programmatic IDS routing
Klaus Heinrich Kiwi
klausk at linux.vnet.ibm.com
Mon Mar 24 13:13:22 UTC 2008
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
More information about the Linux-audit
mailing list