Capabilities fixes #3006
Capabilities fixes #3006
Conversation
|
@josedonizetti I would like you to take a look at the changes related to "tracee-rules" (and tracee single binary) initialization, if possible. I postponed the privilege dropping so both tracee-ebpf and tracee could use the same "capabilities initialization" under Tracee.Init(). |
| @@ -105,32 +103,26 @@ func NewConfigsFromDir(dirPath string) ([]SignaturesConfig, error) { | |||
| func walkFilesWithExtensions(rootDir string, extensions []string) ([]string, error) { | |||
| var files []string | |||
|
|
|||
| err := capabilities.GetInstance().Specific( | |||
There was a problem hiding this comment.
Why do we remove this request?
There was a problem hiding this comment.
Ok, I see why from you commit message.
I'm just trying to think what should be done in the future if we need to call this function in runtime (maybe we will support dynamically loading new signatures?)
Can't we move the capabilities initialization part to be before calling this func?
There was a problem hiding this comment.
I'm just trying to think what should be done in the future if we need to call this function in runtime (maybe we will support dynamically loading new signatures?)
Yes, that will be the "next step", together with the "mapping all things that need to be done for the dynamic unload/load of signatures" (for the API). For now I thought it would be ok to keep it like this and fix the bugs we currently have (For the release). WDYT ?
When executing tracee-ebpf, the capabilities are dropped correctly, but when executing the single binary, they are not. That happens because the single binary calls a function to find signatures in a directory, and that function raised capabilities. Since the capabilities gwere not initialized at that moment (by tracee.New()), then they were initialized incorrectly (since GetInstace() initializes capabilities if it isn't yet). This commit removes capabilities raising from early stage functions, in tracee rules logic, and postpones a bit the full capabilities setup This way, both tracee-ebpf and tracee binaries can coexist with a working initialization logic. Fixes: #3004
Legacy attachments (for now: cgroupv2 prog attachments under older
kernels) might not be done using BpfLink logic. Without a file
descriptor for the link, tracee needs to raise its capabilities
in order to call bpf() syscall for the legacy detachment.
This fixes error happening in older kernels when exiting tracee:
{"level":"error","ts":1681876470.9877832,"msg":"failed to detach
probes when closing tracee","err":"probes.(*probes).DetachAll:
probes.(*cgroupProbe).detach: failed to detach program:
cgroup_skb_ingress (failed to detach (legacy) program
cgroup_skb_ingress from cgroupv2 /sys/fs/cgroup/unified)"}
Fixes: #2998
|
@yanivagman I believe this is ready for merging (for the release). |
commit cb71563 (HEAD -> capabilities-fixes, origin/capabilities-fixes)
Author: Rafael David Tinoco rafaeldtinoco@gmail.com
Date: Wed Apr 19 04:01:45 2023
commit b063b4b
Author: Rafael David Tinoco rafaeldtinoco@gmail.com
Date: Wed Apr 19 03:16:46 2023