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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
