Linux - System Preferences - Disable USB Storage

What the Linux USB storage disabler does

This Automox Worklet™ disables the usb-storage kernel module on Linux endpoints so USB mass storage devices stop mounting. The Worklet first uses lsmod to detect whether the running kernel has usb-storage or usb_storage loaded. When the module is loaded, the endpoint is flagged for remediation and the policy moves the host back into a compliant state.

Remediation writes a modprobe configuration file to /etc/modprobe.d/ax-usb-storage.conf containing the line install usb-storage /bin/true. That single directive redirects every future load attempt for the usb-storage module to /bin/true, which exits 0 without loading any code. The Worklet then runs rmmod usb-storage to unload the module from the running kernel so the change takes effect immediately, not just at the next reboot.

Before writing the new rule, the script sweeps /etc/modprobe.d/ for any existing files that reference usb-storage or usb_storage and strips the conflicting lines with sed. The configuration filename is parameterized through the module_config_file_name input, defaulting to ax-usb-storage.conf so the Automox-managed rule is easy to spot in an audit. A revert path in the same remediation script removes the blocking file and runs modprobe usb-storage when an administrator needs to temporarily re-enable removable media on a specific endpoint.

Why disable the usb-storage module on Linux endpoints

Unrestricted USB mass storage is the shortest path past every network-layer control your security team has built. A thumb drive copies sensitive files in seconds without crossing the DLP egress filter, and a malicious USB device handed to a user can deliver a payload directly into the kernel without an inbound port being opened. CIS Distribution Independent Linux Benchmark v2.0.0 calls this out explicitly in control 1.1.x, which requires the usb-storage module to be disabled on systems that do not have a documented business need for removable storage. Auditors checking PCI-DSS 9.5, HIPAA §164.310(d)(1), and SOC 2 CC6.7 will ask for the same evidence: a kernel-level block, persistent across reboots, with a named configuration file they can fingerprint.

This Worklet writes install usb-storage /bin/true to /etc/modprobe.d/ax-usb-storage.conf on every Linux endpoint in scope, then runs rmmod usb-storage to unload any already-loaded instance of the driver. RHEL, Rocky, Alma, Debian, and Ubuntu hosts all receive the same modprobe rule, and a workstation reimaged from a stale gold image re-converges on the next evaluation. The auditor's evidence is a named configuration file with a deterministic path and content rather than a sampled inventory of /sys/module.

How the usb-storage block works

1. Evaluation phase: The evaluation script runs lsmod | grep -q -E 'usb-storage|usb_storage' to check whether the usb-storage kernel module is currently resident in the running kernel. If the regex matches, the script exits 1 with a stderr message and the endpoint is flagged for remediation. If the module is not loaded, it exits 0 and the endpoint is reported compliant without further action.

2. Remediation phase: The remediation script reads the module_config_file_name parameter, scrubs any existing usb-storage or usb_storage references from files in /etc/modprobe.d/, and writes install usb-storage /bin/true to /etc/modprobe.d/ax-usb-storage.conf. It then runs rmmod usb-storage to unload the active module and re-checks lsmod. The script exits 0 when the module is gone, or exits 1 with a message in stderr if the rule could not be written or the module refuses to unload.

Requirements to block usb-storage

• Linux endpoint with a modular kernel that supports modprobe configuration under /etc/modprobe.d/ (RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, and SUSE variants all qualify)

• Root or sudo privileges so the Automox agent can write to /etc/modprobe.d/ and call rmmod on the running kernel

• Optional: set the module_config_file_name input to a custom filename when an internal naming standard requires it; the default ax-usb-storage.conf is recommended so the file is identifiable in audit evidence

• Optional: set revert=true in the remediation script when an administrator needs to temporarily re-enable usb-storage on a single endpoint without removing the Worklet from the policy

• Confirm no production workflow depends on USB mass storage (engineering bench imaging, kiosk media ingest, backup-to-USB processes) before scheduling the policy fleet-wide

Expected state after the usb-storage block

On a remediated endpoint, /etc/modprobe.d/ax-usb-storage.conf exists and contains the single line install usb-storage /bin/true. Running lsmod | grep usb-storage returns no output, and inserting a thumb drive into a USB port produces no /dev/sd* node, no entry in dmesg beyond the controller-level enumeration, and no mount target in /media or /run/media. The configuration file survives a reboot, so the next time the kernel attempts to autoload usb-storage in response to a hot-plug event the modprobe rule short-circuits to /bin/true and the module never enters the kernel.

Validate the policy run by capturing three pieces of evidence on a pilot endpoint. First, cat /etc/modprobe.d/ax-usb-storage.conf to confirm the rule. Second, lsmod | grep usb-storage to confirm no loaded module. Third, plug in a known-good USB stick and check dmesg | tail and lsblk; the device should enumerate at the USB controller layer but never produce a block device. For audit packets, attach the contents of the modprobe file along with the Automox activity log entry showing exit code 0 from the remediation run. The endpoint stays in this state across reboots and kernel updates until an administrator deletes the configuration file or runs the Worklet with revert=true.