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

What the HFS+ filesystem blocker does

This Automox Worklet™ disables HFS Plus filesystem support on Linux endpoints by neutralizing the hfsplus kernel module. The Worklet writes a modprobe override at /etc/modprobe.d/hfsplus.conf, redirects any future load attempt to /bin/true, and removes the module from the running kernel with rmmod. The endpoint can no longer mount HFS+ volumes from USB drives, disk images, or any other source.

The Worklet is idempotent. A second run on an already-remediated endpoint finds hfsplus absent from lsmod, reports compliance, and exits without touching the system. Endpoints that never had the module compiled into the kernel report compliance immediately. The configuration persists across reboots because the modprobe directive is consulted every time the kernel attempts to load hfsplus.

Map this Worklet to CIS Distribution Independent Linux Benchmark control 1.1.1.4 (Disable Mounting of hfsplus Filesystems). The control belongs to the family of filesystem-module hardening checks (1.1.1.1 cramfs, 1.1.1.2 freevxfs, 1.1.1.3 hfs, 1.1.1.4 hfsplus, 1.1.1.5 jffs2, 1.1.1.6 squashfs, 1.1.1.7 udf). Pair it with the sibling Worklets to close the full 1.1.1.x baseline in one policy group.

Why disable HFS+ filesystem support on Linux

HFS Plus is Apple's legacy filesystem. On a Linux server or workstation that has no operational reason to read Mac-formatted media, the hfsplus kernel module is a parser that runs in ring 0 against untrusted byte streams from any USB drive inserted into the endpoint. Filesystem-parsing flaws are a recurring category of Linux kernel CVE, and the rarely audited legacy filesystem drivers have a long history of out-of-bounds reads and slab-out-of-bounds writes triggered by malformed volume headers. An attacker with physical access, or a malicious peripheral plugged into a workstation, can use a crafted HFS+ image to trigger kernel-side memory corruption before any userspace control intercepts the media.

Loading kernel modules on demand is fine when the module is needed; on a Linux server farm, an engineering workstation pool, or a Kubernetes node, hfsplus is almost never needed. A weekly Automox policy against those groups blacklists hfsplus proactively, so the attack surface stays neutralized rather than waiting for the next CVE in a Mac filesystem parser to land in upstream stable and trigger an emergency patch cycle.

How hfsplus module neutralization works

1. Evaluation phase: The Worklet runs modprobe -n -v hfsplus to see whether the module exists in the current kernel's module tree. If modprobe reports the module is not available (for example, on a hardened kernel build that omitted it), the endpoint is already compliant and the script exits 0. If the module is available, the Worklet parses lsmod for an hfsplus entry. An empty lsmod result exits 0 as compliant; a populated result exits 1 and writes the non-compliance reason to stderr so the Automox console schedules remediation.

2. Remediation phase: The Worklet writes /etc/modprobe.d/hfsplus.conf containing exactly install hfsplus /bin/true. That directive tells modprobe to run /bin/true (which returns 0 immediately) instead of inserting the module, so any future modprobe hfsplus call succeeds without actually loading the kernel code. The Worklet then runs rmmod hfsplus to evict the module from the running kernel, re-checks lsmod to confirm it is gone, and exits 0 on success or non-zero with the failure reason on stderr.

HFS+ blocker requirements and parameters

• Linux endpoint with a kernel that supports modprobe.d overrides (every mainstream distribution: RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, SUSE, Oracle Linux)

• Bash available at /bin/bash for evaluation.sh and remediation.sh

• Root privileges in the agent execution context – the Automox agent runs as root by default, which is what the rmmod and /etc/modprobe.d/ write both require

• Automox Agent 1.42.22 or later

• Optional: FixNow / RunNow entitlement to remediate immediately when the policy reports an endpoint non-compliant

• No parameters – the Worklet is single-purpose and ships ready to run

Expected state after HFS+ remediation

After a successful remediation run, lsmod | grep hfsplus returns no output, and cat /etc/modprobe.d/hfsplus.conf returns the single line install hfsplus /bin/true. The endpoint reports compliant on subsequent evaluation cycles without re-running remediation. Attempting to mount a Mac-formatted volume now fails at the kernel layer: mount /dev/sdb1 /mnt/usb returns mount: unknown filesystem type 'hfsplus', and modprobe hfsplus exits 0 without inserting any code – the override has redirected the load to /bin/true.

For audit evidence, capture three artifacts after the policy run: the contents of /etc/modprobe.d/hfsplus.conf, the output of lsmod | grep hfsplus (empty line), and the Automox activity log entry for the policy. Map them to CIS control 1.1.1.4 in the audit workbook. The change reverses only by deleting /etc/modprobe.d/hfsplus.conf and rebooting (or running depmod -a then modprobe hfsplus); at that point grep -r 'install hfsplus' /etc/modprobe.d returns no rows on the next evaluation, and the remediation phase recreates the override file before the host mounts another HFS+ volume.