Hi Patrick (and security-misc maintainers),
I've been building a small tool that overlaps with security-misc's "Disable Kernel Modules" wiki page in interesting ways, and I'd value your read on whether it complements or conflicts with what you're already doing.
The tool is ModuleJail: https://github.com/jnuyens/modulejail
(POSIX /bin/sh, GPL-3.0, 793 lines, currently v1.2.2)
In one sentence: it snapshots /proc/modules on a running host, unions that with a built-in baseline and an operator-editable whitelist (in-script or in /etc/modulejail/whitelist.conf), and writes one modprobe.d-style blacklist file for every other module the running kernel ships. Currently-loaded modules are unconditionally preserved - "loaded -> keep" is the only safety invariant.
How it differs from security-misc's approach: security-misc's blacklists (30_security-misc.conf) are a curated set of known-risky modules, chosen based on attack surface analysis. ModuleJail's blacklist is computed per-host from what each kernel actually has and what's actually in use. They're complementary, not overlapping - security-misc would still blacklist its curated set even on hosts that don't currently load those modules, while ModuleJail catches the long tail of "modules this host's kernel package shipped but this workload doesn't use."
I'd specifically welcome your view on:
-
Threat-model framing in the README. I currently lean on the "AI-assisted kernel CVE discovery wave" framing; your wiki page is more measured about what kernel module surface reduction does and doesn't buy you. I'd happily fold tighter language back into the README if you see overclaim.
-
Whether the "loaded -> keep" invariant is the right safety model for Kicksecure's use cases, or whether your audience would expect a more conservative dry-run / opt-in pattern.
-
Whether this is something Kicksecure would want to ship, fold into security-misc, or simply reference from the "Disable Kernel Modules" wiki page as an external tool.
The script is a single shell file with no daemons, no initramfs involvement, no runtime deps beyond coreutils + awk + comm + sha256sum (+ optionally /usr/bin/logger for blocked-load visibility, with a byte-identical /bin/true fallback for hosts that prefer it).
Cross-distro evidence: tests/run-fixtures.sh PASS on Arch + Alpine + openSUSE in container fixtures; tests/run-ssh-hosts.sh PASS on Ubuntu 24.04 + Debian 13.4 + Rocky 9.7. Pinned-tag install:
curl -fsSL https://raw.githubusercontent.com/jnuyens/modulejail/v1.2.2/modulejail -o /tmp/modulejail
less /tmp/modulejail
sudo sh /tmp/modulejail
Happy to hear "no thanks, we already cover this," or "yes but here's what's wrong with it." Either is useful signal.
Thanks,
Jasper
Hi Patrick (and security-misc maintainers),
I've been building a small tool that overlaps with security-misc's "Disable Kernel Modules" wiki page in interesting ways, and I'd value your read on whether it complements or conflicts with what you're already doing.
The tool is ModuleJail: https://github.com/jnuyens/modulejail
(POSIX /bin/sh, GPL-3.0, 793 lines, currently v1.2.2)
In one sentence: it snapshots
/proc/moduleson a running host, unions that with a built-in baseline and an operator-editable whitelist (in-script or in/etc/modulejail/whitelist.conf), and writes one modprobe.d-style blacklist file for every other module the running kernel ships. Currently-loaded modules are unconditionally preserved - "loaded -> keep" is the only safety invariant.How it differs from security-misc's approach: security-misc's blacklists (
30_security-misc.conf) are a curated set of known-risky modules, chosen based on attack surface analysis. ModuleJail's blacklist is computed per-host from what each kernel actually has and what's actually in use. They're complementary, not overlapping - security-misc would still blacklist its curated set even on hosts that don't currently load those modules, while ModuleJail catches the long tail of "modules this host's kernel package shipped but this workload doesn't use."I'd specifically welcome your view on:
Threat-model framing in the README. I currently lean on the "AI-assisted kernel CVE discovery wave" framing; your wiki page is more measured about what kernel module surface reduction does and doesn't buy you. I'd happily fold tighter language back into the README if you see overclaim.
Whether the "loaded -> keep" invariant is the right safety model for Kicksecure's use cases, or whether your audience would expect a more conservative dry-run / opt-in pattern.
Whether this is something Kicksecure would want to ship, fold into security-misc, or simply reference from the "Disable Kernel Modules" wiki page as an external tool.
The script is a single shell file with no daemons, no initramfs involvement, no runtime deps beyond coreutils + awk + comm + sha256sum (+ optionally
/usr/bin/loggerfor blocked-load visibility, with a byte-identical/bin/truefallback for hosts that prefer it).Cross-distro evidence:
tests/run-fixtures.shPASS on Arch + Alpine + openSUSE in container fixtures;tests/run-ssh-hosts.shPASS on Ubuntu 24.04 + Debian 13.4 + Rocky 9.7. Pinned-tag install:Happy to hear "no thanks, we already cover this," or "yes but here's what's wrong with it." Either is useful signal.
Thanks,
Jasper