user audits
Steve,
Would there be any issue with adding a couple new trusted_application event types? Would any kernel mods be needed to support this?
The reason I ask is because I'd like to process some event types differently on the back end (the aggregator) and if I could easily identify those types it would make life easier.
Some trusted_application events are for recording "bad" security issues, some for "good", etc. and I'd like to easily differentiate those.
I can put something inside the event text but if possible would prefer a couple different types, like trusted_app1, trusted_app2, etc.
Thx,
LCB
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Quoted 2 lines · LC Bruzenak
Would there be any issue with adding a couple new
trusted_applicationevent types? Would any kernel mods be needed to support this?
Are these events originating in user space or the kernel? I might be convinced to set aside the block of IDs from 2600 - 2699 for local use if a suitable framework were written. This would mean that there is some config file that holds the local mapping of event IDs to text and ausearch/report/parse will need to be patched to understand local definitions.
Would you be interested in this approach?
-Steve
Quoted 9 lines · Steve Grubb
Quoted 2 lines · LC Bruzenak
Would there be any issue with adding a couple new
trusted_applicationevent types? Would any kernel mods be needed to support this?Are these events originating in user space or the kernel? I might be convinced to set aside the block of IDs from 2600 - 2699 for local use if a suitable framework were written. This would mean that there is some config file that holds the local mapping of event IDs to text and ausearch/report/parse will need to be patched to understand local definitions.
Great!
Quoted 1 line
From user space only. Analogous to signal handling of SIGUSR1, SIGUSR2
where the framework supports the user-implemented pieces.
I was thinking ausearch/auparse would treat all the TRUSTED_APPs the same...since they (currently) fails to parse these correctly anyway IMHO. :)
Everything else could treat the additional user types exactly as they do the TRUSTED_APP event now. When I dig through the events on the back end I would be able to act differently on the ones I know I've put in place on the originating end.
Quoted 2 lines
Would you be interested in this approach?
Absolutely!
I will be starting work on some stuff which could utilize this after the holidays. If it gets into RHEL6 I would be thrilled!
Thx,
LCB
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Quoted 12 lines · LC Bruzenak
Quoted 10 lines · Steve Grubb
Quoted 2 lines · LC Bruzenak
Would there be any issue with adding a couple new
trusted_applicationevent types? Would any kernel mods be needed to support this?Are these events originating in user space or the kernel? I might be convinced to set aside the block of IDs from 2600 - 2699 for local use if a suitable framework were written. This would mean that there is some config file that holds the local mapping of event IDs to text and ausearch/report/parse will need to be patched to understand local definitions.
Quoted 8 lines
Great!
From user space only. Analogous to signal handling of SIGUSR1, SIGUSR2 where the framework supports the user-implemented pieces.
I was thinking ausearch/auparse would treat all the
TRUSTED_APPsthe same...since they (currently) fails to parse these correctly anyway IMHO. :)
It translates the event record type and allows searches based on the event record's name. Aureport totals event types. Auparse also translates event type. libaudit may or may not have validation issues - I have not looked at the code for sending events lately.
Quoted 4 lines
Everything else could treat the additional user types exactly as they do the
TRUSTED_APPevent now. When I dig through the events on the back end I would be able to act differently on the ones I know I've put in place on the originating end.
Parsing the event beyond the type, timestamp, and serial number is problematic. But the first couple items are standard and the kernel enforces conformance. That is as far as I was thinking to go with it.
Quoted 5 lines
Quoted 1 line
Would you be interested in this approach?
Absolutely!
I will be starting work on some stuff which could utilize this after the holidays. If it gets into RHEL6 I would be thrilled!
Look at what I said above. I would suggest a file at /etc/audit/local.defs for a mapping of local definitions. I would expect to be able to use:
ausearch -m local-type
aureport --summary --events -i
-Steve