Linux - System Preferences - Ensure Mounting of Squashfs Filesystems is Disabled

What the squashfs kernel module blocker does

This Automox Worklet™ blocks the squashfs kernel module on Linux endpoints so the kernel cannot mount squashfs filesystems on demand. Squashfs is a compressed read-only filesystem widely used by live boot media, embedded images, and snap packages. On a standard server or hardened workstation where snap is not deployed, the loaded module is a kernel-attack surface with no operational return.

The Worklet writes /etc/modprobe.d/squashfs.conf with the directive install squashfs /bin/true, which tells modprobe to run /bin/true instead of loading the real module. Any subsequent mount -t squashfs call or auto-mount trigger then fails because the kernel cannot resolve a squashfs handler. The Worklet also runs rmmod squashfs to clear an already-loaded instance from memory, so the policy takes effect on the current boot rather than waiting for a reboot.

Note: squashfs is required by snap. If the endpoint relies on snap-installed packages (Ubuntu desktop, snapd-managed tools), do not target it with this Worklet. The remediation will not break already-mounted snaps until reboot, but new snap installs and refreshes will fail. Use the policy scope to limit this control to servers and CIS-hardened workstations.

Why block squashfs on hardened Linux endpoints

The squashfs driver is one of several auxiliary filesystem modules that the kernel will autoload when a matching superblock is presented. CIS Distribution Independent Linux benchmark control 1.1.1.6 calls this out alongside cramfs, freevxfs, jffs2, hfs, hfsplus, and udf because each module is a relatively low-traffic codepath inside a privileged context. A malicious USB image, a crafted disk image dropped through SSH, or an attacker with limited filesystem access can trigger autoload and reach kernel parsing code that has historically carried mount-time CVEs (CVE-2022-0185 in the legacy filesystem-mount path is one canonical reminder). Removing the module from the available set removes the reachability.

A weekly Automox policy against your Linux server, container host, and workstation groups holds the squashfs blacklist in place across the RHEL, CentOS, Rocky, Alma, Debian, and Ubuntu estate. Newly enrolled endpoints inherit the same hardened state on their first agent check-in, so CIS control 1.1.1.6 evidence stays consistent without admin intervention against each host. Endpoints where squashfs is required for legitimate AppImage or snap workflows should be excluded from the target group rather than left in drift.

How squashfs blocking works

1. Evaluation phase: The Worklet runs modprobe -n -v squashfs to confirm the kernel knows about the module. If that command fails, squashfs is not available on the endpoint and the script exits 0 with a no-changes-required message. If the module is known, the Worklet runs lsmod | grep squashfs to check whether it is currently loaded. An empty result means the endpoint is compliant and the script exits 0. A matching row means the module is live in the running kernel, and the script exits 1 to the stderr channel so Automox schedules remediation.

2. Remediation phase: The remediation script repeats the modprobe and lsmod checks, then calls a disable_squashfs function that touches /etc/modprobe.d/squashfs.conf and writes the single line install squashfs /bin/true into it. The function then runs rmmod squashfs to drop the active module from memory. A final lsmod | grep squashfs verifies the module is no longer loaded; if it is gone the script exits 0, and if the module is still resident (for example because a squashfs mount is in use) the script exits 1 and surfaces the failure in the Automox activity log.

Squashfs blocking requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Debian, or Ubuntu (server or hardened workstation; do not target Ubuntu desktops that depend on snap)

• Root or sudo for the Automox agent (the default agent context already meets this)

• /etc/modprobe.d/ writable on the root filesystem (the script will fail fast on read-only roots)

• Standard kernel-module utilities present in PATH: modprobe, lsmod, rmmod

• Bash shell environment and Automox agent 1.42.22 or later

• Confirm snap is not in use on the target endpoint (snap list returns empty or the command is absent) before scheduling the policy

Expected state after squashfs is blocked

After remediation, /etc/modprobe.d/squashfs.conf exists with the single line install squashfs /bin/true. Running modprobe -n -v squashfs prints install /bin/true, which is the canonical signal that the override is wired up correctly. lsmod | grep squashfs returns nothing, and attempting mount -t squashfs /path/to/image.squashfs /mnt fails with mount: unknown filesystem type 'squashfs'. The configuration persists across reboots because modprobe reads /etc/modprobe.d/ on every kernel module load.

For audit evidence, capture three artifacts from the endpoint after the next evaluation run: the contents of /etc/modprobe.d/squashfs.conf, the output of modprobe -n -v squashfs, and the output of lsmod | grep -E '^squashfs'. Store them with the Automox policy run identifier; together they document compliance with CIS Distribution Independent Linux control 1.1.1.6. The Worklet is idempotent, so subsequent runs against an already-hardened endpoint exit 0 in the evaluation phase and do not touch the filesystem.