Sysadmin Creates 'ModuleJail' To Automatically Blacklist Unused Kernel Modules (github.com) 29
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)
Modules exist on an as needs basis. There's no reason to permit a module to be loaded by any ol' 3rd party, and it's trivial to lock it down so that only explicit modules are run.
The point is, modules is code. That code is either needed or is not. If you are loading modules that aren't needed or used then you have a *you* problem, not a problem with the security of modules. If modules are loaded and used then evidently their code is needed. In the past that would result in them being compiled into the kerne
Re: (Score:2)
Re: (Score:2)
If you don't understand that module loading is under the explicit control of the system administrator then you may make that comparison, yes.
Re: (Score:2)
All configuration options are under control of system administrator. Yet somehow there are still plenty of security issues caused by bad configuration.
To err is human.
Great idea. (Score:5, 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:3)
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 software (install a VPN server, you get IPSec/ESP networking modules included). So with devices, they are autodetected (load driver module when you detect hardware, including when plugged in to USB or other removable port), and with other kernel features, they are brought in when some software requires it (some might of course be there by default, like firewall). Only case where you would manually edit /etc/modprobe.d is if you manually install some software...right? Why would a kernel load every module it has come with of most of them are not even needed?
Re:Do these modules get loaded unnecessarily? (Score:4, Informative)
" Why would a kernel load every module it has come with of most of them are not even needed?"
They're not.
(By definition) Modules that are not statically linked to the kernel are dynamically loaded. They are not loaded until needed... but an exploit that "needs" them can load them in demand.
Re: (Score:3)
but obviously you can't do that if you have a huge farm of devices to support.
It depends what those devices are. In a lot of cases this "huge farm" is actually "hundreds of virtual machines running on the same hypervisor" so you absolutely can compile a custom kernel and roll it out. The memory usage vs a generic kernel will also be somewhat lower, multiplied by the number of virtual machines and you have quite decent savings.
Re:As far as I'm concerned (Score:4, Interesting)
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 the module. With so many vulnerabilities coming our way this is a brilliant and easy fix.
I hope he gets a shout-out at the next FOSDEM, which is held in Brussels. Judging by his name he won't live far away.
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.
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:4, Interesting)
Many are not loaded by default, but for example when a udev event happens. You plug in the webcam, udev finds what device class was plugged in and loads the driver. With this ModuleJail, you can't use a webcam that was not present when the whitelist of this approach was built.
Re: (Score:2)
Actually, this script supports profiles - one of which seems like a good fit for desktop Linux. From TFA:
Re: As far as I'm concerned (Score:2)
sounds like a good idea (Score:2)
Blacklist? (Score:2)
What ever has happened to depmod -a? Maybe after some "modprobe -r" for modules you don't need. Should at least do the job until the next kernel update, but until then you should have blacklisted whatever you really don't want to be loaded.
This is how 'nix tools SHOULD be written (Score:2)
I've g
It's an interesting idea (Score:3)
The script lets you supply your own whitelist, and it also offers some generic profiles that try to cover use cases like "Linux desktop". Since it generates its own separate blacklist file (/etc/modprobe.d/modulejail-blacklist.conf), it's simple enough to roll back if necessary (or you could even automate it so that file is removed on shutdown or on boot, I suppose).
Basically it seems like an easily reverted, low risk approach. I think I'll be looking into this further, for our student lab machines - during the quarter, I can't just reboot the machines whenever I want.
Kernel Module Signing (Score:3)
Removing unnecessary modules and reducing attack surface is great, but an attacker with root access could bypass this fairly easily. What you really need is Kernel Module Signing, so that you can't sideload malicious modules without a proper signature.
https://www.kernel.org/doc/htm... [kernel.org]
Re: Kernel Module Signing (Score:2)
For clarity, I meant scenarios where an attacker targets a process with root privileges, manages to execute code inside it and inheris root-level access, but then needs to load additional malicious modules for the second stage (lateral, persistence, etc.)
Re: (Score:2)
"an attacker with root access could bypass this fairly easily" - An attacker with root access doesn't need to bypass anything else. This article is about loading a module with code flaws in it and exploiting those flaws to get root access. Also the other argument about signed modules doesn't help either - these modules have the flaws in them regardless they are signed or not ...
I'm interested (Score:2)
For one, I'd love to *not* load modules that I don't need - cuts memory use, speeds up what I do.
Why this is a bad idea (Score:1)