1

While running FreeBSD a long time ago, there was a default feature which logged when a process received one of the fatal signals, like SIGSEGV, SIGBUS, SIGKILL, etc. and was terminated because of that.

Is there something similar for Linux?

Ivan Voras
  • 176
  • 1
  • 7

2 Answers2

3

The auditd suggestion is solid, but note that it only works if the kill(2) syscall is invoked. SIGBUS, for example, doesn't invoke that syscall; it's an interrupt handler inside of the kernel that then propagates the signal directly to the relevant process with no syscall interface required.

To accomplish your goal perfectly, you're probably looking for BPF. This is an excellent resource to start playing with. At a guess—no warranties expressed or implied—you might want to instrument here.

BMDan
  • 7,129
  • 2
  • 22
  • 34
  • 2
    Using the code found here: https://en.wikipedia.org/wiki/Bus_error I was able to create a SIGBUS fault, and it was indeed caught by auditd: "type=ANOM_ABEND msg=audit(1559452833.341:184): auid=1000 uid=0 gid=0 ses=8 pid=1424 comm="sigbus" exe="/[... snip ...]/sigbus" sig=7", but no, it was not logged as a SYSCALL signal, and thus not matched by the rule posted in my answer. – Morgan Jun 02 '19 at 07:35
  • 1
    Very nice research, @Morgan, thank you! I suppose it makes sense; `auditd` has kernel interfaces anyway, so it adds up (once I'm challenged on it!) that it could have the right hooks to instrument non-`kill`-propagated signals, but it had never occurred to me that it *would*. After a bit of research of my own, it looks like OP could try `OBJ_PID` (records all signals sent; too chatty?), or `RESP_KILL_PROC`. The latter presumably wouldn't/couldn't have signal information for anything other than `ANOM_ABEND` events at most, since one can't strictly correlate nonfatal signals with shutdown. – BMDan Jun 09 '19 at 17:25
  • 1
    @bmdan as far as I can tell, `RESP_KILL_PROC` is never actually sent. The `RESP` records are intended to be sent by an intrusion detection system in usermode to document the response taken to deal with a threat. i.e. `RESP_KILL_PROC` doesn't mean that a process was killed naturally but rather that the intrusion detection system actively killed it and is now documenting the fact. I reviewed all uses of `RESP_KILL_PROC` and `AUDIT_ RESP_KILL_PROC` on github search and couldn't find a single case where `RESP_KILL_PROC` is actually sent. So I think it's unused - at least that's my interpretation. – Natan Yellin Oct 06 '20 at 08:26
2

If you're looking for signals sent to a specific process, strace may be all you need:

# strace -e trace=signal -p <pid>

Lots of info available in the strace manpage...

There is also the "auditd" package.

This post over at redhat.com addresses you're specific question: https://access.redhat.com/solutions/36278

Summarizing from the redhat post:

1) Install auditd
2) Edit /etc/audit/audit.rules to include the line:

-a entry,always -F arch=b64 -S kill -k teste_kill

3) restart the auditd service (or stop/start)

# service auditd restart

4) tail the auditd log file

# tail -f /var/log/audit/audit.log

Morgan
  • 371
  • 1
  • 3