Problem With Deploying Defend 4 Container from Elastic due to missing kernel option

[pl853]

Describe the bug

Hi,

We are currently enrolling Elastic Defend for Containers on our Vmware Tanzu Kubernetes env. running photonOS.

This however isnt working because the CONFIG_BPF_LSM option isnt set in the kernel. Is it possible for you guys to deploy this by default? If no, what would be the best way to do this ourselves and is there a chance this would mess up our envirionment.

Kind regards,
P.

Reproduction steps

1. Have Vmware Tanzu Kubernetes with PothonOS
2. Install defend for containers
3. watch it not working
   ...

Expected behavior

1. Have Vmware Tanzu Kubernetes with PothonOS
2. Install defend for containers
3. watch it work
   ...

Additional context

No response

[dcasota]

Hi,

Yes, Photon OS 5 does not enable CONFIG_BPF_LSM by default. The main use case is observability/tracing with post-facto killing. Relying on userspace kill responses or weaker fallbacks increases residual risk of compromise. On the other scale pan, the somewhat reduced footprint reduces overall risk.
For Ubuntu with enabled CONFIG_BPF_LSM by default, the main use case is eligibility for in-kernel enforcement. On the other scale pan, that expands the kernel attack surface for privileged attackers. Compromised root could load malicious BPF programs to bypass security, and interactions with other kernel bugs could lead to container escapes or info leaks.

TKG v2.5+ docs [2] state Ubuntu 22.04 and Photon OS 5 are hardened to CIS/STIG standards out-of-the-box, and both OS are a few years old now.
Situation since ~2023: There were some eBPF verifier vulnerabilities.
Situation 2026: The latest eBPF-related CVE-2025-39748 (CVSS 5.5) is fixed in Ubuntu 22.04 (USN-8028-6 - published February 19, 2026). There are ongoing reports of eBPF verifier pruning bypasses [4].

fyi Elastic Defend for Containers is deprecated [1] since 9.0.0 and there is no direct built-in replacement from Elastic for runtime container protection. E.g Falco as alternative is for detection + response only, hence it does not require CONFIG_BPF_LSM set. E.g. Kubearmor requires CONFIG_BPF_LSM set for in-kernel enforcement.

In my opinion from a residual risk management perspective, the above list includes the longer-term effects of advantages and disadvantages. The residual risk is not static with regard to AI-generated attack patterns.

---

[1] https://www.elastic.co/docs/release-notes/security/deprecations
[2] https://techdocs.broadcom.com/us/en/vmware-tanzu/standalone-components/tanzu-kubernetes-grid/2-5/tkg/mgmt-release-notes.html
[3] https://ubuntu.com/security/CVE-2025-39748
[4] e.g. https://nebelwelt.net/files/25SOSP.pdf

[pl853]

hi @dcasota ,

Thankyou for the very informational response! Elastic re-introduced D4C because they found out their costumer base on kubernetes was quite large, after deprecating it not long ago.

I hear LSM is only required for Drift detection and container lvl blocking. Therefore, since we only want to use it for telemtry gathering, i'm going to ask for an enhanchement request to be able to have a 'non LSM' mode.

If this isnt going to work out, what would be a way for us to enable the CONFIG_BPF_LSM option? And would this possibly "break the system"?

Also will this go against our support contract to do something like that?

Again thankyou for the help

Kind regards,
P

[dcasota]

Hi @pl853,

I don't know what Elastic will do or not, and about your support contract concerns. However, the Photon OS team will certainly review the thread and provide you with a well-founded answer.

[dcasota]

Hi Photon OS team,
the attached Excel sheet comparison.xlsx contains a five-row comparison table contrasting Linux LSM/eBPF security (including CONFIG_BPF_LSM) with the equivalent of Windows Defender ETW AutoLoggers, covering enforcement hooks, audit layers, configuration options, fixes since 2020, and residual risks against autonomous AI-generated threats with MITRE ATT&CK and ATLAS mitigations. Well, this is for the weekend :-) Literature is talking about QML-powered real-time anomaly detection on kernel telemetry...

[bhllamoreaux]

Hi @pl853,

The only way to enable CONFIG_BPF_LSM would be to compile your own Photon kernel with this option. It's doable, but not recommended, and probably against your support contract since it wouldn't be an official Photon build. You'd have to continually maintain it, e.g rebuild with each new Photon kernel commit, to consume all the new CVE/bug fixes. And deploying it via Tanzu, no idea how that works.

With regard to enabling this option in Photon, typically we'd prefer not to, unless there is a real need for it. It helps to keep the kernel smaller and reduces the security attack surface.

Please update us if you can get a non-LSM mode, or if you'll really need this option enabled. We can consider adding it in that case.