Add by default runc as known_memfd_execution_binaries

[borrelm]

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

[svendberg]

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!

[svendberg]

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.

[michaelSchmidMaloon]

We also experience this problem since upgrading AKS from 1.28 to 1.30. Is there any progress on this?

[svendberg]

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?