Re: Catching process termination on SIGKILL

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Hassan wrote:
> On 2015-01-26 16:41, Steve Grubb wrote:
> > We collect anything that leads to a core dump because that is an 
> > anomally. No
> > one should have segfaulting code on a production system. However, the 
> > kernel
> > does not allow a SIGKILL to be delivered to processes the user has no 
> > rights
> > to send it to, so its not really an abnormal event. I could see 
> > someone maybe
> > wanting to monitor this, but its never been a priority to solve this 
> > problem.

Well, the OOM killer can deliver SIGKILL to processes the user has no rights
to send it to. ;-)

> I see. Auditing SIGKILL reception would allow for easy tracking of 
> process activity by following clone/fork/vfork/exit/exit group/abnormal 
> termination and then SIGKILL. Without it, it becomes a kludge requiring 
> to track kill/tkill/tgkill and trying to find which process will accept 
> the SIGKILL sent and which won't, which then requires keeping track of 
> process privileges and such.

Do you have to implement it using audit subsystem? If you want to track
process activity for temporary (or debug) purpose, SystemTap would do it.

---------- program start ----------
# stap -e '
probe kernel.function("do_exit") {
  if ($code & 0x7F)
    printf("%s %s(%u) exiting with signal %u\n",
           ctime(gettimeofday_s()), execname(), pid(), $code & 0x7F);
}'
---------- program end ----------

---------- output example start ----------
Sat May 3 06:00:39 2014 a.out(2101) exiting with signal 11
Sat May 3 06:00:48 2014 sleep(2102) exiting with signal 2
Sat May 3 06:01:17 2014 sleep(2105) exiting with signal 9
Sat May 3 06:01:21 2014 a.out(2131) exiting with signal 11
---------- output example end ----------

> 
> I'll try to figure out what a patch to audit the KILL reception would 
> look like, intent would be to provide the sender's PID + the target PID 
> in the audit msg. Should that be a new AUDIT msg type or do you see it 
> fit within an existing msg type ?

SystemTap would do it, if you can accept SystemTap.