Re: [PATCH 1/2] add SIGNAL syscall class
Steve Grubb wrote: [Wed Feb 14 2007, 03:32:02PM EST]
On Wednesday 14 February 2007 15:12:05 Amy Griffis wrote:
> Steve Grubb wrote: [Wed Feb 14 2007, 02:04:07PM EST]
>
> > On Wednesday 14 February 2007 13:24:31 Amy Griffis wrote:
> > > Add a syscall class for sending signals.
> >
> > The intent of the syscall classes had been to make an update
> > independent way of being able to specify audit rules for
> > filesystem auditing where new syscalls could be added.
>
> Yeah, I know I used it in a different way from the original
> purpose.
So, how does this work from a user perspective? Do you need to patch
auditctl?
For now, only the kernel is using the signal syscall class. You
wouldn't need to do anything in userspace.
For the other signal audit patch, you would only need to add an entry
for AUDIT_TARGET_PID in msg_typetab.h so the new record type is not
logged as UNKNOWN.
This reminds me, do we want/need to be able to filter on target pid?
> But I think this is still a valid use... When we are adding or
> removing a rule, we need a way to determine if the rule specified
> one of the syscalls for sending signals.
Could you show a sample use? (Just so I understand what its doing.)
It works like the audit_n_rules counter. When you add a rule
specifying kill, tkill or tgkill the counter goes up. When you remove
one of them, the counter goes down. If the counter is 0 when we hit
the audit_signal_info hook, we don't collect the info about the target
pid(s). That way we don't add unnecessary overhead to the call path.
The signal class exists so we can see if the rule being added/removed
contains any of those particular syscalls.
Amy