Opis łaty na jądro, w znaczym stopniu poprawiającej bezpieczeństwo systemu.

W czerwcu zeszłego roku napisałem artykuł traktujący o grsecurity dla, najnowszego wówczas, jądra 2.4.5. Postanowiłem napisać go od nowa, gdyż zmiany, które nastąpiły przez rok są na tyle duże, że żadne uzupełnienie nie miałoby sensu.

Więc od początku... Grsecurity to patch na jądra z serii 2.4 poprawiający bezpieczeństwo i wzbogacający system o kilka ciekawych możliwości. Przez dłuższy okres istnienia serii 2.4 był jedynym tego typu narzędziem, jednak ostatnio, Solar Designer wypuścił również testową wersję Openwall dla nowych wersji kernela.

Skąd? Łata (oraz kilka innych narzędzi) dostępna jest pod adresem: www.grsecurity.org.

Po zaaplikowaniu łaty, w konfiguracji jądra pojawia się nowa sekcja o nazwie "Grsecurity". Wewnątrz niej znajduje się opcja CONFIG_GRKERNSEC, dzięki której określamy czy chcemy korzystać z możliwości łaty. Po jej zaznaczeniu (do wkompilowania, żadnej opcji grsecurity nie można zaznaczyć jako moduł), dostajemy do wyboru 4 ustawienia poziomu bezpieczenstwa: Low, Medium, High i Customized. Ja, rzecz jasna, zajmę się tylko tym ostatnim. Czytelnikowi również polecam przyjrzenie się dokładnie wszystkim opcjom, zwłaszcza że po przeczytaniu tego opracowania samodzielne skonfigurowanie grsecurity nie pwoinno stanowić większego problemu. Zobaczmy więc dokładnie co oferują poszczególne sekcje.

Co to "buffer overflow"? Dla większości wsółczesnych włamań podstawą są ataki polegające na przepełnieniu bufora - buffer overflow. Nie będę opisywał na czym one polegają, bo ten temat mógłby wypełnić kolejny artykuł podobnej wielkości. Generalnie chodzi o to, że niestarannie napisane programy pozwalają potencjalnemu włamywaczowi wywołać dowolny kod, jeśli zaś są to aplikacje instalowane w systemie z ustawionym bitem SUID, lub usługi uruchmione przez uprzywilejowanego użytkowniika, drzwi do uzyskania uprawnień administratora stoją otworem.

Oto w jaki sposób możemy się (choćby częściowo) zabezpieczyć się przed tego typy atakami przy pomocy grsecurity:

Openwall non-executable stack (CONFIG_GRKERNSEC_STACK) To zabezpieczenie próbuje zapobiegać wykonywaniu kodu w stosie, co komplikuje działanie exploitów i sprawia że ich stworzenie staje się trudniejsze. To rozwiązanie przeniesione zostało z Openwalla, o którym wspomniałem wcześniej.

PaX protection (CONFIG_GRKERNSEC_PAX) PaX uniemożliwia wykonywanie niektórych fragmentów pamięci (stos, sterta), zabezpieczając system skuteczniej niż non-executable stack z Openwalla, jednakże niesie ze sobą dwie niedogodności: pierwszą jest spadek wydajności, drugą niedziałanie niektórych programów (XFree 4.x, wine, ...)

Full Address Space Layout Randomization (ASLR) (CONFIG_GRKERNSEC_PAX_RANDMMAP) Zaznaczenie tej opcji powoduje, że ładowany dynamicznie kod, pojawia się pod losowym (a więc nie znanym włamywaczowi) adresem. Praktycznie niemożliwa staje się więc ingerencja w taki kod. Ta opcja jest szczególnie polecana, gdyż nie ma wpływu na wydajność systemu.

Read-only kernel memory (CONFIG_GRKERNSEC_KMEM) Powoduje, że pamięć jądra nie może być modyfikowana (nawet przez roota). Dokumentacja sugeruje, że ustawienie tej opcji, łącznie z wyłączeniem możliwości ładowania modułów, wyeliminuje możliwość użycia przez jądro obcego kodu.

Opcje dostępne w tej sekcji ograniczają lub zabezpieczają przed atakami różne części systemu plików, oto one:

Proc restrictions (CONFIG_GRKERNSEC_PROC) Opcja znana z Openwalla. Uniemożliwia użytkownikom dostęp do plików w /proc które ich nie dotyczą (informacje o procesach innych użytykoników, sieci, ...). Ograniczanie /proc jest dość dobrze znane i szeroko wykorzystywane przez większość administratorów. Możliwe jest też udostępnienie tych informacji konkretnemu użytkownikowi lub grupie (wymagane np: przez demony *identd działające jako zwykły użytkownik, a potrzebujące informacji o procesach i sieci). Dodatkowa opcja pozwala ponadto ograniczyć informacje o urządzeniach w systemie (np: /proc/cpuinfo).

Linking restrictions (CONFIG_GRKERNSEC_LINK) i FIFO restrictions (CONFIG_GRKERNSEC_FIFO) Zapobieganie atakom z użyciem dowiązań poprzez nałożenie pewnych ograniczeń na system plików - m.in. linki do plików będących własnością innych użytkowników, lub linki i kolejki w katalogach z ustawionym bitem +t (jak np: /tmp). Uniemożliwia to podstawienie w /tmp linku do jakiegos istotnego dla systemu pliku nazwanego tak, by wykorzystał go jakiś program (np demon), który go zmodyfikuje w korzystny dla włamywacza sposób. Dodatkowo, losowe PIDy (opisane niżej) utrudniają przewidzenie nazwy pliku tymczasowego którego użyje atakowany proces, a więc i stworzenie odpowiedniego dowiązania.

Secure file descriptors (CONFIG_GRKERNSEC_FD) Deskryptory plików 0 (stdin), 1 (stdout) i 2 (stderr), które mogą zostać użyte przez włamywacza do odczytu lub zapisu w plikach mu niedostępnych są zabezpieczane poprzez "wymuszenie" ich otwarcia - jeśli aplikacja ich nie używa zostaje otwarty /dev/null.

Chroot jail restrictions (CONFIG_GRKERNSEC_CHROOT) Umożliwia wybranie szeregu opcji zabezpieczających dodatkowo "klatkę" jaką dla programów jest chroot. Do wyboru mamy:

Restricted signals

- nie pozwala wysłać sygnałów poza chroot

Deny mounts

- procesy wewnątrz "więzienia" nie mogą montować lub re-montować żadnych sytemów plików

Deny double-chroots

- nie można robić chrootów w chroocie

Enforce chdir("/") on all chroots

- wymuszanie przejścia do katalogu (dla chroota) głównego

Deny (f)chmod +s

- uniemożliwienie ustawiania atrybutu SUID

Deny mknod

- zakaz tworzenia plików specjalnych wewnątrz chroota

Deny ptraces

- zakaz używania ptrace

Restrict priority changes

- uniemożliwienie zwiekszania priorytetu procesów

Capability restrictions within chroot (CONFIG_GRKERNSEC_CHROOT_CAPS) Zaznaczenie tej opcji znacznie ogranicza możliwości roota wewnątrz chroot jail. Nie będzie on mógł ładować modułów, korzystać z bespośredniego I/O, zmieniać czasu, rebootować systemu, itd...

Secure keymap loading (CONFIG_GRKERNSEC_KBMAP) Uniemożliwienie ładowania mapy klawiatury, a więc i zmiany znaczenia klawiszy przez nieuprzywilejowanych użytykowników.

Opcje w tej sekcji umożliwiają wybranie dodatkowych zdarzeń, które mają być zapisywane przez jądro w dzienniku systemowym.

Single group for auditing (CONFIG_GRKERNSEC_AUDIT_GROUP) Określa, czy niektóre zarzenia (exec, chdir, (un)mount, ipc) mają być logowane tylko dla określonej grupy - wybranej w: GID for auditing. Umożliwia to obserwowanie konkretnych użytkowników lub procesów.

Exec logging (CONFIG_GRKERNSEC_EXECLOG) Zapisuje (WSZYSTKIE!) wywołania funkcji execve(), a więc i wszystkich exec*(). Pozwala dokładnie śledzić programy uruchamiane przez użytkoników, jednak włączenie tej opcji globalnie nie wydaje się rozsądnym rozwiązaniem ze względu na ilość produkowanych logów.

Log execs within chroot (CONFIG_GRKERNSEC_CHROOT_EXECLOG) Identyczne z poprzednią opcją, ale zapisuje wywołania wyłącznie wewnątrz chroota.

Chdir logging (CONFIG_GRKERNSEC_AUDIT_CHDIR) Logowanie wywołań funkcji systemowej chdir(). Równie zaśmiecające logi co Exec logging.

Mount logging (CONFIG_GRKERNSEC_AUDIT_MOUNT) Zapisywanie wszystkich montowań i odmontowań.

IPC logging (CONFIG_GRKERNSEC_AUDIT_IPC) Wybranie tej opcji powoduje logowanie pewnych wywołań funkcji IPC (komunikacji między procesami) - tworzenia i usuwania kolejek komunikatów, pamięci dzielonej i semaforów.

Ptrace logging (CONFIG_GRKERNSEC_AUDIT_PTRACE) Wszystkie udane wywołania ptrace() zostaną zapisane. Dowiemy się dzięki temu kto próbuje używać programów w rodzaju gdb czy strace, lub też próbuje użyć exploitów wykorzystujących luki w kodzie jądra związanym z ptrace, jak na przykład tego.

Signal logging (CONFIG_GRKERNSEC_SIGNAL) Zaznaczenie tego spowoduje, że istotniejsze sygnały zostaną zalogowane. Przykładem sygnału który może interesować administratora jest SIGSEGV, ponieważ może on świadczyć o próbie akatu typu buffer overflow (o czym wyżej).

Fork failure logging (CONFIG_GRKERNSEC_FORKFAIL) Ta opcja powoduje zapisywanie nieudanych wywołań fork(). Dzieki niej administrator będzie wiedział o próbach przekroczenia limitu jednocześnie uruchomionych przez użytkownika procesów.

Set*id logging (CONFIG_GRKERNSEC_SUID) Również przydatna opcja - loguje wszystkie wywołania set*id() (ustawienie (E)UID, GID, ...), ale jednocześnie produkuje ogromną ilość wpisów w dzienniku systemowym.

Ta sekcja zawiera opcje, które ograniczają lub podbezpieczają funkcje systemowe związane z wykonywaniem programów.

Exec process limiting (CONFIG_GRKERNSEC_EXECVE) Domyślnie w Linuksie przy wywołaniu funkcji exec*() nie są brane pod uwage limity procesów. Użycie tej opcji powoduje dodanie takiej funkcjonalności.

Dmesg(8) restriction (CONFIG_GRKERNSEC_DMESG) Ograniczenie dostępu do komunikatów wypisywanych przez jądro wyłącznie do użytkownika root. Zwykły użytkownik chcący odczytac te informacje ujrzy jedynie: "klogctl: Operacja niedozwolona".

Randomized PIDs (CONFIG_GRKERNSEC_RANDPID) Ta opcja powoduje, że nowe procesy otrzymują pseudo-losowe identyfikatory (normalnie, po prostu kolejne). Zapobiega to przed "odgadnięciem" PIDa określonej aplikacji (np demona), przez włamywacza. Polecane jest używanie tej opcji razem z Proc restrictions.

Trusted path execution (CONFIG_GRKERNSEC_TPE) Umożliwia wydzielenie (przez dodanie do odpowiedniej grupy), użytkowników, którzy będą mogli uruchamiać pliki znajdujące się jedynie w katalogach których właścicielem jest root i tylko on może w nich zapisywać. Uniemożliwi to "wybrańcom" uruchomienie nieznanego kodu (np exploita). Wybranie tej opcji powoduje pojawienie się kolejnych:

Partially restrict non-root users (CONFIG_GRKERNSEC_TPE_ALL)

- Włącza TPE dla wszystkich użytkowników poza administratorem, z tym, że pozwala im na uruchamianie aplikacji z własnych katalogów (jeżeli nie mają one praw do zapisu dla grupy lub wszystkich). Chroni to użytkowników przed "podrzuceniem" im kodu przez kogoś innego.

GID for untrusted users (CONFIG_GRKERNSEC_TPE_GID)

- Określa ID grupy dla której chcemy zastosować wspomniane wyżej restrykcje.

Dzieki poniższym opcjom możliwe jest ukrycie pewnych cech charakterystycznych dla Linuksa zaszytych między innymi w kodzie obsługującym stos TCP/IP, jak również ograniczenie dostępu do sieci konkretnym użytkownikom.

Randomized IP IDs (CONFIG_GRKERNSEC_RANDID) Dzieki tej opcji jądro bedzie używac, zapożyczonego z OpenBSD, kodu odpowiedzialnego za ustalanie pola ID w nagłówku pakietów IP. Dzieki temu ciężej bedzie określic rodzaj systemu poprzez OS fingerprinting, jak również uniemożliwi to skanowanie trudnowykrywalną metodą ip.id.

Randomized TCP source ports (CONFIG_GRKERNSEC_RANDSRC) Powoduje ustalanie losowych portów, otwieranych na maszynie przy nawiązywaniu połączenia. Domyślnie numery tych portów są po prostu zwiększane. Utrudnia fingerprinting.

Randomized RPC XIDs (CONFIG_GRKERNSEC_RANDRPC), Randomized RPC privileged port binding (CONFIG_GRKERNSEC_RANDBIND) Dodatkowa "losowość" przy RPC, zwiększająca bezpieczeństwo tych usług.

Altered Ping IDs (CONFIG_GRKERNSEC_RANDPING) Zmiana "polityki" wybierania ID przy odpowiedziach na icmp echo (popularny "ping"). Powoduje kolejną dezinformacje przy próbie rozpoznania systemu.

Socket restrictions (CONFIG_GRKERNSEC_SOCKET) Ograniczanie możliwości tworzenia gniazd sieciowych przez użytkowników. Patrz opcje poniżej:

Deny all socket access (CONFIG_GRKERNSEC_SOCKET_ALL)

- zablokuj wszystkie rodzaje gniazd (klienckie, serwerowe), określonej grupie

Group for disabled socket access (CONFIG_GRKERNSEC_SOCKET_ALL_GID)

- grupa która nie będzie mogła korzystać z gniazd

Deny all client socket access (CONFIG_GRKERNSEC_SOCKET_CLIENT)

- zablokuj możliwość otwierania gniazd "klienckich" (connect() ...)

Group for disabled client socket access (CONFIG_GRKERNSEC_SOCKET_CLIENT_GID)

- GID dla tego ograniczenia

Deny all server socket access (CONFIG_GRKERNSEC_SOCKET_SERVER)

- uniemożliw tworzenie gniazd serwerowych (a więc i otwieranie portów)

Group for disabled server socket access (CONFIG_GRKERNSEC_SOCKET_SERVER_GID)

- grupa nie mogąca tworzyć serwerowych socketów

Opcje sieciowe grsecurity nie kończą sie na tej sekcji. Jeśli wybraliśmy CONFIG_NETFILTER, CONFIG_INET, CONFIG_IP_NF_IPTABLES, więc obsługę netfilter, TCP/IP i iptables, w sekcji IP: Netfilter Configuration pojawi się opcja: stealth match support. Rozszerza ona możliwości filtra pakietów o wyłapywanie pakietów TCP/UDP kierowanych na zamknięte porty i odrzucanie ich. Standardowo Linux wysyła w takiej sytuacji pakiet ICMP informujący o zamkniętym porcie - port unreachable. Zastosowanie tego rozwiązania może dość poważnie utrudnić próby skanowania naszego systemu, ale również sprawi, że stanie się on niezgodny z RFC.

Sysctl support Ogromną ilość opcji grsecurity można włączać i wyłączać, lub zmieniać ich wartości (np GID), dynamicznie bez potrzeby rekompilacji jądra; jest to możliwe poprzez mechanizm sysctl. Po zaznaczeniu opcji CONFIG_GRKERNSEC_SYSCTL, dla wiekszosci opisanych wyzej opcji pojawi sie pozycja w /proc/sys/kernel/grsecurity. Włączanie/wyłączanie odpowiednich możliwości odbywa się poprzez nadanie im wartości 0 lub 1. Przy niektórych (np GID), należy podać odpowiednie wartości. Najwygodniej odpowiednie wpisy umieścić w skryptach startowych, lub, jeśli nasza dystrybucja to obsługuje, w pliku /etc/sysctl.conf. Przykładowo, fragment takiego pliku może wyglądać tak:

kernel.grsecurity.socket_all = 1
kernel.grsecurity.socket_all_gid = 61000
kernel.grsecurity.socket_client = 1
kernel.grsecurity.socket_client_gid = 62000
kernel.grsecurity.socket_server = 1
kernel.grsecurity.socket_server_gid = 63000
			

Logi grsecurity W sekcji Miscellaneous Features określić możemy w jaki sposób maja się generować wpisy w dzienniku systemowym generowane przez grsecurity. Opcje te pozwalają uniknąć zbyt wielu wpisów.

Tego opisu nie należy traktować jako kompendium wiedzy o bezpieczenstwie w Linuksie. Jest to jedynie opis jednego narzędzia.Tylko od administratora będzie zależeć czy i jak go użyć.

Zupełnie został pomięty opis mechanizmu List Kontroli Dostępu - ACL dostępnego w grsecurity, ponieważ objętość takiego opisu znacznie przekraczałaby wielkość tego artykułu. Zainteresowanych odsyłam do opublikowanej niedawno dokumentacji ACL.

Artykuł ten możesz przeczytać również na stronie Słupskiej Grupy Użytkowników Linuksa - SLUG , gdzie znajdziesz zawsze aktualną jego wersję.
Jeśli zauważyłeś jakąś nieścisłość lub błąd, bądz masz sugestie co do tego artykułu, bardzo prosze o kontakt - wojrus@linux.slupsk.net.