tracee
tracee copied to clipboard
aquasecurity
Container Enrichment for net events
Initial Checklist
- [x] There is an issue describing the need for this PR.
- [x] Git log contains summary of the change.
- [x] Git log contains motivation and context of the change.
- [ ] If part of an EPIC, PR git log contains EPIC number.
- [ ] If part of an EPIC, PR was added to EPIC description.
Description (git log)
commit b1bbd031fd5f37f0fd07f29831b2c70353a451f5
Author: Nadav Strahilevitz <[email protected]>
Date: Sun Jul 10 14:53:20 2022 +0000
procinfo: enrich cgroup and container data
By adding the CgroupID from sched_process_fork to the procinfo map
we can use it later to enrich the net events so they go through
enrichment logic.
commit 0edb4fb445066a83dc1c2e434c6f9b1cf57b696c
Author: Nadav Strahilevitz <[email protected]>
Date: Sun Jul 10 14:52:11 2022 +0000
net_events: merge into pipeline
Fans in the network trace.Event generator into the standard ebpf
pipeline.
This way, logic isn't duplicated between the two, and net events can
go through the container enrichment process.
Fixes: #1922
Type of change
- [ ] Bug fix (non-breaking change fixing an issue, preferable).
- [ ] Quick fix (minor non-breaking change requiring no issue, use with care)
- [x] Code refactor (code improvement and/or code removal)
- [x] New feature (non-breaking change adding functionality).
- [ ] Breaking change (cause existing functionality not to work as expected).
How Has This Been Tested?
First, create a linux distro image with a ping command (in this test we use ubuntu)
- run tracee:
sudo ./dist/tracee-ebpf --containers -o json -o option:parse-arguments -o option:detect-syscall -t container -t event=net_packet -t net=docker0 - open a networking container
- run
ping google.com
Confirm the net_packet events are enriched. Test steps 1 and 2 in reverse as well.
Final Checklist:
Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.
- [ ] I have made corresponding changes to the documentation.
- [x] My code follows the style guidelines (C and Go) of this project.
- [x] I have performed a self-review of my own code.
- [x] I have commented all functions/methods created explaining what they do.
- [x] I have commented my code, particularly in hard-to-understand areas.
- [x] My changes generate no new warnings.
- [ ] I have added tests that prove my fix, or feature, is effective.
- [x] New and existing unit tests pass locally with my changes.
- [x] Any dependent changes have been merged and published before.
Git Log Checklist:
My commits logs have:
- [x] Subject starts with "subsystem|file: description".
- [x] Do not end the subject line with a period.
- [x] Limit the subject line to 50 characters.
- [x] Separate subject from body with a blank line.
- [x] Use the imperative mood in the subject line.
- [x] Wrap the body at 72 characters.
- [x] Use the body to explain what and why instead of how.
Now that we have thread_info_map in bpf code, we can do all the enrichment there, and procinfo is not required anymore. I would even redirect net events (non pcap) to the events buffer instead of the net_events buffer.
As long as we have both buffers, we still need this pipeline source merge at the very least. And we could still move the procinfo enrichment to kernel, that's probably the right thing to do as well.
but just so we can get container enrichment for net events in, we can merge this first and then remove the procinfo code and move the net events submission buffer (in one or two PRs) later down the line, WDYT? I can attempt those PRs myself if you want, but as a first step at least this PR works.
Now that we have thread_info_map in bpf code, we can do all the enrichment there, and procinfo is not required anymore. I would even redirect net events (non pcap) to the events buffer instead of the net_events buffer.
As long as we have both buffers, we still need this pipeline source merge at the very least. And we could still move the procinfo enrichment to kernel, that's probably the right thing to do as well.
Why is that? If we perform the enrichment in the kernel and send the events in the events buffer, there is no need for this pipeline source merge. The net_events buffer will only be used for pcaps, for which the pipeline isn't needed
Why is that? If we perform the enrichment in the kernel and send the events in the events buffer, there is no need for this pipeline source merge. The net_events buffer will only be used for pcaps, for which the pipeline isn't needed
Correct me if i'm wrong, direct submission of net_packet events from ebpf will still be through the old net event buffer right? If these can still be emitted, they need to go through the standard event pipeline down the line. If they are only submitted for capturing and not emitted, then we can just trim that pipeline code down and be satisfied with that (ideally with a name change).
Correct me if i'm wrong, direct submission of net_packet events from ebpf will still be through the old net event buffer right? If these can still be emitted, they need to go through the standard event pipeline down the line. If they are only submitted for capturing and not emitted, then we can just trim that pipeline code down and be satisfied with that (ideally with a name change).
I might have this changed because of the networking fixes/changes. Please hold this PR until we merge the network fixes PRs (soon) and I'll come back here so we can finish this.
I have converted this to draft so this is not lost (for my reference) BUT it is likely that this won't be merged because of the new networking code. Either way I might want to keep a reference to this code and point to this PR.