Do not allow ACPI methods to be inserted/replaced at run time
Ensures the running kernel is built without CONFIG_ACPI_CUSTOM_METHOD, so ACPI methods cannot be inserted or replaced at run time.
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
Enabling CONFIG_ACPI_CUSTOM_METHOD exposes /sys/kernel/debug/acpi/custom_method, which lets a root (uid=0) user write arbitrary kernel memory by redefining ACPI methods. This breaks the boundary that hardening relies on (lockdown, secure boot, signed modules): an attacker who reaches root can rewrite kernel code/data, bypass CONFIG_STRICT_KERNEL_RWX, and defeat other security measures. Disabling it removes a powerful primitive for privilege persistence and kernel tampering.
What Pavois checks
Pavois reads the build-time configuration of the kernel that is actually running, /boot/config-$(uname -r) and, as a fallback, the in-kernel /proc/config.gz. It asserts the line is not CONFIG_ACPI_CUSTOM_METHOD=y. Querying the effective config of the live kernel (keyed on uname -r) is more reliable than reading a stray config-* file in /boot: it reflects the exact image GRUB booted, even when multiple kernels are installed.
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_ACPI_CUSTOM_METHOD=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should_not match(/^CONFIG_ACPI_CUSTOM_METHOD=y$/) }
endHow to verify it is applied
Run grep -h '^CONFIG_ACPI_CUSTOM_METHOD=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep CONFIG_ACPI_CUSTOM_METHOD). Expected: either no output or # CONFIG_ACPI_CUSTOM_METHOD is not set. A line CONFIG_ACPI_CUSTOM_METHOD=y is a failure.
Inspect & investigate
There is no runtime log; this is a static kernel build option. Inspect it with zcat /proc/config.gz | grep ACPI_CUSTOM_METHOD or grep ACPI_CUSTOM_METHOD /boot/config-$(uname -r). If the option is set, the debugfs entry would appear at /sys/kernel/debug/acpi/custom_method.
Remediation
No automated remediation is shipped: this is a kernel compile-time option that cannot be toggled at run time. Apply it by booting a kernel built with CONFIG_ACPI_CUSTOM_METHOD unset, use the distribution's hardened/stock kernel that disables it, or rebuild the kernel. pavois harden apply cannot change it.
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 left enabled: a root-level attacker (or a kernel exploit that reaches root) gains a clean primitive to write arbitrary kernel memory, undermining lockdown and module-signing protections.
Precautions before changing it: switching kernels is a reboot-level operation. Verify the replacement kernel still supports your hardware's ACPI tables, keep the old kernel entry in GRUB as a fallback, and confirm boot on a console (not just SSH) before removing the previous kernel. Disabling this option has no functional impact on normal systems, only out-of-tree ACPI debugging workflows use it.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R15 | 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.