Projekt Openwall wydanie modułu jądra (Linux Kernel Runtime Guard), zaprojektowanego do wykrywania i blokowania ataków oraz naruszeń integralności struktur jądra. Na przykład, moduł może chronić przed nieautoryzowanymi zmianami w działającym jądrze oraz próbami zmiany uprawnień procesów użytkowników (określenie stosowania exploitów). Moduł nadaje się zarówno do organizowania ochrony przed już znanymi exploitami dla jądra Linux (na przykład, w sytuacjach, gdy aktualizacja jądra w systemie jest problematyczna), jak i do przeciwdziałania exploitom dla jeszcze nieznanych luk. Kod projektu na licencji GPLv2.
Wśród zmian w nowej wersji:
- Zmieniło się pozycjonowanie projektu LKRG, który teraz nie dzieli się na osobne podsystemy do sprawdzania integralności i określania stosowania exploitów, lecz jest przedstawiany jako jednolity produkt do wykrywania ataków i różnych naruszeń integralności;
- Zapewniona zgodność z jądrami Linux od wersji 5.3 do 5.7, a także z jądrami skompilowanymi z agresywnymi optymalizacjami GCC, bez opcji CONFIG_USB i CONFIG_STACKTRACE lub z opcją CONFIG_UNWINDER_ORC, a także z jądrami, w których brakuje przechwytywanych funkcji LKRG, jeśli można się bez nich obejść;
- Podczas kompilacji zapewniono sprawdzenie niektórych obowiązkowych ustawień jądra CONFIG_* w celu generowania sensownych komunikatów o błędach zamiast niejasnych awarii;
- Dodano wsparcie dla trybu uśpienia (ACPI S3, suspend to RAM) oraz trybu hibernacji (S4, suspend to disk);
- Dodano wsparcie DKMS w Makefile;
- Zrealizowano eksperymentalne wsparcie dla 32-bitowych platform ARM (testowane na Raspberry Pi 3 Model B). Wcześniej dostępne wsparcie AArch64 (ARM64) zostało uzupełnione o zapewnienie zgodności z płytą Raspberry Pi 4;
- Dodano nowe przetworniki (hook), w tym przetwornik wywołania capable() dla lepszego określenia exploitów manipulujących „«, a nie identyfikatorami procesów ();
- Proponowana jest nowa logika określania prób wyjścia z ograniczeń przestrzeni nazw (na przykład, z kontenerów Docker);
- Na systemach x86-64 zapewniono sprawdzenie i zastosowanie bitu SMAP (Supervisor Mode Access Prevention), mającego na celu blokowanie dostępu do danych w przestrzeni użytkownika z kodu z przywilejami wykonywanego na poziomie jądra. Ochrona SMEP (Supervisor Mode Execution Prevention) została wdrożona wcześniej;
- Podczas pracy zapewniono umieszczenie ustawień LKRG w stronie pamięci, zazwyczaj dostępnej tylko do odczytu;
- Rejestrowanie informacji, które mogą być szczególnie przydatne w przypadku ataków (np. informacje o adresach w jądrze), jest ograniczone do trybu debugowania (log_level=4 i wyżej), wyłączonego domyślnie.
- Zwiększona skalowalność bazy danych śledzenia procesów — zamiast jednego drzewa RB chronionego jednym spinlockiem, użyto tabeli haszowej z 512 drzewami RB, chronionymi odpowiednio 512 blokadami do odczytu i zapisu;
- Wdrożono i domyślnie włączono tryb, w którym sprawdzanie integralności identyfikatorów procesu jest często wykonywane tylko dla bieżącego zadania, a także opcjonalnie dla aktywowanych (budzących się) zadań. Dla pozostałych zadań, które są w stanie uśpienia lub działają bez odwołania do kontrolowanego API LKRG jądra, sprawdzanie odbywa się rzadziej.
- Dodano nowe parametry sysctl i modułu do precyzyjnego dostosowania LKRG, a także dwa sysctl do uproszczonej konfiguracji przez wybór spośród przygotowanych przez deweloperów zestawów szczegółowych ustawień (profile);
- Ustawienia domyślne zostały zmienione, aby osiągnąć lepszą równowagę między szybkością wykrywania naruszeń a skutecznością reakcji z jednej strony oraz wpływem na wydajność i ryzykiem fałszywych alarmów z drugiej;
- Plik jednostki systemd został przerobiony w celu załadowania modułu LKRG na wczesnym etapie rozruchu (do wyłączenia modułu można użyć parametru wiersza poleceń jądra);
Biorąc pod uwagę optymalizacje zaproponowane w nowym wydaniu, spadek wydajności przy zastosowaniu LKRG 0.8 oceniany jest na poziomie 2,5% w domyślnym trybie ("heavy") i 2% w trybie uproszczonym ("light").
W niedawno przeprowadzonym wydajności pakietów w wykrywaniu rootkitów LKRG najlepsze wyniki, bez fałszywych alarmów, wykrywając 8 na 9 przetestowanych rootkitów działających na poziomie jądra (wykryto rootkity Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit i Sutekh, ale pominięto Keysniffer, który jest modułem jądra z keyloggerem, a nie rootkitem w dosłownym tego słowa znaczeniu). Dla porównania, pakiety AIDE, OSSEC i Rootkit Hunter wykryły 2 rootkity z 9, podczas gdy Chkrootkit nie wykrył żadnego. Przy tym LKRG nie obsługuje detekcji rootkitów umieszczanych w przestrzeni użytkownika, dlatego największa efektywność osiągana jest przy użyciu połączenia AIDE i LKRG, które pozwoliło wykryć 14 z 15 rootkitów wszystkich typów.
Dodatkowo można zauważyć, że twórca dystrybucji rozpoczął gotowych pakietów z DKMS dla Debiana, Whonixa, Qubes i Kicksecure, a pakiet dla został już zaktualizowany do wersji 0.8. Pakiety z LKRG są również dostępne w rosyjskich i .
Sprawdzanie integralności w LKRG odbywa się na podstawie porównania aktualnego kodu i danych jądra oraz modułów, niektórych ważnych struktur danych i ustawień CPU z zapisanymi hashami lub kopiami odpowiednich obszarów pamięci, struktur danych lub rejestrów. Sprawdzenia są aktywowane zarówno okresowo na podstawie zegara, jak i w przypadku różnych zdarzeń.
Określenie możliwego wykorzystania exploitów i blokowanie ataków odbywa się na etapie przed udzieleniem przez jądro dostępu do zasobów (np. przed otwarciem pliku), ale po uzyskaniu przez proces nieautoryzowanych uprawnień (np. zmiana UID). W przypadku wykrycia nieautoryzowanego zachowania procesów domyślnie następuje ich wymuszone zakończenie, co wystarcza do zablokowania wielu exploitów.
Źródło: opennet.ru
