Enable seccomp to safely compute untrusted bytecode
Requires the kernel to be built with CONFIG_SECCOMP=y, the base support that enables seccomp syscall confinement.
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.
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
seccomp enables the ability to filter system calls made by an application, effectively isolating the system's resources from it. CONFIG_SECCOMP is the base switch on which seccomp-bpf (CONFIG_SECCOMP_FILTER) builds; without it a process cannot restrict which syscalls it may issue, so a compromised or sandboxed program retains the full kernel interface and a much larger path to privilege escalation or container escape.
What Pavois checks
Pavois reads the build options of the running kernel, grep '^CONFIG_SECCOMP=' /boot/config-$(uname -r) or zcat /proc/config.gz, and requires y. Reading the live kernel's own config (keyed on uname -r) reflects exactly the booted kernel, which a package-name guess or generic file cannot.
describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_SECCOMP=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_SECCOMP=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_SECCOMP=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep CONFIG_SECCOMP). Expected output:
CONFIG_SECCOMP=y
Runtime support is also visible as a Seccomp: line in grep Seccomp /proc/self/status.
Inspect & investigate
No routine log entry. Seccomp denials (when a filter is in log/kill mode) appear in /var/log/audit/audit.log (type=SECCOMP) and in dmesg / journalctl -k. Confirm the build flag with grep CONFIG_SECCOMP /boot/config-$(uname -r).
Remediation
This is a kernel build-time option, so Pavois ships no automated harden step for it. It is satisfied by booting a distribution kernel compiled with CONFIG_SECCOMP=y (true for all current Debian/Ubuntu/RHEL kernels, required by container and systemd sandboxing); a custom kernel must be rebuilt.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | kernel_build |
|---|
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If absent, no process can restrict its syscalls, so seccomp profiles in Docker/Podman/systemd are silently ineffective and sandboxes are far weaker. Precautions: this is an enabling capability, not an active restriction, so turning it on (via a compliant kernel) cannot break existing software. Leaving it off is the real risk. No lockout concern beyond the normal kernel switch.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R20 | direct | 2.0 | high |
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.