cleanup(rules)!: refactor kernel module rule #43
Conversation
A major refactor of Falco now exposes each syscall Falco's libs supports to the end user :) Official support starts with Falco 0.35.0 Signed-off-by: Melissa Kilby <[email protected]>
poiana
added
kind/bug
rules/falco_rules.yaml
Outdated
| output: Linux Kernel Module injection using insmod detected (user=%user.name user_loginuid=%user.loginuid parent_process=%proc.pname module=%proc.args %container.info image=%container.image.repository:%container.image.tag) | ||
| condition: ((spawned_process and proc.name=insmod) or init_module) | ||
| and container | ||
| and not proc.args in (white_listed_modules) |
There was a problem hiding this comment.
Nice, thanks for noticing!
Btw, I am thinking that maybe it's time to change this rule and make it even better.
I would like to drop the part of the condition relying on insmod, and use instead the related syscalls, which is of course init_module but also finit_module (which is what my insmod is using). wdyt? :)
There was a problem hiding this comment.
Thank you @loresuso this is great! Done :)
There was a problem hiding this comment.
Nice! One last thing convertingwhite_listed_modules into an allowed_container_images_loading_kernel_module list and add it to the condition with and not and it's perfect for me!
incertum
changed the title
| @@ -3147,13 +3150,14 @@ | |||
| enabled: false | |||
| tags: [host, container, network, mitre_command_and_control, TA0011] | |||
|
|
|||
| - list: white_listed_modules | |||
There was a problem hiding this comment.
how are we going to handle the whitelisted kernel modules
There was a problem hiding this comment.
For me now given that the rule is changing, it makes sense having a whitelist on container images that can load modules
There was a problem hiding this comment.
did you add it in the condition
There was a problem hiding this comment.
no, that's what I was asking (see above), let's wait for Melissa :)
There was a problem hiding this comment.
with the whitelisted images (e.g. falco), I think we're good to go.
There was a problem hiding this comment.
Added, this is great feedback, ty :)
Since Falco 0.35 only alert on respective syscalls (init_module, finit_module). Deprecate alerting on spawned_process and insmod as proc.name. Co-authored-by: Lorenzo Susini <[email protected]> Signed-off-by: incertum <[email protected]>
incertum
force-pushed
the
kernel-module-rule
branch
from
c5b08d8 to
3723314
Compare
|
LGTM label has been added. Git tree hash: e0d44b38085b14a75df4f75f074e57a85ba287b4
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: incertum, jasondellaluce, loresuso The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Note for us: renaming the macro can represent a breaking change. Let's keep this in mind for the next falco_rules release. |
Maybe let's revert the macro, we should probably give a heads up in the release notes (saying this macro will be deprecated in release 3.8 or 9) |
What type of PR is this?
/kind bug
/kind cleanup
Any specific area of the project related to this PR?
/area rules
What this PR does / why we need it:
Rule "Linux Kernel Module Injection Detected" is limited in scope.
A major refactor of Falco now exposes each syscall Falco's libs supports (including
init_module) to the end user :)Official support starts with Falco 0.35.0.
Which issue(s) this PR fixes:
falcosecurity/falco#2443 (comment)
Fixes #
Special notes for your reviewer:
CC @loresuso @LucaGuerra @jasondellaluce