Sysadmin Creates 'ModuleJail' To Automatically Blacklist Unused Kernel Modules (github.com) 22
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: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:1)
Don't hear much about philosophy students using mammoth legacy data systems. Was this a university or research center?
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: (Score:2)
" 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: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: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: (Score:3)
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:2)
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
Kernel Module Signing (Score:2)
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.)