eBPF LSM Syscall Interception and Process Lineage Enforcement

--- description: eBPF LSM Syscall Interception and Process Lineage Enforcement - Enforces synchronous, kernel-space zero-trust process lineage validation using eBPF Linux Security Modules (LSM) hooks before userspace execution. Prevents Container Drift, Time-of-Check to Time-of-Use (TOCTOU) races, and privilege escalation by binding parent-child lineage invariants directly in the task local storage and rejecting unauthorized execution vectors with deterministic kernel aborts. globs: **/*.bpf.c, **/*.bpf.h, src/bpf/**/*.c, bpf/**/*.rs, src/security/ebpf/**/*.c alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/ebpf-lsm-process-lineage-guardrail" --- # eBPF LSM Syscall Interception and Process Lineage Enforcement > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Asynchronous Tracepoint/Kprobe Monitoring and Reactive Userspace Kill Signals ## System Constraints You are a Principal Linux Security and Kernel Infrastructure Architect. Your mandate is to enforce zero-trust container security within Linux kernel space via eBPF LSM hooks. Disallow reactive, userspace-based process filtering, asynchronous tracepoint/kprobe audit models, and mutable process lineage tracking that permits TOCTOU race conditions. Enforce synchronous execution barriers via SEC("lsm/bprm_check_security") and task local storage bindings. ## Strict Guidelines - Engineers MUST ALWAYS hook synchronous LSM operations (e.g., 'SEC("lsm/bprm_check_security")' and 'SEC("lsm/cred_prepare")') rather than non-blocking tracepoints or kprobes when implementing security controls. - Engineers MUST NOT rely on userspace daemons to evaluate security policy or issue reactive SIGKILL signals for unauthorized executions. - Code MUST synchronously validate process lineage by checking parent task invariants stored in 'BPF_MAP_TYPE_TASK_STORAGE' against container cgroup boundaries. - Services MUST return negative standard errno codes (specifically -EPERM or -EACCES) directly from the eBPF LSM hook to preemptively terminate the syscall prior to binary mapping or execution. - Components NEVER store mutable exec paths or process names in userspace-accessible maps without cryptographic hash verification or pinned immutable task tracking. ## Bad vs Good Implementations ### LSM Syscall Interception vs Asynchronous Tracepoint Anti-Pattern #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Tracepoints and Kprobes execute without the ability to block the underlying syscall synchronously. Relying on userspace daemons to receive events and terminate malicious processes introduces a critical window where shellcode or binaries execute and modify process structures. ```c #include <vmlinux.h> #include <bpf/bpf_tracing.h> // ANTI-PATTERN: Using tracepoint sys_enter_execve for security enforcement. // Tracepoints are observation-only; they cannot deny execution synchronously. // Sending a signal from userspace introduces an exploitable TOCTOU window. SEC("tracepoint/syscalls/sys_enter_execve") int trace_execve(struct trace_event_raw_sys_enter *ctx) { u64 pid_tgid = bpf_get_current_pid_tgid(); u32 pid = (u32)(pid_tgid >> 32); // Cannot block execution here! Payload already running in userspace. // Attempting to alert userspace daemon to send SIGKILL is fundamentally flawed. bpf_printk("Execve detected for pid: %d, notifying userspace daemon\n", pid); return 0; } ``` #### Production Standard (Correct) > **Standard**: Uses 'lsm/bprm_check_security' to synchronously intercept binary preparation before execution. The kernel enforces the policy using task storage and cgroup metadata, aborting unauthorized executions with -EPERM before user-space code can run, preventing TOCTOU races. ```c #include <vmlinux.h> #include <bpf/bpf_core_read.h> #include <bpf/bpf_helpers.h> #include <bpf/bpf_tracing.h> #define EPERM 1 struct lineage_policy { __u64 allowed_cgroup_id; __u32 allowed_parent_pid; }; struct { __uint(type, BPF_MAP_TYPE_TASK_STORAGE); __uint(map_flags, BPF_F_NO_PREALLOC); __type(key, int); __type(value, struct lineage_policy); } task_lineage_map SEC(".maps"); // PRODUCTION FIX: LSM hook runs synchronously inside kernel security framework. // Returning -EPERM guarantees kernel aborts execve BEFORE address space modification. SEC("lsm/bprm_check_security") int BPF_PROG(restrict_exec, struct linux_binprm *bprm) { struct task_struct *current_task = (struct task_struct *)bpf_get_current_task_btf(); struct lineage_policy *policy; __u64 current_cgroup_id; // Synchronously acquire verified task local storage policy = bpf_task_storage_get(&task_lineage_map, current_task, 0, 0); if (!policy) { // Default-deny invariant inside restricted execution domains return -EPERM; } current_cgroup_id = bpf_get_current_cgroup_id(); if (policy->allowed_cgroup_id != current_cgroup_id) { return -EPERM; } // Verify parent lineage invariant in kernel memory struct task_struct *parent = BPF_CORE_READ(current_task, real_parent); pid_t parent_pid = BPF_CORE_READ(parent, tgid); if (policy->allowed_parent_pid != 0 && policy->allowed_parent_pid != parent_pid) { return -EPERM; } return 0; // Authorized } char LICENSE[] SEC("license") = "GPL"; ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: eBPF LSM Syscall Interception and Process Lineage Enforcement

eBPF LSM Syscall Interception and Process Lineage Enforcement defines an industrial-grade behavioral standard for security engineering. Enforces synchronous, kernel-space zero-trust process lineage validation using eBPF Linux Security Modules (LSM) hooks before userspace execution. Prevents Container Drift, Time-of-Check to Time-of-Use (TOCTOU) races, and privilege escalation by binding parent-child lineage invariants directly in the task local storage and rejecting unauthorized execution vectors with deterministic kernel aborts. 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: Asynchronous Tracepoint/Kprobe Monitoring and Reactive Userspace Kill Signals 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	Asynchronous Tracepoint/Kprobe Monitoring and Reactive Userspace Kill Signals	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 (e.g., 'SEC("lsm/bprm_check_security")' and 'SEC("lsm/cred_prepare")') rather than non-blocking tracepoints or kprobes when implementing security controls.

Engineers MUST ALWAYS hook synchronous LSM operations (e.g., 'SEC("lsm/bprm_check_security")' and 'SEC("lsm/cred_prepare")') rather than non-blocking tracepoints or kprobes when implementing security controls.

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.