Sysadmin Creates 'ModuleJail' To Automatically Blacklist Unused Kernel Modules (github.com) 14
Long-time Slashdot reader internet-redstar shares an interestging response to "the recent wave of Linux kernel privilege escalation vulnerabilities like 'Copy Fail' and 'Dirty Frag'":
Belgian Linux sysadmin and Tesla Hacker "Jasper Nuyens" got tired of the idea of manually blacklisting dozens or even hundreds of obscure kernel modules across large fleets of Linux systems in the near future.
So he wrote ModuleJail, a GPLv3 shell script that scans a running Linux system and automatically blacklists currently unused kernel modules, reducing kernel attack surface without requiring a reboot. The idea is simple: many modern Linux privilege escalation bugs target obscure or rarely used kernel functionality that is still enabled by default on servers that do not actually need it. ModuleJail works across major distributions including Debian, Ubuntu, RHEL, Fedora, AlmaLinux and Arch Linux, generating 1 modprobe blacklist rules file while preserving commonly-used modules.
Nuyens argues that the increasing speed of AI-assisted vulnerability discovery will likely turn kernel hardening and attack surface reduction into a much bigger operational priority for sysadmins over the next few weeks and months.
Nuyens argues that the increasing speed of AI-assisted vulnerability discovery will likely turn kernel hardening and attack surface reduction into a much bigger operational priority for sysadmins over the next few weeks and months.
Old times (Score:3)
Remember the old times when kernel modules were considered a security risk, thus disabled altogether?
When OpenBSD was boasting its monolithic kernel as a security features?
IIRC, some commercial *nix OSs didn't had modules for reasons of being archaic fossils. But then more recently, couple decades later, also rebranded it into a safety and a security feature.
Re: (Score:3)
Remember the old times when kernel modules were considered a security risk, thus disabled altogether?
I remember those times. It was a time of compiling everything into the kernel so you couldn't disable them even if you wanted to (without passing boot time parameters)
Modules aren't a security risk. Code is a security risk.
Re: (Score:2)
Modules aren't a security risk. Code is a security risk.
So do you or do you not understand that allowing tons of obscure code to be loaded dynamically (hint: modules) that you certainly don't need or want is a security risk? Meaning TFA solution, which addresses modeules, is a good methodology for many systems, especially servers?
Re: (Score:2)
Great idea. (Score:4, Interesting)
I followed something similar in philosophy when I was supporting a mammoth critical legacy system. Not quite as automated, of course. I had sat down with the clients to go over the module list to see what we could deprecate. Turns out they thought nothing was okay to remove. Two years later I embarked on a strategy.
- Identified a series of modules and functions I thought were disused
- Installed logging to identify access and usage, and monitored it for a period
- Turned stuff off and waited for somebody to complain
I retired over a hundred pieces of the app. One time, six months later, the phone rang. I said, "We can turn it back on if you need it."
"Hold on, I'll call you back."
They never called back. :)
Re: (Score:2)
By philosophy I meant thematic alignment rather than identical implementation. Perhaps I misused the term.
Do these modules get loaded unnecessarily? (Score:2)
In my own systems, I've just compiled my own kernel, but obviously you can't do that if you have a huge farm of devices to support.
Anyway, I have always thought that the whole point of a modular kernel for typical Linux distributions is that if your hardware or software configuration does not need a particular model, it is not loaded. If there's some piece of software (e.g. Virtualbox) that needs kernel-level access, those do get loaded as part of the software installation. Same for most package-managed sof
Re: (Score:3)
Unnecessary modules take up memory. That doesn't matter much on a system with 16GB RAM, but it does for an embedded device.
The vulnerability discussed in the article proves modules that aren't needed are best left out - otherwise the vulnerability would be present and active in every Linux machine in the world.
Modules can be loaded on demand, for instance when a "file" in /dev is read. These files are accessible to anyone - even if you don't have permission to read them, just attempting to do so can load th
Re: (Score:2)
Unnecessary modules take up memory. That doesn't matter much on a system with 16GB RAM, but it does for an embedded device.
Then they shouldn't be loaded by default. Linux is not Windows. We don't have a one OS fits all approach. You should not be using the same distribution for a small embedded system as you do for a full blown desktop or high end server. It's perfectly reasonable to expect consistently used modules to be compiled in the kernel for one system while using a different kernel without them for another. That's the whole point of the cusomisability of the Linux kernel in the first place.
The AC does have a point. If a
Re: As far as I'm concerned (Score:2)
sounds like a good idea (Score:2)