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

What the HFS filesystem disabler does

This Automox Worklet™ disables the HFS kernel module on Linux endpoints so that HFS volumes can no longer mount on the host. HFS is the legacy Apple Hierarchical File System driver; on a Linux server or workstation it is almost never a load-bearing filesystem. The Worklet treats the driver as untrusted code surface, blocks it from loading at boot, and unloads it from running kernel memory in the same policy run.

The remediation script writes a single-line override into /etc/modprobe.d/hfs.conf with the directive install hfs /bin/true. That directive tells modprobe to silently run /bin/true instead of loading the hfs module, so any future modprobe hfs, autofs trigger, or USB hotplug event that asks for HFS support gets a no-op back. The script then calls rmmod hfs to evict the driver from the current kernel, closing the gap between policy application and the next reboot.

The Worklet runs on both workstation and server endpoints across any distribution that uses modprobe, including RHEL, CentOS, Rocky, Alma, Fedora, Debian, and Ubuntu. The evaluation phase is idempotent, so the same policy can be scheduled on a recurring cadence to catch endpoints where a kernel upgrade, image refresh, or admin override has removed the modprobe block.

Why disable the HFS kernel module

Every filesystem driver compiled into or loadable by a Linux kernel is parser code that runs in ring 0. Historically, rare filesystem drivers have been a productive source of kernel CVEs (CVE-2020-29371 in romfs, CVE-2021-28950 in fuse, CVE-2022-1011 also in fuse), because the parsers are old, lightly fuzzed, and reachable from any user who can plug in a USB stick or supply a crafted image. The HFS and HFS+ drivers fall into that category on Linux. Disabling them removes a class of attack reachable through removable media on shared workstations and shared lab hosts.

CIS Distribution Independent Linux v2.0.0 control 1.1.1.3 calls out HFS specifically and recommends blocking the module from loading. PCI-DSS, HIPAA, and SOC 2 audits routinely reference the CIS benchmarks as the basis for Linux hardening evidence, so a clean lsmod output and a present /etc/modprobe.d/hfs.conf are useful artifacts to capture in a control narrative.

A recurring Automox policy against your Linux server, container host, and developer workstation groups writes the hfs blacklist file to every targeted endpoint and unloads the module when it is currently loaded. Newly enrolled endpoints inherit the same blocked-module state on their first agent check-in, so CIS 1.1.1.3 evidence holds across the estate without per-host kernel inspection.

How HFS module blocking works

1. Evaluation phase: The Worklet runs modprobe -n -v hfs as a dry run to detect whether the kernel has any usable hfs configuration; if modprobe returns non-zero (HFS is not present at all), the script exits 0 as compliant. When HFS is present, the Worklet then runs lsmod | grep hfs. An empty result means the driver is not currently loaded and the endpoint is reported compliant. Any active hfs row in lsmod fails the check, the endpoint is flagged non-compliant, and remediation is scheduled.

2. Remediation phase: The remediation script touches /etc/modprobe.d/hfs.conf, writes the line install hfs /bin/true into it with a redirected echo, and calls rmmod hfs to unload the driver from running memory. The script then re-checks lsmod | grep hfs to confirm the driver is gone and exits 0 on success. If hfs is still resident after rmmod (typically because a volume is currently mounted with HFS), the policy returns exit code 1 so the failure surfaces in the Automox activity log rather than silently leaving the kernel exposed.

HFS hardening requirements

• Linux endpoint running any distribution that uses modprobe (RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, SUSE)

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

• modprobe, lsmod, and rmmod utilities present on PATH (standard on every supported Linux distribution)

• No active HFS mount on the endpoint at remediation time (rmmod cannot evict a driver that is backing a mounted filesystem)

• Both workstation and server endpoints are supported; a recurring weekly cadence is appropriate

Expected HFS-disabled state

After the Worklet runs successfully, /etc/modprobe.d/hfs.conf exists on the endpoint and contains the line install hfs /bin/true. lsmod | grep hfs returns no rows, and modprobe -n -v hfs prints install /bin/true rather than a chain of kernel module insertions. The kernel will not load HFS at boot, on USB hotplug, or in response to an autofs trigger, and an attempt to mount an HFS volume returns mount: unknown filesystem type 'hfs'.

For audit evidence, capture the contents of /etc/modprobe.d/hfs.conf, the output of modprobe -n -v hfs, and the empty lsmod | grep hfs result together with the Automox policy run identifier. Subsequent evaluation runs will keep returning an empty lsmod row for hfs and report the endpoint compliant without scheduling remediation again. The block persists across reboots and kernel upgrades because /etc/modprobe.d/ is consulted at every module load; if an administrator deletes the override file and something subsequently loads hfs into the running kernel, the next evaluation catches the regression and the Worklet rewrites the override and unloads the module.