Rule order is not preserved between rules that have an event type and those that don't

[mstemm]

It's possible to have rules that don't explicitly name an event type, or have conditions that make it difficult to map to a specific set of event types. These rules run for all event types. This compares to most rules that name an event type, which are stored in a list of rules indexed by event type.

There isn't anything that preserves rule order between the two collections, so it's possible that a rule that appears later in a rules file and runs for all event types will be considered before a rule that appears earlier in a rules file runs for a specific event type.

Here's an example:

- rule: open_below_tmp
  desc: An open event below /tmp
  condition: evt.type=open and fd.directory=/tmp
  output: some other output
  priority: INFO

- rule: related_to_tmp
  desc: Any action related to /tmp/
  condition: fd.directory=/tmp
  output: some output
  priority: INFO

In this case, related_to_tmp will run first even though it appears second in the file.

The fix is to keep track of overall rule order and preserve it when comparing rules in the two collections.

[mattpag]

What's the goal of this fix? Is there a reason why falco must match the rules in the order in which they appear in the file?
Asking because if there's not and the goal is performance optimization, why can't we try to automatically reorder the rules to first match the rules that names event types and only after the "catchall" ones, instead of relying on the order in the rules file?

PS - I cannot find the test rules file catchall_order.yaml, maybe you forgot to add it to the commit?

[mstemm]

I think generally preserving rule order is useful as you can ensure that earlier rules will match an event first.

I ran into this bug when I had a rules file that first checked filesystem paths related to an open, and later checked system calls. I wanted the filesystem paths rule to take precedence over the system calls rule, so I put it earlier in the file. However, because the system calls rule wasn't specifically tied to any particular system call (its condition was something like and not evt.type in (...), it was put in the catchall category and always was evaluated first.

When I tried to open a file below a disallowed path, the system call rule triggered instead of the filesystem rule.

Thanks about catchall_order.yaml, I added it to the PR.

[mattpag]

Oh ok now I got it, it's a rule precedence issue.
I agree with your solution then. Thanks for the explanation!