Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add by default runc as known_memfd_execution_binaries #266

Open
borrelm opened this issue Nov 4, 2024 · 5 comments
Open

Add by default runc as known_memfd_execution_binaries #266

borrelm opened this issue Nov 4, 2024 · 5 comments
Labels
kind/feature New feature or request

Comments

@borrelm
Copy link

borrelm commented Nov 4, 2024

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

@borrelm borrelm added the kind/feature New feature or request label Nov 4, 2024
@svendberg
Copy link

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
Copy link

svendberg commented Nov 8, 2024

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
Copy link

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

@svendberg
Copy link

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?

@walf443
Copy link

walf443 commented Dec 10, 2024

I also encountered this problem by upgrading k0s from v1.29.6+k0s.0 to v1.30.6+k0s.0.

And I confirmed #266 (comment) setting ignored this issue.

For known_memfd_execution_binaries settings backword compalibility, Is it good to introduce known_memfd_execution_pnames for PullRequest ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants