From mboxrd@z Thu Jan 1 00:00:00 1970 From: hsultan@thefroid.net Subject: Re: Catching process termination on SIGKILL Date: Mon, 26 Jan 2015 17:56:59 -0800 Message-ID: <45a5a4d7425943aa52df4117448cf2ce@thefroid.net> References: <5601880178188ab58cf241b359ebf97d@thefroid.net> <4299392.Ypj558huPe@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx13.extmail.prod.ext.phx2.redhat.com [10.5.110.18]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0R1v5Hj014530 for ; Mon, 26 Jan 2015 20:57:05 -0500 Received: from homiemail-a78.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0R1v1Qm032708 for ; Mon, 26 Jan 2015 20:57:02 -0500 Received: from homiemail-a78.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a78.g.dreamhost.com (Postfix) with ESMTP id 64721200061E7 for ; Mon, 26 Jan 2015 17:57:01 -0800 (PST) Received: from webmail.thefroid.net (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: hsultan@thefroid.net) by homiemail-a78.g.dreamhost.com (Postfix) with ESMTPA id 5CC68200061E2 for ; Mon, 26 Jan 2015 17:57:01 -0800 (PST) In-Reply-To: <4299392.Ypj558huPe@x2> 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 2015-01-26 16:41, Steve Grubb wrote: > 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. 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. 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 ? Thanks, Hassan