falcosecurity
Add by default runc as known_memfd_execution_binaries
Motivation
Since runc 1.1.15, that was notably deployed in AKSUbuntu-2204gen2containerd-202410.15.0 vs previous version, we do experience a hell lot of falco CRITICAL alerts
I'm clearly not a subject expert, so pardon me if it is non-sense, but I think this change in runc 1.1.15 may be the culprit of why it is now trigerring alerts.
Nonetheless, I think runc may be added to known_memfd_execution_binaries as it was suggested here but for unknown reason didn't make it to final release
Feature
Add runc as a known_memfd_execution_binaries to avoid false critical alerts
Alternatives
Additional context
We observe the same issue in our AKS clusters, and apparently, other people are experiencing it as well. https://learn.microsoft.com/en-us/answers/questions/2113575/experiencing-critical-fileless-execution-via-memfd
Well done, @borrelm, for identifying the root cause of the issue!
I don't think the changes mentioned will solve the issue.
In our case the process.name is reported as 5, not "runc", while process.pname is reported as "runc."
proc.name: 5
proc.pname: runc
In addition to adding "runc" to the items, I believe the rule should be changed to look at "pname" instead of "name".
From
macro: known_memfd_execution_processes
condition: (proc.name in (known_memfd_execution_binaries))
To
macro: known_memfd_execution_processes
condition: (proc.pname in (known_memfd_execution_binaries))
At the very least, this would allow us to add the necessary exception—if it makes sense to permit runc to operate like this.
We also experience this problem since upgrading AKS from 1.28 to 1.30. Is there any progress on this?
We have modified our rules to ignore runc for now by adding this (we are using the Falco Helm chart).
customRules:
rules-memfd.yaml: |-
- list: known_memfd_execution_binaries
items: [runc]
override:
items: append
- macro: known_memfd_execution_processes
condition: (proc.pname in (known_memfd_execution_binaries))
override:
condition: replace
It would be interesting to understand why runc's behavior changed to trigger the rule. And I guess we need this knowledge before deciding whether this exception belongs in the default rules?
I also encountered this problem by upgrading k0s from v1.29.6+k0s.0 to v1.30.6+k0s.0.
And I confirmed https://github.com/falcosecurity/rules/issues/266#issuecomment-2506347253 setting ignored this issue.
For known_memfd_execution_binaries settings backword compalibility, Is it good to introduce known_memfd_execution_pnames for PullRequest ?
this is what I went with on EKS. As stated above the proc name is "5" which is a file descriptor number and not suited for filtering on.
- macro: known_memfd_execution_processes
condition: >
(
proc.cwd startswith "/run/containerd/io.containerd.runtime.v2.task/k8s.io/" and
proc.sname = "containerd" and
proc.aname[2] = "oci-add-hooks" and
proc.exepath = "memfd:runc_cloned:/proc/self/exe" and
proc.pname = "runc"
)
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
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
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community. /close
@poiana: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with
/reopen.Mark the issue as fresh with
/remove-lifecycle rotten.Provide feedback via https://github.com/falcosecurity/community. /close
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-sigs/prow repository.