8:55 a.m.
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
9:04 a.m.
On Thursday 08 June 2006 09:55, Steve wrote:
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
9:22 a.m.
> 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
9:39 a.m.
On Thursday 08 June 2006 10:22, Steve wrote:
>> 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.
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
9:57 a.m.
>>> 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?
10:23 a.m.
On Thursday 08 June 2006 10:57, Steve wrote:
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
6772
days inactive
6772
days old
linux-audit@lists.linux-audit.osci.io
5 comments
2 participants
participants (2)
-
Steve -
Steve Grubb