Wprowadzenie do Gentoo HardenedNiniejszy przewodnik powstał z myślą o tych, którzy nie są pewni co tak naprawdę oferuje projekt Gentoo Hardened, jak korzystać z dostępnych opcji i jakie role pełnią one w projekcie. Opieramy się na filarze jaki stanowią warstwy bezpieczeństwa. Warstwy te mają zapewnić, że maszyna użytkownika nie zostanie skompromitowana, a jeśli już, to uszkodzenia zostaną zminimalizowane. Łącząc szereg różnorodnych, choć powiązanych z bezpieczeństwem technologii, sprawiamy, że agresor będzie musiał pokonać dodatkowe przeszkody zanim będzie w stanie skompromitować system. Sugerujemy, by określić wymagania, a następnie wykorzystać przedstawione rozwiązania do zabezpieczenia systemu. W tym podręczniku staramy się wyjaśnić dostępne możliwości oraz nakreślić sposoby w jakie mogą zostać użyte. Gentoo Hardened, samo w sobie, nie jest produktem, ani rozwiązaniem. Jest to po prostu projekt zrzeszający grupę developerów, którzy dążą do tego samego celu, jakim jest niezwykle prewencyjne bezpieczeństwo. Podprojekty Gentoo Hardened nie są ze sobą bardziej powiązane, niż przez sam fakt umieszczenia we wspólnym projekcie. Można o tym myśleć w ten sam sposób jak o KDE i GNOME. Obydwa stanowią część projektu dekstop, obydwa mają analogiczne cele, lecz pod innymi względami nie są ze sobą powiązane.
Serce projektu stanowi PaX. PaX jest łatą na kernel, która pozwala zabezpieczyć się przed atakami opartymi o przepełnienie bufora, sterty i podobnymi. PaX jest pierwszą linią obrony. Źle napisane programy zawsze generują ryzyko kompromitacji, gdyż mogą być podatne na przepełnienia stosu i sterty. Możliwość przepełnienia stosu oraz sterty to efekt braku sprawdzania ograniczeń dla danych przekazywanych do aplikacji. Jeśli tylko agresor ma możliwość wprowadzenie danych do programu, które są umieszczane w pamięci i nie są weryfikowane, to istnieje możliwość przepełnienia. Niskopoziomowe języki programowania, takie jak C i C++, nie chronią w sposób automatyczny przed tego rodzaju zachowaniem. W efekcie, gdy bufor jest przepełniany, sąsiadujący z nim kod może zostać nadpisany przez dane, które wprowadzi użytkownik. Jeśli dane wprowadzone przez użytkownika są niezrozumiałe dla komputera, to w większości sytuacji prowadzi to do zawieszenia się aplikacji. Objawia się to przez page fault (przyp. tłum. wygenerowanie informacji o stronie pamięci), gdyż znaki przepełniające bufor i zapisane w przestrzeni wykonywania zostaną potraktowane jako adres pamięci, który prawdopodobnie nie istnieje. Takie zachowanie stanowi najłagodniejszy efekt nadpisania. Agresor, który wie o przepełnieniu, ma możliwość dodania shellcode do wprowadzanych danych i zamiast doprowadzić do zawieszenia się aplikacji jest w stanie wymusić wykonanie się przekazanych instrukcji. Dzieje się tak, gdyż shellcode, to sposób w jaki instrukcje przeznaczone do wykonania przechowywane są w pamięci. Ogólnie mówiąc, shellcode składa się z kodów rozkazów (ang. opcodes), które składają się na fragmenty procedur. Agresor doskonale zna te kody i może tworzyć shellcode, który pozwala mu na zrobienie wszystkiego co zechce. Może być to uruchomienie powłoki z prawami roota i udostępnienie jej na określonym porcie. Użytkownik nawet nie będzie świadomy, że coś jest nie tak, gdyż aplikacja nie zawiesi się, lecz zamiast tego zacznie wykonywać kod przekazany przez agresora. PaX łagodzi powyższy problem, przez losowe umieszczanie każdego bufora i funkcji w pamięci aplikacji. Metoda ta znana jest jako ASLR (Address Space Layout Randomization - losowy rozkład przestrzeni adresowej) i stanowi fundament PaX. Losowe przesunięcia dla funkcji i buforów, sprawiają że, agresor nie jest w stanie przygotować danych, które zagwarantują, że shellcode zostanie wykonany (zadanie jest bardzo utrudnione, gdyż aplikacja prawdopodobnie zawiesi się i zostanie ponownie uruchomiona z nowymi losowymi przesunięciami). ASLR jest najbardziej użyteczny w połączeniu z PIE (Position Independent Executable - kod niezależny od pozycji), ale działa także ze standardowym kodem wykonywalnym, lecz przy pewnym narzucie na wydajność.. PaX daje możliwość rozdzielenia praw dla segmentów pamięci, tj. segment może mieć atrybut wykonywania, ale brak możliwości zapisu, i podobnie, może być zapisywalny, ale kod z tego segmentu nie może być wykonywany. Jest to znane pod nazwą pageexec. Na procesorach x86 nie ma do tego wsparcia sprzętowego, gdyż projektanci x86, aby zaoszczędzić miejsca, połączyli flagi pamięci read/execute w jedną. Jako że strona może być zapisywalna albo dostępna do odczytu i wykonywania, to nie ma sensu ustawiać atrybutu non-executable dla buforów, gdyż wtedy przestaną być dostępne do odczytu. Dlatego na maszynach x86, PaX emuluje takie zachowanie na poziomie programowym. Wprowadza to narzut na wydajność, ale jest bardzo użyteczne dla bezpieczeństwa. Dla zachowania przejrzystości: łączymy dyskusję o PIE i SSP, gdyż stanowią element toolchain w wersji hardened. Tak naprawdę są to różne technologie, którym przyświecają inne cele. PIE samo z siebie nie wprowadza dodatkowego bezpieczeństwa, jednakże w połączeniu z PaX dostarcza potężnego narzędzia przeciwko przepełnieniom. SSP jest całkowicie zaimplementowane jako część funkcjonalności w przestrzeni użytkownika i zabezpiecza przed atakami na stos ([ang.] stack smashing attack), bez asysty kernela. Ze względu na to, że wymienione technologie są zaimplementowane oddzielnie i wykonują różne działania, to stanowią dwie różne warstwy zabezpieczeń, np. atak ret2libc, który mógł przejść przez PAX, może zostać zablokowany przez SSP. Pokonaliśmy długą drogę, by dostarczyć użytkownikom łatwego sposobu na zbudowanie całej przestrzeni użytkownika z kodem ze wsparciem PIE, tak by było możliwe skorzystanie przy niewielkim narzucie wydajnościowym z dobrodziejstw ASLR. Poza PIE, nasz tolchain w wersji hardened dostarcza także zabezpieczenia SSP (stack smashing protection). SSP chroni przed atakami na stos. Robi to przez zarezerwowanie pamięci na zewnątrz buforów i wstawiając tam losowy, krypograficzny znacznik. Pozwala to na sprawdzenie po jakimkolwiek zapisie do bufora, czy znacznik został nadpisany, i jeśli tak się stało, to aplikacja może zostać zakończona. Toolchain w wersji hardened, dostarcza wsparcie dla PIE/SSP w przestrzeni użytkownika, w najprostszy możliwy sposób. Pliki stage oznaczone jako 'hardened' są standardowymi plikami stage zbudowanymi ze wsparciem dla PIE i SSP, nie zawierają kontroli dostępu SELinux/RSBAC/grsecurity. Podczas gdy PaX jest pierwszą warstwą zabezpieczeń, a nawet drugą lub trzecią, jeśli posiadamy firewall i/lub system detekcji intruzów, to do dalszego zabezpieczenia systemu, zalecamy używania list kontroli dostępu. Niezmiernie ważne jest zdanie sobie sprawy z tego, że listy kontroli dostępu stanowią ostatnią warstwę zabezpieczeń. Listy kontroli dostępu są bardzo pomocne przy powstrzymywaniu działań lokalnych użytkowników lub agresora, który uzyskał dostęp do systemu. Gentoo Hardened oferuje obecnie trzy rozwiązania do kontroli dostępu: SELinux, grsecurity i RSBAC. Jeśli chcemy korzystać z grsecurity, to nie musimy się martwić o etapy, gdyż grsecurity nie wymaga zmian w przestrzeni użytkownika. Używamy po prostu plików stage pie-ssp i gdy jesteśmy gotowi, by zbudować kernel, używamy źródeł z włączonym grsecurity, takich jak hardened-sources. Jak tylko system zostanie uruchomiony, możemy użyć trybu nauki grsecurity, by zbudować listy kontroli dostępu dla naszego systemu. Podobnie jak grsecurity, RSBAC nie wymaga żadnych zmian w przestrzeni użytkownika i może być ustawiony po standardowej instalacji Gentoo. RSBAC jest wspierany przez kernel z pakietu rsbac-sources kernel. Po uruchomieniu systemu możemy wybierać spośród różnych modeli kontroli dostępu oferowanych przez RSBAC. Jest to możliwe dzięki budowie modułowej. W dokumentacji Gentoo dla RSBAC wymieniona jest lista oferowanych modeli, a także, o każdym z nich, dostępne jest więcej informacji. Omówiliśmy dwie obecnie dostępne warstwy. Mamy zamiar zaoferować ich więcej i tak zrobimy w przyszłości. Przykładami dodatkowych warstw są warstwa wykrywania/zapobiegania, która znalazłyby się przed PaX. Zaszyfrowane dyski oraz partycje wymiany, które zabezpieczają przed 'fizycznymi' naruszeniami bezpieczeństwa. Audyt pozawalający dostrzec i zareagować na istniejące luki, zanim stałyby się przyczyną kompromitacji systemu. Szyfrowanie ruchu sieciowego i silne mechanizmy autentykacji, są także warstawi, które są wspierana w głównej linii instalacji Linuksa i prawdopodobnie nie będą tu poruszane.
|
|