feat(events): add process execution tracking #142
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change introduces the capability to monitor process execution events by adding a new eBPF program attached to the `bprm_check_security` LSM hook. A `PROCESS_EXEC` event type is added to the event pipeline. The gRPC API is extended with a new `SignalService` to handle these process-related signals, separate from the existing file activity service. The event handling logic is refactored to differentiate between file and process events, routing them to their respective gRPC streams.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This change introduces the capability to monitor process execution events by adding a new eBPF program attached to the
bprm_check_securityLSM hook.A
PROCESS_EXECevent type is added to the event pipeline. The gRPC API is extended with a newSignalServiceto handle these process-related signals, separate from the existing file activity service.The event handling logic is refactored to differentiate between file and process events, routing them to their respective gRPC streams.
This is an alternative to #141, with this one being a "hand-crafted" implementation. They are both pretty similar, took about the same time to implement but this one has slightly more functionality and better coding quality IMO, do with that information what you will.
Checklist
Automated testing
If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why you did not do so. (Valid reasons include "CI is sufficient" or "No testable changes")
In addition to reviewing your code, reviewers must also review your testing instructions, and make sure they are sufficient.
For more details, ref the Confluence page about this section.