Openwall-project release van de kernelmodule (Linux Kernel Runtime Guard), ontworpen om aanvallen en schendingen van de integriteit van kernelstructuren te detecteren en te blokkeren. De module kan bijvoorbeeld beschermen tegen ongeautoriseerde wijzigingen aan de actieve kernel en probeert de machtigingen van gebruikersprocessen te wijzigen (het detecteren van het gebruik van exploits). De module is zowel geschikt voor het organiseren van bescherming tegen reeds bekende exploits voor de Linux-kernel (bijvoorbeeld in situaties waarin het moeilijk is om de kernel in het systeem te updaten), als voor het tegengaan van exploits voor nog onbekende kwetsbaarheden. Projectcode gelicentieerd onder GPLv2.
Onder de veranderingen in de nieuwe versie:
- De positionering van het LKRG-project is gewijzigd, dat niet langer is opgedeeld in afzonderlijke subsystemen voor het controleren van de integriteit en het vaststellen van het gebruik van exploits, maar wordt gepresenteerd als een compleet product voor het identificeren van aanvallen en diverse integriteitsschendingen;
- Compatibiliteit wordt geboden met Linux-kernels van 5.3 tot 5.7, evenals met kernels die zijn gecompileerd met agressieve GCC-optimalisaties, zonder de CONFIG_USB- en CONFIG_STACKTRACE-opties of met de CONFIG_UNWINDER_ORC-optie, evenals met kernels die geen LKRG-gekoppelde functies hebben, als ze dat kunnen achterwege blijven;
- Bij het bouwen worden enkele verplichte CONFIG_* kernelinstellingen gecontroleerd om betekenisvolle foutmeldingen te genereren in plaats van obscure crashes;
- Ondersteuning toegevoegd voor stand-by- (ACPI S3, slaapstand naar RAM) en slaapstand (S4, slaapstand naar schijf);
- DKMS-ondersteuning toegevoegd aan Makefile;
- Experimentele ondersteuning voor 32-bits ARM-platforms is geïmplementeerd (getest op Raspberry Pi 3 Model B). Eerder beschikbare AArch64 (ARM64)-ondersteuning is uitgebreid om compatibiliteit met het Raspberry Pi 4-bord te bieden;
- Er zijn nieuwe hooks toegevoegd, waaronder een capabele() call handler om exploits die manipuleren beter te identificeren", geen ID's verwerken ();
- Er is nieuwe logica voorgesteld voor het detecteren van pogingen om aan naamruimtebeperkingen te ontsnappen (bijvoorbeeld vanuit Docker-containers);
- Op x86-64-systemen wordt de SMAP-bit (Supervisor Mode Access Prevention) gecontroleerd en toegepast, ontworpen om de toegang tot gebruikersruimtegegevens te blokkeren van bevoorrechte code die op kernelniveau wordt uitgevoerd. SMEP-bescherming (Supervisor Mode Execution Prevention) werd eerder geïmplementeerd;
- Tijdens bedrijf worden de LKRG-instellingen op een geheugenpagina geplaatst die meestal alleen-lezen is;
- Logboekinformatie die het nuttigst kan zijn voor aanvallen (bijvoorbeeld informatie over adressen in de kernel) is beperkt tot de foutopsporingsmodus (log_level=4 en hoger), die standaard is uitgeschakeld.
- De schaalbaarheid van de database voor het volgen van processen is vergroot - in plaats van één RB-boom beschermd door één spinlock, wordt een hashtabel van 512 RB-bomen beschermd door 512 lees-schrijfvergrendelingen gebruikt;
- Er is standaard een modus geïmplementeerd en ingeschakeld, waarin de integriteit van procesidentifiers vaak alleen voor de huidige taak wordt gecontroleerd, en optioneel ook voor geactiveerde (wakkere) taken. Voor andere taken die zich in de slaapstand bevinden of werken zonder toegang te krijgen tot de kernel-API die wordt beheerd door LKRG, wordt de controle minder vaak uitgevoerd.
- Nieuwe sysctl- en moduleparameters toegevoegd voor het verfijnen van LKRG, evenals twee sysctl voor vereenvoudigde configuratie door te selecteren uit sets van fijnafstemmingsinstellingen (profielen) opgesteld door de ontwikkelaars;
- De standaardinstellingen zijn gewijzigd om een evenwichtiger evenwicht te bereiken tussen de snelheid van detectie van overtredingen en de effectiviteit van de reactie enerzijds, en de impact op de prestaties en het risico op valse positieven anderzijds;
- Het systemd unit-bestand is opnieuw ontworpen om de LKRG-module vroeg tijdens het opstarten te laden (een kernel-opdrachtregeloptie kan worden gebruikt om de module uit te schakelen);
Rekening houdend met de in de nieuwe release voorgestelde optimalisaties, wordt de prestatievermindering bij gebruik van LKRG 0.8 geschat op 2.5% in de standaardmodus (“zwaar”) en 2% in de lichte modus (“licht”).
In een onlangs gehouden effectiviteit van pakketten voor het detecteren van rootkits LKRG beste resultaten, waarbij 8 van de 9 geteste rootkits werden geïdentificeerd die op kernelniveau werkten zonder valse positieven (rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit en Sutekh werden geïdentificeerd, maar Keysniffer, een kernel module, werd gemist met een keylogger, niet met een rootkit in de letterlijke zin). Ter vergelijking: de pakketten AIDE, OSSEC en Rootkit Hunter hebben 2 van de 9 rootkits gedetecteerd, terwijl Chkrootkit er geen heeft gedetecteerd. Tegelijkertijd ondersteunt LKRG de detectie van rootkits die zich in de gebruikersruimte bevinden niet, dus de grootste efficiëntie wordt bereikt bij het gebruik van een combinatie van AIDE en LKRG, waardoor het mogelijk werd om 14 van de 15 rootkits van alle typen te identificeren.
Bovendien kan worden opgemerkt dat de distributie-ontwikkelaar begonnen kant-en-klare pakketten met DKMS voor Debian, Whonix, Qubes en Kicksecure, en een pakket voor al bijgewerkt naar versie 0.8. Pakketten met LKRG zijn ook beschikbaar in het Russisch и .
Integriteitscontrole in LKRG wordt uitgevoerd door de feitelijke code en gegevens van de kernel en modules, enkele belangrijke datastructuren en CPU-instellingen te vergelijken met opgeslagen hashes of kopieën van de overeenkomstige geheugengebieden, datastructuren of registers. Controles worden zowel periodiek door een timer als bij het optreden van verschillende gebeurtenissen geactiveerd.
Het bepalen van het mogelijke gebruik van exploits en het blokkeren van aanvallen wordt uitgevoerd in de fase voordat de kernel toegang geeft tot bronnen (bijvoorbeeld voordat een bestand wordt geopend), maar nadat het proces ongeautoriseerde toestemming heeft gekregen (bijvoorbeeld het wijzigen van de UID). Wanneer ongeautoriseerd gedrag wordt gedetecteerd, worden processen standaard beëindigd, wat voldoende is om veel exploits te blokkeren.
Bron: opennet.ru