Higher level events

[itaysk]

This is not a new idea, we have discussed it in the past but it's wasn't yet articulated. The idea is to create higher level events that abstracts the kernel events and makes them more usable for the user. For example: instead of using execve, security_bprm_check or sched_process_exec, the user use an event called “exec” that contains all the relevant information.

Motivation:

1. The implementation details behind the abstract event might evolve over time (switching from execve to security_bprm_check to sched_process_exec would be seamless).
2. A higher level event can introduce additional data like hash while remaining semantically correct (and therefore intuitive for the user)
3. User-space processing is straight-forward (for example, capture exec can hook to the exec event)
4. It might be possible to use different techniques to implement a single high level event.
5. Grouping of similar events. Users are sometimes able to express intention but are not aware/don’t care about how it’s implemented, for example dup1/2/3. Related to Adding category for each event #720

[itaysk]

related: #1115

[itaysk]

Another important aspect that I forgot, is flags that modify the event schema (e.g detect-syscall,exec-env,exec-info). Signatures can express interest in events, but not flags (nor they should). Higher level events can help us solve this by creating variants of events which convey the intent more accurately, e.g exec, exec-hash, exec-hash-env.
This also relates to @yanivagman 's proposal to allow the user to explicitly select what args to collect. Either way, the solution should consider how signatures will consume the data, not just how users configure it.

[itaysk]

related: #1170