Decouple tracee-rules and engine from `trace.Event`

[NDStrahilevitz]

When the protocol package for events was implemented, the headers were defined according to a common but not necessarily fitting way for tracee-rules.

The headers then had to enrich payload info into themselves so for example the ContentType header would look like: "tracee/event-execve".

This by itself wouldn't be a problem, except the engine matches events to signatures through a different system which defines three fields:

1. Name
2. Origin
3. Source

While these may be slightly domain specific to tracee-ebpf, they can easily fit other sources, however with our current headers a conversion between them and the signature selector was needed (see in engine.go line:296).

I propose matching the headers at the minimum to the SignatureSelectors, this will keep backwards compatibility and easily allow new and generic protocol.Events from other sources. There are 4 independent PRs required to reach this goal:

1. Producing protocol events from tracee-ebpf (#1531)
2. Matching the EventHeaders struct (#1645)
3. Removing the coupling in engine.go (#1646)
4. Allowing any payload from protocol in REGO signatures (#1654)

I'm opening the issue as a main thread for for opinions on the overall proposal, so it won't be divided between the PRs.

Once all of these are merged, another PR should be opened to update the Signature Writing documentation to more accurately reflect the way the protocol is used.

[NDStrahilevitz]

@rafaeldtinoco @danielpacak Tagging you as Rafael requested.

[danielpacak]

I think it make sense. Could you provide sample values for each header type? I'm not quite sure if I understood the difference between Origin and Source headers in particular.

[NDStrahilevitz]

@danielpacak So, as I explained these headers are a bit problematic because they were designed with the ebpf domain specifically in mind, but now we need to extrapolate them for generic usage. So classically as an example from tracee-ebpf it would look like so:

{
    Source: "tracee",
    Origin: "host",
    Name: "execve"
}

So we could define it as such:

1. Source is the sending system, for example k8s, CNDR, etc.
2. Origin is a subsystem of source, for example in k8s that could be the audit log. I guess this could potentially be empty.
3. Name is an arbitrary field, usually the inner event name from the system defining it, for example in the audit log context the "Kind" field would probably fit here.

Pragmatically speaking, what really decides these headers will be the conventions signatures writers use... Best we can do is define an intended usage. I would ideally change names in the Selectors to accommodate this change but that would be a breaking change.

@AsafEitani your feedback would help a lot for this.

[NDStrahilevitz]

To include REGO parity in this goal, I've uploaded #1654 and added it to the original post.

[NDStrahilevitz]

Currently, the only remaining PR for this goal is PR 1 (#1531). I have moved it back to draft since it's tests are failing. To make it work, tracee-rules needs a way to recreate the payload back into it's struct form from json. Additionally, gob is being parsed into empty events. In the case of json, there seems to be a need for a ContentType header and another type hint header. This can be implemented either at the engine level, or at the cmd level. Personally I think this is more relevant for the cmd layer and not the engine, since internally a consuming go application (for example a single binary tracee) can do just fine without such payload interpretation. It is only at the external integration level where this is a problem.

[NDStrahilevitz]

With "everything is an event", this will be redundant.