On Tue, 2005-04-05 at 17:54 -0400, Steve Grubb wrote:
I've worked around the problem in the following way - it's a
bit of a
hack but I think easier than completely restructuring the code:
- dynamically add an audit rule from /etc/init.d/audit to monitor
signals sent to the auditd pid
- change auditd to keep processing kernel messages for two seconds
after getting the shutdown signal so that it has a chance to save
the "signal" event record.
This is what it looks like (i386, syscall 37 is "kill"):
type=KERNEL msg=audit(1111114589.580:4100282): syscall=37 exit=0
a0=469d a1=f a2=469d a3=469d items=0 pid=18094 loginuid=500 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
Chris and I looked at this and discussed the possibility of adding a
check in security_task_kill() -- or we could at least add a new
audit_task_kill() next to it in signal.c::check_kill_permission().
That would be an inline function which checks for t->pid == audit_pid
and either marks the syscall auditable or just logs an appropriate
report.
--
dwmw2