Openwall-project uitgave van de kernelmodule (Linux Kernel Runtime Guard), ontworpen om aanvallen en integriteitsinbreuken op de structuren van de kernel te detecteren en te blokkeren. Bijvoorbeeld, de module kan beschermen tegen ongeautoriseerde wijzigingen aan een draaiende kernel en pogingen om de bevoegdheden van gebruikersprocessen te wijzigen (bepaling van exploittoepassingen). De module is geschikt voor zowel het beschermen tegen al bekende exploits voor de Linux-kernel (bijvoorbeeld in situaties waarin het moeilijk is om de kernel bij te werken) als voor het tegenwerken van exploits voor nog onbekende kwetsbaarheden. Projectcode onder GPLv2-licentie.
Onder de wijzigingen in de nieuwe versie:
- De positionering van het LKRG-project is gewijzigd, dat nu niet meer wordt opgesplitst in afzonderlijke subsysteem voor integriteitscontroles en het bepalen van exploittoepassingen, maar wordt gepresenteerd als een samenhangend product voor het detecteren van aanvallen en verschillende integriteitsinbreuken;
- Compatibiliteit met Linux-kernels van 5.3 tot 5.7 is verzekerd, evenals met kernels die zijn samengesteld met agressieve GCC-optimalisaties, zonder de opties CONFIG_USB en CONFIG_STACKTRACE of met de optie CONFIG_UNWINDER_ORC, alsook met kernels waarin geen onderschepte LKRG-functies aanwezig zijn, indien deze niet noodzakelijk zijn;
- Bij het bouwen is controle op enkele verplichte kernelinstellingen CONFIG_* toegevoegd voor het genereren van zinvolle foutmeldingen in plaats van onduidelijke storingen;
- Ondersteuning voor de slaapstand (ACPI S3, suspend to RAM) en de slaapmodus (S4, suspend to disk) is toegevoegd;
- Ondersteuning voor DKMS is toegevoegd aan het Makefile;
- Experimentale ondersteuning voor 32-bits ARM-platforms is geïmplementeerd (getest op Raspberry Pi 3 Model B). Eerder beschikbare ondersteuning voor AArch64 (ARM64) is uitgebreid met compatibiliteit voor de Raspberry Pi 4 bord;
- Nieuwe hooks zijn toegevoegd, inclusief de capable()-hook voor een betere bepaling van exploits die manipuleren "" in plaats van de identificaties van processen ();
- Een nieuwe logica is voorgesteld voor het bepalen van pogingen om uit de beperkingen van naamruimten te ontsnappen (bijvoorbeeld uit Docker-containers);
- In x86-64-systemen is de controle en toepassing van de SMAP-bit (Supervisor Mode Access Prevention) verzekerd, bedoeld om de toegang tot gegevens in de gebruikersruimte vanuit priviliged code die op kernel niveau draait te blokkeren. De bescherming SMEP (Supervisor Mode Execution Prevention) was eerder geïmplementeerd;
- In het werkproces is ervoor gezorgd dat de instellingen van LKRG in een geheugenpagina worden geplaatst die meestal alleen voor lezen toegankelijk is;
- De output in de logs van informatie die het meest nuttig kan zijn voor aanvallen (bijvoorbeeld informatie over adressen in de kernel) is beperkt tot de debugmodus (log_level=4 en hoger), die standaard is uitgeschakeld.
- De schaalbaarheid van de database voor procesmonitoring is verbeterd - in plaats van één RB-boom, beveiligd door één spinlock, wordt een hashtabel van 512 RB-bomen gebruikt, beveiligd door respectievelijk 512 lees-schrijf sloten;
- Er is een modus geïmplementeerd en standaard ingeschakeld waarbij de integriteitscontrole van proces-identificators vaak alleen wordt uitgevoerd voor de huidige taak, en optioneel voor geactiveerde (wakker wordende) taken. Voor andere taken die in de slaapstand zijn of zonder communicatie met de gecontroleerde LKRG API van de kernel werken, wordt de controle minder vaak uitgevoerd.
- Nieuwe sysctl- en moduleparameters zijn toegevoegd voor de fijne afstemming van LKRG, evenals twee sysctl voor eenvoudige configuratie door te kiezen uit de door de ontwikkelaars voorbereide sets van fine-tuning (profiles);
- De standaard instellingen zijn gewijzigd om een beter evenwicht te bereiken tussen de snelheid van het detecteren van schendingen en de effectiviteit van de reactie aan de ene kant, en de impact op de prestaties en het risico op valse positieven aan de andere kant;
- Het systemd unit-bestand is herzien voor het laden van de LKRG-module in een vroeg stadium van het opstarten (een opstartparameter kan worden gebruikt om de module uit te schakelen);
Met inachtneming van de voorgestelde optimalisaties in de nieuwe release wordt de prestatievermindering bij het toepassen van LKRG 0.8 geschat op 2,5% in de standaardmodus (‘heavy’) en 2% in de lichtere modus (‘light’).
In recent gehouden effectiviteit van pakketten voor het detecteren van rootkits LKRG de beste resultaten, zonder valse positieven, door 8 van de 9 geteste rootkits te detecteren die op kernniveau werkten (de rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit en Sutekh werden gedetecteerd, maar Keysniffer werd gemist, wat een kernelmodule is met een keylogger en geen rootkit in strikte zin). Ter vergelijking: de pakketten AIDE, OSSEC en Rootkit Hunter detecteerden 2 rootkits van de 9, terwijl Chkrootkit er geen enkele vond. Daarnaast ondersteunt LKRG geen detectie van rootkits die in de gebruikersruimte worden geplaatst, dus de grootste effectiviteit wordt bereikt door AIDE en LKRG samen te gebruiken, waarmee 14 van de 15 rootkits van alle soorten konden worden gedetecteerd.
Daarnaast kan worden opgemerkt dat de ontwikkelaar van de distributie begon ik kant-en-klare pakketten met DKMS voor Debian, Whonix, Qubes en Kicksecure, terwijl het pakket voor al is bijgewerkt naar versie 0.8. Pakketten met LKRG zijn ook aanwezig in Russische en .
De integriteitscontrole in LKRG wordt uitgevoerd op basis van de vergelijking van de actuele code en gegevens van de kernel en modules, enkele belangrijke datastructuren en CPU-instellingen met de 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 identificeren van mogelijke exploittoepassingen en het blokkeren van aanvallen gebeurt in de fase voordat de kernel toegang tot middelen verleent (bijvoorbeeld voordat een bestand wordt geopend), maar na het verkrijgen van ongeautoriseerde bevoegdheden door het proces (bijvoorbeeld het veranderen van UID). Bij het detecteren van ongeautoriseerd gedrag van processen wordt standaard hun gedwongen beëindiging uitgevoerd, wat voldoende is om veel exploits te blokkeren.
Bron: opennet.ru
