← All rules
SOCLE-CLD-SYS-019// Kernel & network (sysctl)mediumeffective runtime

Disable Access to Network bpf() Syscall From Unprivileged Processes

Sets kernel.unprivileged_bpf_disabled = 1 so the bpf() syscall is restricted to privileged processes.

Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 2 standards

Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.

A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.

Why this rule matters

Loading and accessing packet-filter programs and maps via the bpf() syscall can leak sensitive information about kernel state, and the in-kernel eBPF subsystem has been a recurring source of privilege-escalation vulnerabilities. Exposing bpf() to unprivileged processes greatly widens the kernel attack surface. Setting kernel.unprivileged_bpf_disabled = 1 restricts bpf() to privileged (CAP_BPF/CAP_SYS_ADMIN) processes.

What Pavois checks

Pavois reads the live kernel value with kernel_parameter('kernel.unprivileged_bpf_disabled') (equivalent to sysctl kernel.unprivileged_bpf_disabled), not a /etc/sysctl.d/*.conf line. Defaults vary by distribution and kernel build, and this value can be locked (2) once set; only reading the effective parameter reveals what unprivileged processes are actually permitted to do right now. A config file that was never applied or was overridden by a drop-in would mislead a file-based scanner.

describe kernel_parameter('kernel.unprivileged_bpf_disabled') do
  its('value') { should cmp >= 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.unprivileged_bpf_disabled[[:space:]]*=[[:space:]]*[12]([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

How to verify it is applied

Run sysctl kernel.unprivileged_bpf_disabled. Expected output (1, or 2 if locked):

kernel.unprivileged_bpf_disabled = 1

Inspect & investigate

No dedicated log line. Confirm with sysctl kernel.unprivileged_bpf_disabled. The effect is observable: an unprivileged process calling bpf() receives EPERM, and tools relying on it (e.g. unprivileged bpftrace) will fail with a permission error.

Remediation

Pavois's harden plan uses the sysctl resource to set kernel.unprivileged_bpf_disabled = 1, persists it in a Pavois-managed drop-in under /etc/sysctl.d/, and applies it live (no reboot). Apply it with pavois harden apply.

Pavois applies this with its own harden engine, the plan below, not a shell script:

keykernel.unprivileged_bpf_disabled
resourcesysctl
value1
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Risk if not applied: unprivileged processes can use bpf(), exposing kernel state and a historically vulnerable subsystem that has enabled local privilege escalation.

Precautions before applying:

  • This breaks unprivileged eBPF. Observability/security agents (Cilium, Falco, Pixie, bpftrace) or sandboxes that load eBPF without root will need CAP_BPF/CAP_SYS_ADMIN, or must run privileged. Inventory eBPF-using tooling before enforcing.
  • Note that once set to 1, the kernel may not allow lowering it back to 0 until reboot (and 2 is a hard lock). No boot or login lockout risk otherwise.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R9direct2.0high
NISTAC-6, SC-7(10)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium

Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.

Sources & references