feat(events): create access_remote_vm event

[AlonZivony]

1. Explain what the PR does

An event for accessing the memory of a process externally (can be the same process) by the mem file of the process in procfs.

789bd69 test(events): add e2e test to access_remote_vm
fd6e01a feat(events): create access_remote_vm event
0854a88 feat(ebpf): support 7 arguments saving for kretprobe
491ba04 feat(events): add probe relevance attribute

Fix #3518

2. Explain how to test it

3. Other comments

[rafaeldtinoco]

I loved the event! It LGTM, definitely.

There are just minor spell nits, some comments to be added to make it easier to understand your intents (if my interpretation is correct).

A small "point to clear" would be the VMA naming strategy/logic. I left a question for you there.

Also, If you could add a simple e2e-inst trigger for this type of event I would also appreciate (like we already spoke).

Nice work!

[rafaeldtinoco]

I haven't seen a single test failing till now, so I am not sure to what you are referring. I can't really understand the problem without seeing it, so if you can reset the tests for me to see or send me a test suite that failed I will dig deeper.

Fix your pr.yaml file and force push. Wait for tests to finish and you will see. I dont need to reset anything on my side. Your pr.yaml is wrong.

[rafaeldtinoco]

However, I don't see why should we have a sleep in the test like in the process tree. There is no state here to initialize. If there is a timing issue here, it is an issue with all e2e tests and should be fixed by the tests environment. However, I can add for now a sleep if you think it will solve it.

Never said it was a definitive answer. My feedback was "it might be related", but it might be an entire different thing. When you fix pr.yaml and tests fail you will be able to see. Let me know if you need a VM with the same images that are failing (but it might be intermittent among all of them, without considering v6.5 which always fails due to other reasoning).

[rafaeldtinoco]

For the record:

https://gist.github.com/rafaeldtinoco/bb0bcf795fb2c821136db01417ca669a
https://gist.github.com/rafaeldtinoco/7042acfa78d3c7ca3f31ce8147d54255

Those files show the execution path in a 5.19 (event works) vs a 6.5 (event does not work).

rafaeldtinoco@rugged:mine$ gh gist create asyncio.perf.5.19.0-50-generic
- Creating gist asyncio.perf.5.19.0-50-generic
✓ Created secret gist asyncio.perf.5.19.0-50-generic
https://gist.github.com/rafaeldtinoco/bb0bcf795fb2c821136db01417ca669a

rafaeldtinoco@rugged:mine$ gh gist create asyncio.perf.6.5.9-arch2-1
- Creating gist asyncio.perf.6.5.9-arch2-1
✓ Created secret gist asyncio.perf.6.5.9-arch2-1
https://gist.github.com/rafaeldtinoco/7042acfa78d3c7ca3f31ce8147d54255

Im using https://gist.github.com/rafaeldtinoco/1e619d9d25a4a934b0ef577304125b87 to test.

[AlonZivony]

Alright, but be aware that there are many detections from this signature coming from regular processes (not sure your signature will filter for specific stuff, but systemd, dbus-daemon, etc are all being "detected").

Yea I am aware, but there is enough information in the event to filter regular stuff out.

Another thing, are you sure you want 1 event per VMA ? You may gets lots of events from the same action:

You are right that it might spam, but it is significant.
Each vma has its own name and own permissions, and you don't see operations on the file done frequently or in massive amount.
It might be a cause of malicious spam, but it is true for almost any event.

[AlonZivony]

Only pushed to see tests, still not fixed

[rafaeldtinoco]

Looks like the tests failed but when looking at the output the event (at least on 4.18) worked. Needs some fine tuning I believe.

[AlonZivony]

You can see that the problem is the version check, because the remote_pid value is 0.
I will try to find another type.

[geyslan]

We have this update #3875

Please rebase your PR against main to make use of the new workflow setup.