Falco EBPF On Ubuntu 22.04: Least Privileged Bug?

Hey folks! 👋 If you're using Falco with the modern eBPF probe and running it on Ubuntu 22.04, you might be running into a bit of a snag. It seems like the modernEbpf.leastPrivileged setting, which is supposed to give Falco the least amount of permissions it needs to do its job, isn't quite working as expected on this particular Ubuntu version. Let's dive in and see what's going on, and maybe figure out a fix.

The Problem: Falco Crashing on Startup 💥

So, here's the deal. When you deploy Falco using version 7.0.0 of the Helm chart (which includes Falco 0.42.0), it's crashing right as it tries to start up. The error messages you'll see in the logs look something like this:

falco Mon Oct 27 15:28:04 2025: [libs]: libbpf: tracepoint 'syscalls/sys_enter_connect' perf_event_open() failed: Permission denied
falco Mon Oct 27 15:28:04 2025: [libs]: libbpf: prog 'connect_e': failed to create tracepoint 'syscalls/sys_enter_connect' perf event: Permission denied

This is a serious issue because Falco needs to be up and running to actually monitor and protect your systems. The core of the problem lies in how Falco interacts with the kernel to monitor system calls. It uses eBPF (extended Berkeley Packet Filter) to do this, and the leastPrivileged setting is supposed to restrict the permissions it needs. However, a recent change in the libs (specifically, this pull request: https://github.com/falcosecurity/libs/pull/2581) introduced a dependency on perf_event_open. This is a system call used for performance monitoring, but it's restricted by default on Ubuntu 22.04. Ubuntu sets kernel.perf_event_paranoid=4 by default, which means that only processes with CAP_SYS_ADMIN can use perf_event_open. This creates a conflict because leastPrivileged is intended to avoid giving Falco this level of privilege.

How to Reproduce the Issue ⚙️

If you want to see this firsthand, here's how to reproduce the issue:

1. Use Helm chart version 7.0.0 (which includes Falco 0.42.0).
2. Run this on a host with Ubuntu 22.04.
3. Deploy Falco with eBPF enabled and the leastPrivileged setting turned on. This means you'll give it these capabilities: BPF, SYS_RESOURCE, PERFMON, and SYS_PTRACE.

Then, boom, Falco should crash as soon as it tries to start.

Expected Behavior ✅

Ideally, Falco should be able to start without any issues, even with leastPrivileged enabled. It should be able to monitor system calls and do its job without needing excessive permissions. No crashes, no permission errors – just smooth sailing!

Diving Deeper: Understanding the Root Cause 🔍

The issue boils down to a conflict between Falco's needs and the security restrictions imposed by Ubuntu 22.04. The perf_event_open system call is crucial for Falco's eBPF probe to function, but it's locked down by default. The leastPrivileged setting tries to give Falco just enough permissions, but it doesn't include CAP_SYS_ADMIN, which is required to use perf_event_open under the default Ubuntu settings.

This means that the current configuration in leastPrivileged is insufficient for Falco to function correctly on Ubuntu 22.04. The question is, how do we solve this? It might involve either:

• Adding CAP_SYS_ADMIN to Falco's capabilities (which goes against the principle of least privilege).
• Reducing kernel.perf_event_paranoid to a less restrictive value (e.g., 2), which could potentially weaken system security.

Neither of these is an ideal solution, and the best approach might depend on your specific security requirements and the overall threat model of your environment. It's a tricky balancing act between security and functionality!

Potential Solutions and Workarounds 🤔

So, what can you actually do to fix this? Here are a few potential solutions and workarounds. Remember, each of these has its own pros and cons, so choose the one that best fits your needs.

1. Modify kernel.perf_event_paranoid

This is a system-wide setting, so it's a bit of a blunt instrument. You could try reducing kernel.perf_event_paranoid to 2. This would allow Falco to use perf_event_open without needing CAP_SYS_ADMIN. The downside is that it relaxes the security posture of your entire system. This is something to consider, as it makes the host more vulnerable.

Pros:

• Simple to implement.
• Falco should start without needing any changes to its permissions.

Cons:

• Reduces system-wide security.
• Might not be acceptable in all environments.

2. Grant CAP_SYS_ADMIN to Falco

This is the most straightforward solution to get Falco working. You would add CAP_SYS_ADMIN to the list of capabilities given to the Falco container. You can set this in your deployment configuration. It's a trade-off: you're giving Falco more power than it ideally needs, which expands the potential attack surface if Falco were to be compromised.

Pros:

• Falco should start without needing any changes to the host's kernel settings.
• Relatively simple to implement.

Cons:

• Increases the attack surface if Falco is compromised.
• Violates the principle of least privilege.

3. Consider a Custom eBPF Probe (Advanced)

This is the most complex option. You could potentially create a custom eBPF probe that works around the need for perf_event_open. This would involve writing your own eBPF code. This is definitely for the advanced users, and it could potentially give you the best of both worlds by getting Falco to work without the need for CAP_SYS_ADMIN. You would need a deep understanding of eBPF and the kernel internals.

Pros:

• Potentially the most secure solution.
• Avoids the need for elevated privileges.

Cons:

• Requires advanced technical skills.
• Complex to implement and maintain.

4. Wait for a Falco Update (Hopefully!) 🤞

Keep an eye on the Falco project. There's a chance the Falco team might find a way to work around this issue or provide a more elegant solution in a future release. This would be the ideal outcome, as it wouldn't require any changes to your environment.

Pros:

• No changes needed to your current setup.
• Maintained by the Falco community.

Cons:

• Relies on someone else finding a solution.
• Might take some time.

Environment Details 💻

Here's a quick rundown of the environment where this issue was encountered:

• Falco Version: 0.42.0 (from Helm chart 7.0.0).
• System Info: (You can get this using falco --support | jq .system_info)
• Cloud Provider/Hardware: OpenStack VM.
• OS: Ubuntu 22.04.5 LTS.
• Kernel: Linux 5.15.0-160-generic.
• Installation: Helm chart.

If you're experiencing this issue, please double-check that your environment matches these details. It will help to make sure that the solutions apply to your case.

Additional Context 📚

This problem arises because of a change in Falco's dependencies, which now uses perf_event_open. The default security settings in Ubuntu 22.04 prevent this from working without the correct privileges. This issue is not directly related to Falco itself but rather to the interaction of the security settings of the host OS and the requirements of the updated Falco. The core issue is the conflict between the leastPrivileged setting and the default Ubuntu 22.04 security settings regarding the perf_event_open syscall.

Conclusion: Navigating the eBPF and Ubuntu 22.04 Maze 🧭

So there you have it, folks! It's a known issue that we have to work through. This is an interesting situation that highlights the trade-offs between security, functionality, and the evolving nature of software. Until there's a more permanent fix, you'll need to choose one of the workarounds. Remember to carefully evaluate the risks and benefits of each approach. Stay tuned for updates from the Falco team, and let's hope for a more seamless experience in the future!

If you have any other insights, or if you've found another solution, definitely share them! Let's help each other out!