Openwall projekt kernel modul kiadás (Linux Kernel Runtime Guard), amelynek célja a támadások és a kernelszerkezetek integritásának megsértése észlelése és blokkolása. Például a modul képes megvédeni a futó kernel jogosulatlan módosításait, és megkísérli megváltoztatni a felhasználói folyamatok engedélyeit (a kihasználások használatának észlelését). A modul alkalmas mind a Linux kernel már ismert exploitjai elleni védelem megszervezésére (például olyan helyzetekben, amikor nehézkes a kernel frissítése a rendszerben), mind pedig a még ismeretlen sebezhetőségek kizsákmányolásainak leküzdésére. Projekt kód GPLv2 licenccel.
Az új verzió változásai között szerepel:
- Módosult az LKRG projekt pozicionálása, amely már nincs külön alrendszerekre osztva az integritás ellenőrzésére és az exploitok használatának meghatározására, hanem teljes termékként jelenik meg a támadások és a különböző integritássértések azonosítására;
- A kompatibilitás biztosított az 5.3-tól 5.7-ig terjedő Linux kernelekkel, valamint az agresszív GCC optimalizálással, a CONFIG_USB és CONFIG_STACKTRACE opciók nélkül vagy a CONFIG_UNWINDER_ORC opcióval fordított kernelekkel, valamint az LKRG funkcióval nem rendelkező kernelekkel nélkülözni kell;
- Az építés során bizonyos kötelező CONFIG_* kernelbeállításokat ellenőriznek, hogy értelmes hibaüzeneteket generáljanak a homályos összeomlások helyett;
- Hozzáadott támogatás a készenléti (ACPI S3, felfüggesztés a RAM-hoz) és alvó (S4, felfüggesztés a lemezre) módokhoz;
- DKMS támogatás hozzáadva a Makefile-hoz;
- Megvalósult a 32 bites ARM platformok kísérleti támogatása (a Raspberry Pi 3 Model B-n tesztelték). A korábban elérhető AArch64 (ARM64) támogatás kibővült, hogy kompatibilis legyen a Raspberry Pi 4 kártyával;
- Új hookok kerültek hozzáadásra, beleértve a képes() híváskezelőt a "", nem folyamatazonosítók ();
- Új logikát javasoltak a névtér-korlátozások elkerülésére irányuló kísérletek észlelésére (például Docker-tárolókból);
- Az x86-64 rendszereken az SMAP (Supervisor Mode Access Prevention) bitet ellenőrzik és alkalmazzák, hogy blokkolja a hozzáférést a felhasználói terület adataihoz a rendszermag szintjén futó privilegizált kódból. A SMEP (Supervisor Mode Execution Prevention) védelmet korábban megvalósították;
- Működés közben az LKRG beállítások egy általában csak olvasható memóriaoldalon kerülnek elhelyezésre;
- A támadásoknál leghasznosabb naplózási információk (például a kernelben lévő címekkel kapcsolatos információk) a hibakeresési módra korlátozódnak (log_level=4 és magasabb), amely alapértelmezés szerint le van tiltva.
- A folyamatkövető adatbázis skálázhatósága megnőtt - egy spinlock által védett RB fa helyett egy 512 RB fát tartalmazó hash táblát használnak, amelyet 512 olvasási-írási zárol védett;
- Alapértelmezésben egy olyan mód került megvalósításra és engedélyezésre, amelyben a folyamatazonosítók sértetlenségét gyakran csak az aktuális feladatnál, és opcionálisan az aktivált (ébreszthető) feladatoknál is ellenőrzik. Más, alvó állapotban lévő vagy az LKRG által vezérelt kernel API-hoz való hozzáférés nélkül működő feladatok esetében az ellenőrzést ritkábban hajtják végre.
- Új sysctl és modul paraméterek hozzáadva az LKRG finomhangolásához, valamint két sysctl az egyszerűsített konfiguráláshoz a fejlesztők által készített finomhangolási beállítások (profilok) készleteiből történő kiválasztással;
- Az alapértelmezett beállításokat úgy módosították, hogy kiegyensúlyozottabb egyensúlyt érjenek el egyrészt a jogsértések észlelésének sebessége és a válasz hatékonysága, másrészt a teljesítményre gyakorolt hatás és a hamis pozitív eredmények kockázata között;
- A systemd unit fájlt újratervezték, hogy az LKRG modult a rendszerindítás korai szakaszában betöltse (a kernel parancssori opciója használható a modul letiltására);
Figyelembe véve az új kiadásban javasolt optimalizációkat, az LKRG 0.8 használatakor a teljesítménycsökkenést 2.5%-ra becsülik alapértelmezett módban ("heavy"), és 2%-ra könnyű módban ("light").
Egy nemrégiben tartott az LKRG rootkitek észlelésére szolgáló csomagok hatékonysága A legjobb eredményeket a 8 tesztelt rootkit közül 9 azonosította, amely kernel szinten működik téves pozitívumok nélkül (a Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit és Sutekh rootkiteket azonosították, de a Keysniffert, amely egy kernel modul, egy keyloggernél hiányzott, nem a szó szerinti rootkitből). Összehasonlításképpen: az AIDE, OSSEC és Rootkit Hunter csomagok 2 rootkitből 9-t észleltek, míg a Chkrootkit egyet sem. Ugyanakkor az LKRG nem támogatja a felhasználói térben található rootkitek észlelését, így a legnagyobb hatékonyságot az AIDE és az LKRG kombinációjának használatával érik el, amely lehetővé tette a 14-ből 15 minden típusú rootkit azonosítását.
Ezenkívül megjegyzendő, hogy a disztribúció fejlesztője elkezdtem kész csomagok DKMS-sel a Debian, Whonix, Qubes és Kicksecure számára, valamint egy csomag már frissítve a 0.8-as verzióra. Az LKRG-vel ellátott csomagok orosz nyelven is kaphatók и .
Az LKRG integritás-ellenőrzése a kernel és a modulok tényleges kódjának és adatainak, néhány fontos adatszerkezetnek és CPU-beállításnak összehasonlításával történik a megfelelő memóriaterületek, adatstruktúrák vagy regiszterek tárolt hash-eivel vagy másolataival. Az ellenőrzéseket az időzítő időszakosan és különböző események bekövetkeztekor is aktiválja.
A kihasználások és a blokkoló támadások lehetséges használatának meghatározása abban a szakaszban történik, mielőtt a kernel hozzáférést biztosít az erőforrásokhoz (például egy fájl megnyitása előtt), de miután a folyamat jogosulatlan engedélyeket kapott (például az UID megváltoztatása). Ha a rendszer jogosulatlan viselkedést észlel, a folyamatok alapértelmezés szerint leállnak, ami elegendő sok kihasználás blokkolásához.
Forrás: opennet.ru