ModuleJail Blocks Unused Linux Kernel Modules to Limit Attack Surface

ModuleJail is a new project that blacklists unused Linux kernel modules, helping reduce the attack surface exposed by recent local privilege escalation flaws.

After three critical Linux kernel vulnerabilities, Copy Fail, Dirty Frag, and Fragnesia, were reported in just two weeks, the Linux community began looking for ways to address the problem.

One proposed solution was Kernel Killswitch, and now a similar idea has emerged: ModuleJail – a Linux hardening project that blacklists unused kernel modules to reduce the attack surface from recent local privilege escalation flaws.

ModuleJail is implemented as a single POSIX shell script. It scans currently loaded modules, compares them to the full module tree under /lib/modules/$(uname -r), and creates a modprobe.d blacklist for unused modules. By default, the blacklist is saved at /etc/modprobe.d/modulejail-blacklist.conf.

In fact, most Linux systems include thousands of kernel modules, but use only a small subset. If an unused module contains a privilege escalation flaw, the system remains at risk if the module can be loaded later. ModuleJail addresses this by preventing unused modules from being autoloaded.

It is important to understand that ModuleJail does not patch these vulnerabilities or detect vulnerable modules. Instead, it takes a broader defensive approach by limiting access to unnecessary kernel functionality.

According to the documentation, ModuleJail preserves modules already loaded on the host, a built-in baseline of essential modules, and any modules specified in an optional sysadmin whitelist. All other modules are blacklisted using install <module> /bin/true directives in a modprobe.d-compatible file.

ModuleJail is intended as a one-time hardening tool, not a background service. It does not include a daemon, continuous monitoring, CVE database lookup, module risk scoring, or AI features. Its approach relies solely on whether a module is currently loaded on a known-good system.

This safety model also defines its main limitation. ModuleJail should be run only after the system reaches a steady state, with all services started, filesystems mounted, and required drivers loaded. Running it too early may blacklist modules needed later, potentially disrupting hardware, storage, networking, or application functionality.

ModuleJail offers three baseline profiles. The default conservative profile is intended for virtualized or bare-metal servers. The desktop profile preserves additional Wi-Fi, Bluetooth, audio, and video drivers for laptops and workstations. The minimal profile retains only core filesystems and essential kernel modules.

Admins can edit a site-local whitelist within the script to preserve specific modules, regardless of whether they are loaded when ModuleJail runs. This is useful for modules needed occasionally or under specific operational conditions.

According to devs, the tool has been tested on Ubuntu 24.04 LTS, Debian 13.4, and Rocky Linux 9.7 using live hosts, with additional container-based tests for Arch Linux, Alpine Linux, and openSUSE Tumbleweed. Prebuilt DEB and RPM packages are available for Debian/Ubuntu and RHEL/Fedora/Alma/Rocky systems.

However, reverting changes is an entirely manual process. Admins can remove /etc/modprobe.d/modulejail-blacklist.conf and reboot, or reload individual modules with modprobe for the current session. The blacklist will reapply after reboot unless the file is deleted.

For more details, see the project’s GitHub page.

Bobby Borisov

Bobby Borisov

Bobby, an editor-in-chief at Linuxiac, is a Linux professional with over 20 years of experience. With a strong focus on Linux and open-source software, he has worked as a Senior Linux System Administrator, Software Developer, and DevOps Engineer for small and large multinational companies.

Leave a Reply

Your email address will not be published. Required fields are marked *