Linuxkärnan är full av moduler som gör systemet flexibelt, men många av dem används aldrig på en vanlig server eller dator. Det nya projektet ModuleJail vill minska risken för angrepp genom att svartlista oanvända kernelmoduler och därmed begränsa den yta som kan utnyttjas vid lokala säkerhetshål. Verktyget lagar inga sårbarheter, men fungerar som ett extra skyddslager för administratörer som vill härda sina Linuxsystem.

Linuxkärnan är hjärtat i ett Linuxsystem. Den hanterar hårdvara, minne, filer, nätverk och mycket annat. För att kunna stödja många olika datorer och användningsområden är kärnan ofta uppbyggd med moduler – små delar som kan laddas in vid behov. Men just den flexibiliteten kan också bli en säkerhetsrisk. Det nya projektet ModuleJail försöker minska risken genom att blockera kernelmoduler som systemet inte använder.

ModuleJail är ett nytt härdningsverktyg för Linux. Det är inte ett antivirusprogram, inte en brandvägg och inte en lösning som lagar sårbarheter. I stället bygger det på en enkel idé: om ett system inte behöver en viss kernelmodul, ska den inte heller kunna laddas in senare.

Bakgrunden är de senaste rapporterna om allvarliga lokala sårbarheter i Linuxkärnan, bland annat Copy Fail, Dirty Frag och Fragnesia. Den typen av sårbarheter kan i värsta fall göra det möjligt för en lokal användare eller process att höja sina rättigheter och få mer kontroll över systemet än den borde ha.

För systemadministratörer är detta ett välkänt problem. Ett modernt Linuxsystem kan innehålla tusentals kernelmoduler, men i praktiken används bara en mindre del av dem. En server behöver kanske inte stöd för Bluetooth, ovanliga filsystem, ljudkort, TV-mottagare eller specialiserad hårdvara. Ändå kan modulerna ligga kvar och i vissa fall laddas in vid behov.

Det är just detta ModuleJail försöker begränsa.

Så fungerar ModuleJail

ModuleJail är byggt som ett enda POSIX shell-skript. Det gör arbetet relativt enkelt och transparent. Verktyget tittar först på vilka kernelmoduler som redan är laddade i systemet. Därefter jämförs dessa med hela modulträdet under:

Alla moduler som inte används, och som inte finns med i en skyddslista, skrivs sedan in i en blacklist-fil för modprobe. Standardplatsen är:

I filen används rader av typen:

Det betyder i praktiken att när systemet försöker ladda modulen via modprobe, körs i stället /bin/true. Resultatet blir att modulen inte laddas.

Det här är en gammal och etablerad metod för att förhindra laddning av kernelmoduler via modprobe-konfigurationen. ModuleJail automatiserar helt enkelt processen och gör den mer systematisk.

Skyddar inte mot allt – men minskar risken

Det är viktigt att förstå vad ModuleJail inte gör. Verktyget analyserar inte moduler efter kända säkerhetshål. Det kontrollerar inte CVE-databaser, gör ingen riskpoängsättning och avgör inte om en modul är farlig.

I stället arbetar ModuleJail med principen minsta möjliga angreppsyta. Om en modul inte behövs på systemet, bör den inte vara tillgänglig.

Det kan jämföras med att låsa dörrar i ett hus som inte används. Man vet kanske inte om någon särskild dörr är svagare än en annan, men färre öppna dörrar ger färre möjligheter för en angripare.

På en server kan detta vara särskilt intressant. En webbserver, databasserver eller filserver använder ofta en ganska förutsägbar uppsättning drivrutiner och funktioner. Om systemet redan är igång och alla tjänster fungerar, kan man ta en ögonblicksbild av vilka moduler som faktiskt behövs. Resten kan blockeras.

Körs en gång – inte som bakgrundstjänst

ModuleJail är tänkt att användas som ett engångsverktyg. Det körs inte som en daemon i bakgrunden och övervakar inte systemet löpande. Det är snarare ett sätt att skapa en statisk spärrlista efter att systemet har nått ett stabilt läge.

Det innebär också att tidpunkten är viktig.

Verktyget bör köras först när systemet är fullt startat, alla tjänster är igång, filsystem är monterade och all nödvändig hårdvara är aktiverad. Om ModuleJail körs för tidigt finns risken att det svartlistar moduler som behövs senare.

Exempelvis kan det handla om moduler för:

• extra lagringsenheter
• nätverkskort
• Wi-Fi
• Bluetooth
• ljud
• grafikkort
• specialiserade filsystem
• backup- eller virtualiseringslösningar

På en skrivbordsdator eller laptop kan detta bli mer känsligt än på en server, eftersom hårdvaran ofta varierar mer. En användare kan ansluta USB-enheter, Bluetooth-tillbehör, externa skärmar eller dockningsstationer först senare.

Tre profiler för olika system

ModuleJail innehåller tre olika basprofiler.

Den konservativa standardprofilen är tänkt för servrar, både virtuella och fysiska. Den försöker bevara moduler som normalt kan behövas i en servermiljö, men blockerar sådant som bedöms vara onödigt.

Desktop-profilen är mer försiktig för vanliga arbetsstationer och bärbara datorer. Den sparar fler moduler för Wi-Fi, Bluetooth, ljud och video, eftersom sådant ofta behövs på en vanlig dator.

Minimal-profilen är den mest strikta. Den behåller i huvudsak kärnfunktioner, grundläggande filsystem och nödvändiga moduler. Den passar främst för mycket kontrollerade miljöer där man vet exakt vad systemet behöver.

Lokal vitlista för specialfall

Alla system är olika. Därför har ModuleJail stöd för en lokal vitlista i skriptet. Där kan administratören ange moduler som alltid ska bevaras, även om de inte råkar vara laddade när verktyget körs.

Det är användbart för moduler som bara behövs ibland. Det kan till exempel vara drivrutiner för backupmedia, tillfälliga nätverkslösningar, externa lagringsenheter eller särskilda filsystem.

Vitlistan är viktig eftersom ModuleJail annars utgår från en ganska enkel fråga: är modulen laddad just nu eller inte?

Det är både styrkan och svagheten i metoden. Den är enkel, begriplig och lätt att granska. Men den kräver också att administratören förstår sitt system.

Kan ge problem om det används fel

ModuleJail är inte ett verktyg man bör köra slentrianmässigt på vilken dator som helst utan eftertanke. Om fel moduler blockeras kan systemet tappa funktionalitet.

På en server kan det betyda att en viss lagringslösning, nätverksfunktion eller virtualiseringsfunktion slutar fungera efter omstart. På en laptop kan det innebära att Wi-Fi, ljud, Bluetooth eller externa enheter inte fungerar som väntat.

Återställning är också manuell. För att ta bort spärren behöver administratören radera blacklist-filen:

Därefter krävs normalt en omstart. Det går också att ladda enskilda moduler manuellt med modprobe under den aktuella sessionen, men efter omstart gäller blacklist-filen igen om den finns kvar.

Det gör att ModuleJail passar bäst för tekniskt kunniga användare och administratörer som vill härda system där funktionerna är välkända och stabila.

Testat på flera Linuxdistributioner

Enligt projektets uppgifter har ModuleJail testats på Ubuntu 24.04 LTS, Debian 13.4 och Rocky Linux 9.7 på riktiga system. Det har även testats i containerbaserade miljöer för Arch Linux, Alpine Linux och openSUSE Tumbleweed.

Det finns färdiga DEB- och RPM-paket för Debian/Ubuntu respektive RHEL/Fedora/Alma/Rocky-baserade system. Samtidigt är själva idén inte bunden till en specifik distribution, eftersom verktyget bygger på standardfunktioner i Linux och modprobe.

Ett enkelt men intressant säkerhetsgrepp

ModuleJail visar att säkerhet inte alltid handlar om avancerad AI, stora databaser eller komplicerade övervakningssystem. Ibland kan en relativt enkel metod ge praktisk nytta: ta reda på vad systemet faktiskt använder och blockera resten.

Det gör inte Linuxkärnan osårbar. Det ersätter inte säkerhetsuppdateringar. Det skyddar inte mot redan laddade sårbara moduler. Men det kan minska antalet möjliga vägar in för en angripare.

För servrar och andra kontrollerade Linuxmiljöer kan ModuleJail därför bli ett intressant komplement till traditionell säkerhetshärdning. Det är inte en universallösning, men det är ett tydligt exempel på en klassisk säkerhetsprincip: ju mindre som är exponerat, desto mindre finns det att angripa.

https://github.com/jnuyens/modulejail/