Missing syscalls events when multi-event name in rule condition

[brness]

Describe the bug I want to test if falco can capture the fchownat syscall in my enviroment, here is the thing, If I set the condition condition: container.id != host and evt.type in (fchownat) and k8s.pod.name=nginx-pod-b965fcc45-nk5xx falco indeed can shows {"hostname":"falco-99tt5","priority":"Notice","rule":"The program is run in a container","source":"syscall","time":"2023-01-11T07:26:36.764431585Z", "output_fields": {"container.id":"1b93d2852905","evt.args":"","evt.time":1673421996764431585,"evt.type":"fchownat","fd.directory":null,"fd.name":null,"k8s.ns.name":"demo","k8s.pod.name":"nginx-pod-b965fcc45-nk5xx","proc.cmdline":"chown root file1","proc.name":"chown","proc.pname":"bash","proc.vmsize":12684,"syscall.type":"fchownat","user.name":"<NA>"}} {"hostname":"falco-99tt5","priority":"Notice","rule":"The program is run in a container","source":"syscall","time":"2023-01-11T07:26:36.764473224Z", "output_fields": {"container.id":"1b93d2852905","evt.args":"","evt.time":1673421996764473224,"evt.type":"fchownat","fd.directory":null,"fd.name":null,"k8s.ns.name":"demo","k8s.pod.name":"nginx-pod-b965fcc45-nk5xx","proc.cmdline":"chown root file1","proc.name":"chown","proc.pname":"bash","proc.vmsize":12684,"syscall.type":"fchownat","user.name":"<NA>"}}

however if I change the condition into condition: container.id != host and evt.type in (fchownat, stat, access) and k8s.pod.name=nginx-pod-b965fcc45-nk5xx then only access event was captured in falco logs {"hostname":"falco-99tt5","priority":"Notice","rule":"The program is run in a container","source":"syscall","time":"2023-01-11T07:36:14.076586416Z", "output_fields": {"container.id":"1b93d2852905","evt.args":"mode=0(F_OK) ","evt.time":1673422574076586416,"evt.type":"access","fd.directory":null,"fd.name":null,"k8s.ns.name":"demo","k8s.pod.name":"nginx-pod-b965fcc45-nk5xx","proc.cmdline":"chown root file1","proc.name":"chown","proc.pname":"bash","proc.vmsize":364,"syscall.type":"access","user.name":"<NA>"}} {"hostname":"falco-99tt5","priority":"Notice","rule":"The program is run in a container","source":"syscall","time":"2023-01-11T07:36:14.076594852Z", "output_fields": {"container.id":"1b93d2852905","evt.args":"res=-2(ENOENT) name=/etc/ld.so.nohwcap ","evt.time":1673422574076594852,"evt.type":"access","fd.directory":null,"fd.name":null,"k8s.ns.name":"demo","k8s.pod.name":"nginx-pod-b965fcc45-nk5xx","proc.cmdline":"chown root file1","proc.name":"chown","proc.pname":"bash","proc.vmsize":364,"syscall.type":"access","user.name":"<NA>"}} {"hostname":"falco-99tt5","priority":"Notice","rule":"The program is run in a container","source":"syscall","time":"2023-01-11T07:36:14.076619050Z", "output_fields": {"container.id":"1b93d2852905","evt.args":"mode=4(R_OK) ","evt.time":1673422574076619050,"evt.type":"access","fd.directory":null,"fd.name":null,"k8s.ns.name":"demo","k8s.pod.name":"nginx-pod-b965fcc45-nk5xx","proc.cmdline":"chown root file1","proc.name":"chown","proc.pname":"bash","proc.vmsize":372,"syscall.type":"access","user.name":"<NA>"}}

How to reproduce it

1. install the falco helm
2. set the custon falco rule as condition: container.id != host and evt.type in (fchownat) and k8s.pod.name=nginx-pod-b965fcc45-nk5xx where the k8s.pod.name is the name of pod to execute chown command
3. enter the nginx pod and execute chown root file1
4. check the falco logs and record it as log_previous
5. change the falco custom rule into condition: container.id != host and evt.type in (fchownat, stat, access) and k8s.pod.name=nginx-pod-b965fcc45-nk5xx
6. enter the nginx pod again and execute chown nobody file1
7. check the falco logs and record it as log_multi_name
8. compare the two log files

Expected behaviour log_multi_name would contains the syscall events of fchownat just as log_previous would do

Screenshots this is the previous one this is the multi_name log

Environment

• Falco version:
• Falco version: 0.33.1 Libs version: 0.9.2 Plugin API: 2.0.0 Driver: API version: 2.0.0 Schema version: 2.0.0 Default driver: 3.0.1+driver
• System info:
• Cloud provider or hardware configuration:
• OS: rke
• Kernel:
• PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
• Installation method:

  Helm falco Additional context

I already try to use -A to get general syscall events, and if I don't specify the evt.names, fchownat can't show up as well

[FedeDP]

Hi! Thanks for reporting this issue! I honestly think this is rather important, let's give it a try for 0.10.1! /milestone 0.10.1

[FedeDP]

Mmh running sinsp-example directly works:

./libsinsp/examples/sinsp-example -f "evt.type in (fchownat, stat, access)" -o "%evt.type %syscall.type"

...
{"evt.type":"access","syscall.type":"access"}
{"evt.type":"access","syscall.type":"access"}
{"evt.type":"fchownat","syscall.type":"fchownat"}
{"evt.type":"fchownat","syscall.type":"fchownat"}
...

[FedeDP]

This gets fixed by: https://github.com/falcosecurity/falco/pull/2347

I don't think we will make it for 0.34.0 though :(

[FedeDP]

Since it is a Falco issue, i'll move this to Falco!

[brness]

OK, That would be so nice!!

[FedeDP]

/milestone 0.35.0