r/eBPF

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

Hello,

I am a writing BPF program to monitor network packet drops, the reason why they are dropping, connections etc. Using tracepoint/skb/kfree_skb and kprobe/udp_sendmsg for monitoring UDP connections and drop reasons. However, the program doesn't show the reason such as DNS couldn't resolve or the reason code for this.

So the question is which kernel function or tracepoint I can use to get this information?

What my program displays right now while querying invalid website:

  {
    "type": "UDP",
    "pid": 519,
    "uid": 991,
    "comm": "systemd-resolve",
    "src": "10.0.2.15",
    "sport": 31956,
    "dst": "10.0.2.3",
    "dport": 53
  },
  {
    "type": "UDP",
    "pid": 519,
    "uid": 991,
    "comm": "systemd-resolve",
    "src": "10.0.2.15",
    "sport": 1763,
    "dst": "10.0.2.3",
    "dport": 53
  },
  {
    "type": "PKT_DROP",
    "pid": 4295,
    "uid": 0,
    "comm": "kworker/0:0",
    "src": "-",
    "sport": 0,
    "dst": "-",
    "dport": 56,
    "drop_reason": "OTHER"
  },
  {
    "type": "UDP",
    "pid": 2126,
    "uid": 115,
    "comm": "cups-browsed",
    "src": "127.0.0.1",
    "sport": 38575,
    "dst": "127.0.0.53",
    "dport": 53
  },

Thanks in advance! I'd appreciate any help or reading materials regarding this.

Hey r/eBPF,

I recently open-sourced AI Agentic Nano Previlaged Access management (NanoPAM) (Aegis-XDP) — a transparent Layer-2 bridge that does port-level PAM + token-bucket rate limiting entirely in XDP.

We achieved:

• P50 = 629 ns

• P99 = 645 ns (<41 ns variance)

• 8,000× faster than traditional Netfilter/iptables

Full technical deep-dive (with architecture diagrams, benchmarks, and jitter graphs) is here:

https://medium.com/@reachshankarg/how-we-achieved-629ns-deterministic-latency-using-ebpf-xdp-and-5-1ghz-isolated-cores-90a15f3e81e1

GitHub repo (source + build instructions): https://github.com/reachshankarg-byte/NanoPAM

Would love feedback from the eBPF community — especially on the XDP fast path and CPU isolation approach. Thanks!

Hi r/ebpf,

I’m working on Rustinel, an open-source endpoint detection project for Windows and Linux.

On the Linux side, the project uses eBPF to collect endpoint telemetry and feed a shared detection pipeline. Current Linux coverage focuses on:

- Process activity

- Network activity

- File activity

- DNS-related telemetry

The collected events are normalized into a shared model, then evaluated against Sigma rules, YARA rules and IOC indicators. Alerts are written as ECS-compatible NDJSON so they can be ingested into SIEM/log pipelines.

I’m very interested in feedback from people with more eBPF experience.

The project is written in Rust and is still evolving. Windows coverage is broader today, so the Linux/eBPF side is one of the areas where feedback would be especially useful.