libs
libs copied to clipboard
falcosecurity
Add euid to execve/execveat exit events
We can't prevent losing setuid events completely and the uid is pretty important for some execve-related rules, so explicitly pass the uid in execve/at exit events
Signed-off-by: Grzegorz Nosek [email protected] Co-authored-by: Angelo Puglisi [email protected]
What type of PR is this?
Uncomment one (or more)
/kind <>lines:
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
Any specific area of the project related to this PR?
Uncomment one (or more)
/area <>lines:
/area build
/area driver-kmod
/area driver-bpf
/area driver-modern-bpf
/area libscap-engine-bpf
/area libscap-engine-gvisor
/area libscap-engine-kmod
/area libscap-engine-modern-bpf
/area libscap-engine-nodriver
/area libscap-engine-noop
/area libscap-engine-source-plugin
/area libscap-engine-udig
/area libscap
/area libsinsp
/area tests
/area proposals
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
NONE
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: gnosek
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [gnosek]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
The PR looks good but we still need to address the ARM workaround tracepoints for all the 3 drivers, this is the bpf one :point_down: https://github.com/falcosecurity/libs/blob/c1d075ffda41dcbdeec0a9fee86f288b7b360d19/driver/bpf/fillers.h#L6142
LGTM label has been added.
@incertum, @Andreagit97: I rebased the PR, care to take a look?
could we double-check this and cleanup if we don't support <2.6.20?
Looks like we still have <2.6.20 checks so I'd rather remove them all in a separate PR. I don't know if we actually run on <2.6.20 any more but I'd rather not break it on purpose in one place.
Hmm just noticed that the PT_ABSTIME patch that went in in #789 was slightly different so we still have a commit here:
commit 841bd9fd4fb5850a913a38c53b5b0dd4f1e5f8e1
Author: Grzegorz Nosek <[email protected]>
Date: Wed Dec 7 19:11:27 2022 +0100
fix(sinsp): format PT_ABSTIME values
Signed-off-by: Grzegorz Nosek <[email protected]>
diff --git a/userspace/libsinsp/event.cpp b/userspace/libsinsp/event.cpp
index 4dd490e92..69ed1110b 100644
--- a/userspace/libsinsp/event.cpp
+++ b/userspace/libsinsp/event.cpp
@@ -1425,7 +1425,6 @@ Json::Value sinsp_evt::get_param_as_json(uint32_t id, OUT const char** resolved_
break;
}
case PT_DYN:
- ASSERT(false);
snprintf(&m_paramstr_storage[0],
m_paramstr_storage.size(),
"INVALID DYNAMIC PARAMETER");
Do we want this? @Andreagit97 @incertum (probably with a better commit message if so)
@gnosek re above question we probably don't need this commit in this PR, ty.
LGTM label has been added.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, gnosek, hbrueckner, incertum
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [Andreagit97,FedeDP,gnosek,incertum]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment