Osquery uses basic SQL commands to leverage a relational data-model to describe a device.

osquery

<@UKBRAB1UL> that event will never be picked up unless osquery is updated to parse it

You can start by updating the following files:
osquery/tables/events/linux/process_events.cpp
osquery/events/linux/process_events.h
osquery/events/linux/auditdnetlink.cpp

It is mostly adding the `__NR_kill`  in the std::unorderd_sets and then enable handling of the event

```osquery/tables/events/linux/process_events.cpp
  - Add __NR_kill to kSyscallNameMap
  - Update the `else` case in `if (is_exec_syscall) {`

osquery/events/linux/process_events.h
  - Add kKillProcessEventsSyscalls with __NR_kill

osquery/events/linux/auditdnetlink.cpp
  Inside `if (FLAGS_audit_allow_process_events) {`

  Add
    for (int syscall : kKillProcessEventsSyscalls) {
      monitored_syscall_list_.insert(syscall);
    }

Additional updates
 - Could be worth adding a `audit_allow_kill_process_events` flag
 - There are other kill syscalls that may be interesting to support```

Then you may want to test it with `--verbose` and see what happens

Awesome, thanks for the reply. I was guessing there wasn't an implementation for parsing the KILL syscall. But, I have one question, why weren;t there any events when there was 3 rules, execve, execveat and kill. From what I am guessing, if there aren't processors for kill, it should just have ignored those events and the `--audit_debug=true` should anyways print those raw audit logs right..

And I will certainly try to contribute back :smile:

<@UKBRAB1UL> Did you parsed this syscall?
<@U04ALQP1T38> fyi