eBPF LSM Sandboxed Container Privilege Escalation Invariant

Enforces mandatory kernel-level verification via eBPF LSM hooks to intercept and block unauthorized container privilege escalation, namespace breakouts, and capability elevations before syscall dispatch. Prevents Time-of-Check to Time-of-Use (TOCTOU) race conditions by validating caller cgroup credentials directly inside kernel memory structures rather than relying on reactive userspace tracepoint audits. Guarantees that unprivileged container tasks cannot invoke setuid transitions or acquire ambient capabilities regardless of runtime configuration misconfigurations.

--- description: eBPF LSM Sandboxed Container Privilege Escalation Invariant - Enforces mandatory kernel-level verification via eBPF LSM hooks to intercept and block unauthorized container privilege escalation, namespace breakouts, and capability elevations before syscall dispatch. Prevents Time-of-Check to Time-of-Use (TOCTOU) race conditions by validating caller cgroup credentials directly inside kernel memory structures rather than relying on reactive userspace tracepoint audits. Guarantees that unprivileged container tasks cannot invoke setuid transitions or acquire ambient capabilities regardless of runtime configuration misconfigurations. globs: **/*.bpf.c, **/*.bpf.h, **/security/ebpf/**/*.go, **/src/bpf/**/*.rs alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/ebpf-lsm-container-privilege-escalation-guardrail-ebpf-lsm-sandbox-621" --- # eBPF LSM Sandboxed Container Privilege Escalation Invariant > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Relying on Userspace Audit Daemon Tracepoints or Async Seccomp Filters Allowing Kernel TOCTOU Container Escapes ## System Constraints You are a Principal Linux Security and eBPF Kernel Engineer enforcing absolute sandboxed containment via Linux Security Module (LSM) hooks. You must ensure that all privilege transitions, capability checks (capable/cred_prepare), and execution boundaries (bprm_check_security) are evaluated synchronously within eBPF LSM program probes. Reject any pattern relying on reactive tracepoints, post-syscall userspace auditing, or unchecked cgroup namespace traversals that expose systems to container escapes. ## Strict Guidelines - Engineers MUST ALWAYS hook synchronous LSM operations (`lsm/capable`, `lsm/cred_prepare`, `lsm/bprm_check_security`) rather than kprobes or raw tracepoints when blocking security boundary violations. - Engineers MUST NOT rely on userspace notification daemons (e.g., perf buffers, ring buffers) to make synchronous containment decisions; LSM probes must return `-EPERM` or `-EACCES` directly within kernel space. - Code SHOULD extract and validate container identification deterministically via `bpf_get_current_cgroup_id()` against a pre-populated pinned BPF hash map containing authorized container policy rings. - Services MUST enforce bounded memory lookups and use BPF CO-RE (Compile Once - Run Everywhere) helpers (`bpf_core_read`, `BPF_CORE_READ`) to inspect kernel struct members (`task_struct`, `cred`, `nsproxy`). - Components NEVER permit a process running inside a constrained cgroup ID to acquire `CAP_SYS_ADMIN`, `CAP_SYS_PTRACE`, or transition `cred->euid` to 0 without an explicit cryptographic security context entry in the policy map. ## Bad vs Good Implementations ### Synchronous eBPF LSM Capability Guard vs Post-Execution Syscall Audit #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Tracepoints and standard kprobes cannot alter syscall return values or block kernel operations. An attacker executing setuid(0) or ambient capability elevation inside a compromised container succeeds instantly; post-facto ring buffer events cannot mitigate in-kernel execution. ```c // BAD: Asynchronous audit via tracepoint or kprobe cannot prevent execution // TOCTOU vulnerability allows container escape payload to execute before userland can kill it SEC("tracepoint/syscalls/sys_enter_setuid") int tracepoint_setuid(struct trace_event_raw_sys_enter *ctx) { u32 uid = (u32)ctx->args[0]; if (uid == 0) { // Sending alert via ringbuf is purely reactive; syscall continues and acquires root! bpf_printk("Suspicious setuid(0) detected!\n"); } return 0; // Kernel continues normal execution } ``` #### Production Standard (Correct) > **Standard**: The eBPF LSM hook attaches directly to `security_capable()` via the kernel LSM framework. If a containerized process requests a prohibited capability (such as `CAP_SYS_ADMIN`), the probe returns `-EACCES` inline, aborting the capability evaluation synchronously before the syscall proceeds. ```c // GOOD: Synchronous eBPF LSM enforcement intercepting kernel capabilities before grant #include "vmlinux.h" #include <bpf/bpf_helpers.h> #include <bpf/bpf_core_read.h> #define EACCES 13 #define CAP_SYS_ADMIN 21 struct { __uint(type, BPF_MAP_TYPE_HASH); __uint(max_entries, 10240); __type(key, u64); /* cgroup_id */ __type(value, u32); /* denied capability bitmask */ } container_policy_map SEC(".maps"); SEC("lsm/capable") int BPF_PROG(restrict_container_capable, const struct cred *cred, struct user_namespace *ns, int cap, unsigned int opts, int ret) { // If kernel has already denied it, bubble up original error if (ret != 0) return ret; u64 cgroup_id = bpf_get_current_cgroup_id(); u32 *denied_caps = bpf_map_lookup_elem(&container_policy_map, &cgroup_id); // Invariant: Containerized tasks must never acquire blocked capabilities in kernel space if (denied_caps && ((*denied_caps) & (1U << cap))) { return -EACCES; } return 0; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: eBPF LSM Sandboxed Container Privilege Escalation Invariant

eBPF LSM Sandboxed Container Privilege Escalation Invariant defines an industrial-grade behavioral standard for security engineering. Enforces mandatory kernel-level verification via eBPF LSM hooks to intercept and block unauthorized container privilege escalation, namespace breakouts, and capability elevations before syscall dispatch. Prevents Time-of-Check to Time-of-Use (TOCTOU) race conditions by validating caller cgroup credentials directly inside kernel memory structures rather than relying on reactive userspace tracepoint audits. Guarantees that unprivileged container tasks cannot invoke setuid transitions or acquire ambient capabilities regardless of runtime configuration misconfigurations. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Relying on Userspace Audit Daemon Tracepoints or Async Seccomp Filters Allowing Kernel TOCTOU Container Escapes Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Relying on Userspace Audit Daemon Tracepoints or Async Seccomp Filters Allowing Kernel TOCTOU Container Escapes	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS hook synchronous LSM operations (`lsm/capable`, `lsm/cred_prepare`, `lsm/bprm_check_security`) rather than kprobes or raw tracepoints when blocking security boundary violations.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.