exe_flags=%evt.arg.flags usage among our rules

[Andreagit97]

Motivation

In many rules, we have this output field exe_flags=%evt.arg.flags. The name exe_flags suggests we are trying to extract some flags relative to the executable, but if we take a closer look we are getting the flags of the open family syscalls.
Let's take the Read sensitive file untrusted rule as an example. The events used in this rule are (open,openat,openat2), so evt.arg.flags returns the flags used to open the file (e.g. O_RDONLY), is this what we want? Looking at the field name exe_flags I would say no 🤔

Example exe_flags=O_RDONLY

11:45:57.319603569: Warning Sensitive file opened for reading by non-trusted program (file=/etc/pam.d/other gparent=gnome-terminal- ggparent=systemd gggparent=systemd evt_type=openat user=root user_uid=0 user_loginuid=1000 process=sudo proc_exepath=/usr/bin/sudo parent=zsh command=sudo cat /etc/shadow terminal=34822 exe_flags=O_RDONLY container_id=host container_name=host)

Probably this is the result of a copy and paste from Run shell untrusted rule

If this is true probably we want to remove this output field from these rules

[Andreagit97]

i realized this is a sort of "default" for all rules, but not sure this is what we want 🤔

[Andreagit97]

This PR #215 removes all the cases where exe_flags=%evt.arg.flags is always evaluated to <NA> but i think we should remove all cases apart the ones where the events involved are execve or execveat WDYT?

[incertum]

Also cross-linked it to #176 where there was an open item to not name it exe_flags, but flags instead.

But on a separate note if Falco cannot gracefully handle something not being present we should not do it.
And I start realizing that seeing NA fields causes panic among adopters, so having done this for consistency was the wrong choice.