← All rules
SOCLE-CLD-MOD-016// Kernel modulesloweffective runtime

Ensure overlayfs kernel module is not available

Ensures the overlay/overlayfs kernel module cannot be loaded, removing the overlay filesystem on hosts that do not run containers.

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 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

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

The overlay/overlayfs filesystem has a history of known CVEs, several allowing local privilege escalation through mishandling of setuid files and namespace interactions. Disabling it reduces the local attack surface by removing support for an unnecessary filesystem type and mitigates unauthorized execution of setuid files. Important caveat: overlayfs is the storage backend for Docker, Podman and most container runtimes, blacklisting it will break containers, so this rule applies only to hosts that run no container workloads.

What Pavois checks

Pavois uses the InSpec kernel_module('overlayfs') resource to confirm the module is not loaded and is disabled (blacklist plus an install ... /bin/true override). This reflects the effective kernel state via lsmod and modprobe --showconfig, important here because a container runtime can autoload overlay on demand, which a static read of /etc/modprobe.d/ would miss.

describe kernel_module('overlay') do
  it { should_not be_loaded }
  it { should be_disabled }
end

How to verify it is applied

Run modprobe -n -v overlay, it should print install /bin/true. Confirm it is not loaded with lsmod | grep overlay (no output expected). modprobe --showconfig | grep overlay should show a blacklist and an install overlay /bin/true line. (The kernel module is named overlay; overlayfs is the historical alias.)

Inspect & investigate

Load attempts and overlay mount activity appear in the kernel ring buffer: dmesg | grep overlay or journalctl -k | grep overlay. The effective modprobe policy is shown by modprobe --showconfig | grep overlay; container runtime failures from a missing overlay backend surface in journalctl -u docker or journalctl -u podman.

Remediation

pavois harden apply uses the kernel_module resource to blacklist overlayfs: it writes a drop-in under /etc/modprobe.d/ with a blacklist and install overlay /bin/true line, and unloads the module if loaded. Because the module may already be active (or pinned by a running container), reboot_required is true to guarantee a clean state.

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

actionblacklist
nameoverlay
reboot_requiredtrue
resourcekernel_module
pavois harden plan local

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

Impact & precautions

Risk if not applied: a filesystem with a record of local-privesc CVEs stays loadable.

  • Critical precaution: do NOT apply on any host running Docker, Podman, Kubernetes nodes, LXC/LXD or any container runtime, overlayfs is their default storage driver and blacklisting it will prevent containers from starting.
  • Apply only to bare, non-container hosts; confirm with docker info / podman info (graph driver) before proceeding.
  • A reboot is required for full effect; schedule it in a maintenance window.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS1.1.1.6directper OS, see the benchmark tablehigh

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