From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Catching process termination on SIGKILL Date: Mon, 26 Jan 2015 19:41:18 -0500 Message-ID: <4299392.Ypj558huPe@x2> References: <5601880178188ab58cf241b359ebf97d@thefroid.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5601880178188ab58cf241b359ebf97d@thefroid.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Monday, January 26, 2015 03:14:20 PM hsultan@thefroid.net wrote: > So I'm curious, auditd catches abnormal process termination (SIGSEGV, > ...) with a 1701 audit message, can catch 'clean' termination by > monitoring syscall (exit, exitgroup), however I don't see anything to > catch process termination by a SIGKILL. > if I audit the kill() system call then I see the call to send the > signal, but I would have expected the system to offer auditing of an > actual SIGKILL *reception* (because you can pass -1 as target PID to > sigkill, which kills all processes reachable by the caller and will make > auditing by syscall very hard to do), am I missing something ? I don't think so. > Is there a parameter to set somehow that I'm missing ? No. This would probably need some kind of kernel patch to enable. Its never really come up that anyone would want to monitor for this. Typically the monitoring is on the sending side rather than the receiving side. 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. -Steve