Monitoring events
I have the program adding rules to Audit now. Thank you for your help.
I also have my program monitoring the output from auditd (via the dispatch option in auditd.conf).
Ideally, I would like to only capture (or parse) events pertaining to rules I have created (since other system processes are using auditd as well). Is there's any kind of identifier that ties events to rules?
Thank you again,
Steve
Quoted 3 lines · Steve
Ideally, I would like to only capture (or parse) events pertaining to rules I have created (since other system processes are using auditd as well). Is there's any kind of identifier that ties events to rules?
Which kernel are you using? Are your events only watches or do you care about syscall auditing as well (meaning you have set some syscall audit rules) ?
-Steve
Quoted 5 lines
Quoted 3 lines
Ideally, I would like to only capture (or parse) events pertaining to rules I have created (since other system processes are using auditd as well). Is there's any kind of identifier that ties events to rules?
Which kernel are you using? Are your events only watches or do you care about syscall auditing as well (meaning you have set some syscall audit rules) ?
kernel-2.6.16-1.2212.2.8_FC6.lspp.34.i686 on Fedora Core 5
At the moment they are only watches, I may add others (syscall rules) later.
Thanks again,
Steve
Quoted 11 lines · Steve
Quoted 7 lines
Quoted 3 lines
Ideally, I would like to only capture (or parse) events pertaining to rules I have created (since other system processes are using auditd as well). Is there's any kind of identifier that ties events to rules?
Which kernel are you using? Are your events only watches or do you care about syscall auditing as well (meaning you have set some syscall audit rules) ?
kernel-2.6.16-1.2212.2.8_FC6.lspp.34.i686 on Fedora Core 5
At the moment they are only watches,
OK, the lspp series (so far) does not support the idea of a "key tag" as RHEL4 did. The key would have allowed you to recognize events you are interested in. That said, you can look for events that have an AUDIT_PATH record in them. Those would likely be yours.
Quoted 1 line
I may add others (syscall rules) later.
That would complicate the analysis somewhat. But you could still do it. You can also look over the list of message types and see which ones you do not want and reject those early in the filtering.
-Steve
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Is there's any kind of identifier that ties events to rules?
Which kernel are you using? Are your events only watches or do you care about syscall auditing as well (meaning you have set some syscall audit rules) ?
kernel-2.6.16-1.2212.2.8_FC6.lspp.34.i686 on Fedora Core 5 At the moment they are only watches,
OK, the lspp series (so far) does not support the idea of a "key tag" as RHEL4 did.
So, assuming I installed RHEL4, would this "key tag" allow all events to be tied to rules, or just the file watch events?
Quoted 2 lines · Steve
So, assuming I installed RHEL4, would this "key tag" allow all events to be tied to rules, or just the file watch events?
There has been some talk about adding the "key" to LSPP kernels. So this might be available eventually. (You are testing against a kernel that is under development and not feature complate.)
RHEL4 on the otherhand has an older audit system. I have not backported the audit dispatcher interface to the 1.0.X series. It shouldn't be difficult and might be something I do for 1.0.15.
-Steve