RFC: new(modern_bpf): add security_file_mprotect #1601
Conversation
Signed-off-by: David Windsor <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dwindsor The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Please double check driver/SCHEMA_VERSION file. See versioning. /hold |
| auxmap__store_u32_param(auxmap, prot); | ||
|
|
||
| /*=============================== COLLECT PARAMETERS ===========================*/ | ||
| //auxmap__submit_event(auxmap, ctx); |
There was a problem hiding this comment.
The auxmap API is wrong (we should be using fixed-size ringbuf), but to illustrate the problem I'm facing, let's just go with this for now.
If this line is not commented out, the verifier fails:
libbpf: prog 'file_mprotect': BPF program load failed: Invalid argument
libbpf: prog 'file_mprotect': -- BEGIN PROG LOAD LOG --
processed 623 insns (limit 1000000) max_states_per_insn 4 total_states 50 peak_states 48 mark_read 3
-- END PROG LOAD LOG --
libbpf: prog 'file_mprotect': failed to load: -22
libbpf: failed to load object 'bpf_probe'
libbpf: failed to load BPF skeleton 'bpf_probe': -22
libpman: failed to load BPF object (errno: 22 | message: Invalid argument)/home/dave/src/libs/test/libscap/test_suites/engines/modern_bpf/modern_bpf.cpp:148: Failure
Value of: !h || ret != 0
Actual: true
Expected: false
Rather than digging deeper into this now, could I get a sanity check to see if this is the correct approach generally given the guidance in #963? @FedeDP
There was a problem hiding this comment.
I agree with this approach; i don't know why this is failing though ;)
Anyway, as shared privately, we surely need more work to understand how to integrate LSM/kprobes inside current libs architecture:
- we will have a single event (instead of pushing a fake empty exit event), while we always had enter/exit events until now
- kprobes/LSM don't carry a return code, therefore we need to understand how to deal with this too
- how to avoid enriching same state from different hooks (ie: both kprobe and syscalls)?
In the end, there are multiple questions looking for a good answer before we can start.
Hopefully maintainers will share some proposals soonish :)
Signed-off-by: David Windsor <[email protected]>
Signed-off-by: David Windsor <[email protected]>
Signed-off-by: David Windsor <[email protected]>
|
/milestone TBD |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh with Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle rotten |
|
Rotten issues close after 30d of inactivity. Reopen the issue with Mark the issue as fresh with Provide feedback via https://github.com/falcosecurity/community. |
|
@poiana: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
After #963, it is now possible to add new event types to Falco. With this, we are aiming to add the LSM hook
security_file_mprotectvia the guidance provided in #963.Please note that this is currently NOT WORKING, and some help would be appreciated to get this in.
As it stands, events for
security_file_mprotectare not being submitted to userspace. See my auto-review ofsecurity_file_mprotect.bpf.c.cc: @FedeDP @Andreagit97 @ecbadeaux
What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
Does this PR require a change in the driver versions?
What this PR does / why we need it:
Which issue(s) this PR fixes:
#252
Special notes for your reviewer:
Does this PR introduce a user-facing change?: