-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tetragon based file integrity monitoring (FIM) #2409
Comments
Hi 👋 , @kkourt! |
Once it is ready, please also add the CfP to the repo https://github.com/cilium/design-cfps |
Thanks @anfedotoff! Here are some first thoughts: Considering your proposal:
In the BPF code, what we do is: For the tetragon/bpf/process/types/basic.h Lines 2591 to 2598 in 82c4b13
We then filter: tetragon/bpf/process/types/basic.h Lines 1815 to 1820 in 82c4b13
And finally do the action: tetragon/bpf/process/types/basic.h Line 2358 in 82c4b13
So by the time we reach the action, we only have the string and we cannot get the hash. Hence, I believe we need to get the hash at the first step. So I was thinking something like:
I'm still not sure about the syntax, but the basic idea would be to push the computation of the hash early, when we extract the arguments. |
LGTM! We still able to filter by file path, before collecting a hash in your approach, right? In other words I mean not to call ima bpf-helpers if filtering is not passed. As far as I concerned, IMA bpf-helpers just retrieve the hash from IMA-measurement list. Difference between
Here you mean to call appropriate bpf-helper according to kernel version? Or user specifies the helper it prefers? I think, the first way is better. |
I think it should be possible to collect the hash after the filtering, but it's more tricky. In that case, collecting the hash in the action makes more sense to me, but we will need to maintain the necessary arguments to call the helpers.
I would do the simple thing first, allowing users to specify exactly what they want. We can add a detection function to reject the policy if the helper does not exist. |
Ah, I understood. Before args filtering, we need to retrieve all arguments. I think we can try to implement your approach. To get hash using an action, we need to store arguments for bpf-helpers somewhere (suppose in separate bpf-map). So, for now, using actions looks more complicated for me:)).
It makes sense. I'll take time to learn more about how to validate tracing policy for correctness. |
Here's an example of checking whether the "multi kprobe" feature is supported: Line 45 in e7c9ec3
What we can do then is check to see whether a specific feature is supported iff it's used by a tracing policy. See for example: tetragon/pkg/sensors/tracing/enforcer.go Line 283 in e7c9ec3
|
Is there an existing issue for this?
Is your feature request related to a problem?
No response
Describe the feature you would like
We could use Tetragon for file integrity monitoring: collect hashes of executed binaries and opened files and put this information in events. Hashes are calculated using IMA-measurement Linux integrity subsystem.
Describe your proposed solution
We already talked about FIM. I found some technical issues during my research, so I decided to provide a CFP before PR.
Code of Conduct
The text was updated successfully, but these errors were encountered: