Disable kernel support for MISC binaries
Ensures the running kernel is built without CONFIG_BINFMT_MISC, so the system cannot register interpreters for arbitrary binary formats.
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
CONFIG_BINFMT_MISC lets the kernel run arbitrary binary formats (e.g. Java .jar, Windows .exe via Wine, foreign-arch via qemu) by registering interpreters through /proc/sys/fs/binfmt_misc. On a hardened server this adds attack surface: an attacker who can register a handler gains a stealthy way to get arbitrary files executed, and the feature has been used in privilege-escalation and persistence techniques. Disabling it (CONFIG_BINFMT_MISC unset) removes that interpreter-registration mechanism entirely.
What Pavois checks
Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r) (fallback /proc/config.gz) and asserts the line is not CONFIG_BINFMT_MISC=y. Reading the live kernel's effective config (keyed on uname -r) matches the exact booted image, more reliably than scanning a stray /boot/config-* file. Note the option can be built as a module (=m); when it is, the check passes but you should also confirm the binfmt_misc module is not loaded with lsmod.
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_BINFMT_MISC=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should_not match(/^CONFIG_BINFMT_MISC=y$/) }
endHow to verify it is applied
Run grep -h '^CONFIG_BINFMT_MISC=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep BINFMT_MISC). Expected: no =y line (either # CONFIG_BINFMT_MISC is not set or =m). Also check lsmod | grep binfmt_misc returns nothing and mount | grep binfmt_misc shows no mounted binfmt_misc filesystem.
Inspect & investigate
Static kernel build option, no runtime log. Inspect with zcat /proc/config.gz | grep BINFMT_MISC or grep BINFMT_MISC /boot/config-$(uname -r). Registered interpreters (if the feature is active) are visible under /proc/sys/fs/binfmt_misc/; ls /proc/sys/fs/binfmt_misc/ listing entries means the feature is in use.
Remediation
No automated remediation is shipped: this is a kernel compile-time option. Apply it by booting a kernel built without CONFIG_BINFMT_MISC, or rebuild the kernel. If the distribution ships it as a module, you can additionally blacklist/unload binfmt_misc at runtime. pavois harden apply cannot change the compile-time setting.
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
Risk if enabled: the system can register interpreters that auto-execute arbitrary file types, a vector for stealthy code execution and persistence.
Precautions before disabling: workloads that rely on binfmt_misc will break, notably running foreign-architecture containers via qemu-user (docker buildx, cross-arch CI), Wine, or direct execution of .jar/.py via registered handlers. Confirm none of these are in use before removing the feature. On a plain server with native binaries only, disabling has no functional impact.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R23 | 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.