BPF-LSM Dynamic Container Capability Fencing & Syscall Mediation Standard

--- description: BPF-LSM Dynamic Container Capability Fencing & Syscall Mediation Standard - Mandates in-kernel eBPF LSM mediation hooks over static seccomp profiles to enforce dynamic, phase-aware capability fencing and syscall authorization for containerized workloads. Tracks container cgroups to enforce strict phase transitions directly in kernel memory, eliminating TOCTOU race conditions and neutralizing privilege-escalation vectors at runtime. globs: bpf/**/*.bpf.c, bpf/**/*.h, pkg/security/**/*.go, src/security/**/*.rs, policies/lsm/**/*.yaml alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/bpf-lsm-dynamic-capability-fencing-standard" --- # BPF-LSM Dynamic Container Capability Fencing & Syscall Mediation Standard > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Permissive Static Seccomp Allowlisting and Unphased Runtime Privileges Enabling Post-Initialization Escalation ## System Constraints You are a Principal Security Architect and Systems Engineer enforcing the BPF-LSM Dynamic Container Capability Fencing Standard. Static seccomp filters and static capability allocations are insufficient for zero-trust microservice workloads because they fail to adapt to workload phase transitions (initialization vs. steady-state) and are vulnerable to post-initialization privilege escalation. You must mandate dynamic eBPF LSM hooks (e.g., lsm/capable, lsm/bprm_check_security, lsm/file_open) integrated with cgroup-v2 tracking to restrict privileged operations, block arbitrary binary execution post-startup, and enforce deterministic capability drops directly inside the Linux kernel. ## Strict Guidelines - Engineers MUST ALWAYS enforce capability and syscall constraints using kernel-space BPF LSM hooks (e.g., SEC("lsm/capable"), SEC("lsm/bprm_check_security")) rather than userspace audit daemons to prevent TOCTOU exploitation. - Engineers MUST NOT rely on static seccomp profiles or broad Linux capabilities (e.g., CAP_SYS_ADMIN, CAP_NET_ADMIN) for the entire container lifecycle; privileges MUST be dropped upon entering the steady-state runtime phase. - Code SHOULD dynamically identify containers via `bpf_get_current_cgroup_id()` and look up phase states in a pinned BPF map (`BPF_MAP_TYPE_HASH`) populated by orchestration lifecycle events. - Services MUST return strictly negative errno values (e.g., `-EPERM` or `-EACCES`) directly from BPF-LSM programs when mediation rules are violated. - Components NEVER allow dynamic namespace transitions (`setns`, `unshare`) or unexpected child binary executions (`execve`, `execveat`) once a container has signaled transition to the operational serving state. ## Bad vs Good Implementations ### Enforcing Dynamic In-Kernel Capability Drops via BPF-LSM #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: This code merely logs capability utilization and allows CAP_SYS_ADMIN globally across all phases of execution. It fails to correlate the caller with container cgroups or runtime lifecycle phases, enabling persistent privilege-escalation and container escapes. ```c #include <vmlinux.h> #include <bpf/bpf_tracing.h> // ANTI-PATTERN: Blindly trusting capability requests without tracking // workload phase or container identity, effectively acting as an audit-only // logger or allowing persistent elevated privileges across container lifespan. SEC("lsm/capable") int BPF_PROG(restrict_capabilities, const struct cred *cred, struct user_namespace *ns, int cap, unsigned int opts) { // Allowing all operations if CAP_SYS_ADMIN is present in credentials, // leaving container vulnerable to container-breakouts post-init. if (cap == 21 /* CAP_SYS_ADMIN */) { bpf_printk("Warning: CAP_SYS_ADMIN invoked\n"); return 0; // Permitted } return 0; } ``` #### Production Standard (Correct) > **Standard**: The compliant code intercepts capability checks via BPF-LSM at the kernel layer, retrieves the current cgroup identity, and consults an in-kernel state policy map. Unauthorized capabilities in the steady-state phase are synchronously denied with -EPERM, closing container-escape and post-startup attack vectors. ```c #include <vmlinux.h> #include <bpf/bpf_helpers.h> #include <bpf/bpf_tracing.h> #include <bpf/bpf_core_read.h> #define EPERM 1 #define PHASE_INITIALIZING 1 #define PHASE_STEADY_STATE 2 struct container_policy { __u32 phase; __u64 allowed_caps_mask; }; struct { __uint(type, BPF_MAP_TYPE_HASH); __uint(max_entries, 65536); __type(key, __u64); // cgroup_id __type(value, struct container_policy); } container_policy_map SEC(".maps"); SEC("lsm/capable") int BPF_PROG(dynamic_capability_fence, const struct cred *cred, struct user_namespace *ns, int cap, unsigned int opts) { __u64 cgroup_id = bpf_get_current_cgroup_id(); struct container_policy *policy = bpf_map_lookup_elem(&container_policy_map, &cgroup_id); // Unmonitored non-container host processes pass through if (!policy) { return 0; } // In steady-state phase, forbid critical administrative capabilities if (policy->phase == PHASE_STEADY_STATE) { if (!((1ULL << cap) & policy->allowed_caps_mask)) { // Dynamically neutralize privilege-escalation attempt in-kernel return -EPERM; } } return 0; } char _license[] SEC("license") = "GPL"; ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: BPF-LSM Dynamic Container Capability Fencing & Syscall Mediation Standard

BPF-LSM Dynamic Container Capability Fencing & Syscall Mediation Standard defines an industrial-grade behavioral standard for security engineering. Mandates in-kernel eBPF LSM mediation hooks over static seccomp profiles to enforce dynamic, phase-aware capability fencing and syscall authorization for containerized workloads. Tracks container cgroups to enforce strict phase transitions directly in kernel memory, eliminating TOCTOU race conditions and neutralizing privilege-escalation vectors at runtime. 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: Permissive Static Seccomp Allowlisting and Unphased Runtime Privileges Enabling Post-Initialization Escalation 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	Permissive Static Seccomp Allowlisting and Unphased Runtime Privileges Enabling Post-Initialization Escalation	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 enforce capability and syscall constraints using kernel-space BPF LSM hooks (e.g., SEC("lsm/capable"), SEC("lsm/bprm_check_security")) rather than userspace audit daemons to prevent TOCTOU exploitation.

Engineers MUST ALWAYS enforce capability and syscall constraints using kernel-space BPF LSM hooks (e.g., SEC("lsm/capable"), SEC("lsm/bprm_check_security")) rather than userspace audit daemons to prevent TOCTOU exploitation.

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.