Gentoo Hardened vs inne dystrybucje

To wszystko w kodzie źródłowym! Gentoo hardened to oparta na bezpieczeństwie dystrybucja, a wzmocniony profil naprawdę zawiera wiele, aby uczynić go naprawdę bezpiecznym.

Ale czy warto go kompilować? Duże pytanie na forach linuksowych.

Spójrzmy na wzmocniony profil Gentoo pod względem bezpieczeństwa:

a jednocześnie dodaje trochę secu jest tak mało, że w większości przypadków nie jest tego warte. Zapewnia większe bezpieczeństwo w dystrybucji binarnej, ponieważ każdy ma te same pliki binarne, a atakujący nie musi zgadywać, gdzie może zostać załadowany określony fragment kodu, ale dzięki uruchomieniu dystrybucji źródłowej Twoja przestrzeń adresowa jest już dość wyjątkowa. Jedyny przypadek, w którym zapewnia pewne bezpieczeństwo, gdy atakujący próbuje odgadnąć adres dla exploita, błędne odgadnięcie prawdopodobnie spowoduje awarię procesu i zostanie ponownie załadowane na nowy adres. Czy masz wystarczająco cenne dane, aby atakujący mógł przez to przejść kłopotów, aby go zdobyć? Jeśli to zrobisz, powinieneś użyć wzmocnionego profilu, ale bezpieczeństwo fizyczne i szyfrowanie dysku są ważniejsze, ponieważ jeśli jest to warte tyle, łatwiej będzie cię po prostu okraść.

Należy pamiętać, że nie ma wzmocnionego profilu dla komputerów stacjonarnych, więc sam w sobie utrudni korzystanie z niego na komputerze stacjonarnym.

Innym powodem jest to, że chcesz użyć czegoś takiego jak SELinux (który nie wymaga wzmocnionego profilu), który daje bardzo precyzyjną kontrolę nad kontrolą dostępu, ale jest również bardzo restrykcyjny. Myślę, że jest to tego warte tylko dla dużych sieci z wieloma użytkownikami i różnymi poziomami dostępu do poufnych danych.

Potrzebowałem niektórych funkcji SELinux, ale zdecydowałem się na używanie AppArmor w nietypowy sposób, aby je osiągnąć, ponieważ SELinux to zbyt duży problem. Wszystko, co naprawdę robi AppArmor, to izolacja procesów lub piaskownica. Jeśli atakujący uzyska dostęp przez eksplozję, będzie mógł uzyskać dostęp tylko do plików, do których ma dostęp wykorzystywana usługa. Używam go z przechwytywaniem wszystkich profili, które zapobiega wykonywaniu z wszystkich katalogów domowych i zapisywalnych na świecie oraz dostępu do kluczy ssh / pgp, kluczy itp. Działa to dobrze na serwerach i komputerach stacjonarnych i nie jest zbyt restrykcyjne. A jeśli potrzebuję wykonać kod z mojego katalogu domowego do programowania, mogę uruchom nieograniczoną powłokę przez sudo. Mogę zostawić swojego laptopa odblokowanego z otwartym portfelem (używam modułu kwallet pam) i będzie ci bardzo trudno uzyskać coś takiego jak klucze ssh lub hasła (mam też łatki do kwallet, więc wymaga hasła ord, aby wyświetlić zapisane hasła), ale programy, które ich potrzebują, mają do nich dostęp.

Ale co sprawia, że jest twardszy? spójrzmy również na niektóre z tych elementów:

• PaX to łatka na jądro, która chroni nas przed przepełnieniem stosu i sterty. PaX robi to za pomocą ASLR (randomizacja układu przestrzeni adresowej), która wykorzystuje losowe lokalizacje pamięci w pamięci. Każdy szelkod musi używać adresu, aby przeskoczyć do osadzenia w nim, aby uzyskać wykonanie kodu, a ponieważ adres bufora w pamięci jest losowy, jest to znacznie trudniejsze do osiągnięcia. PaX dodaje dodatkową warstwę ochrony, utrzymując dane używane przez program w niewykonalnym regionie pamięci, co oznacza, że atakujący nie będzie w stanie wykonać kodu, który zdołał zapisać w pamięci. Aby użyć PaX, musimy użyć jądra obsługującego PaX, takiego jak hardened-sources.
• PIE / PIC (kod niezależny od pozycji): Zwykle plik wykonywalny ma stały adres bazowy, gdzie są załadowane. Jest to również adres, który jest dodawany do RVA w celu obliczenia adresu funkcji wewnątrz pliku wykonywalnego. Jeśli plik wykonywalny jest skompilowany z obsługą PIE, może być załadowany w dowolnym miejscu pamięci, podczas gdy musi być ładowany pod stałym adresem, jeśli jest kompilowany bez obsługi PIE. PIE musi być włączone, jeśli chcemy używać PaX do korzystania z ASLR.
• RELRO (relokacja tylko do odczytu): Kiedy uruchamiamy plik wykonywalny, załadowany program musi zapisywać w niektórych sekcjach, które nie nie trzeba oznaczać jako zapisywalne po uruchomieniu aplikacji. Takie sekcje to .ctors, .dtors, .jcr, .dynamic i .got [4].Jeśli oznaczymy te sekcje jako tylko do odczytu, osoba atakująca nie będzie w stanie użyć pewnych ataków, które mogą być użyte podczas próby uzyskania kodu, takich jak nadpisywanie wpisów w tabeli GOT.
• SSP ( ochrona przed zniszczeniem stosu) jest używana w trybie użytkownika; chroni przed przepełnieniem stosu poprzez umieszczenie kanarka na stosie. Gdy atakujący chce przepełnić zwrotny adres EIP na stosie, musi również przepełnić losowo wybrany kanarek. Kiedy tak się stanie, system może wykryć, że kanarek został nadpisany, w którym to przypadku aplikacja zostaje zakończona, co uniemożliwia atakującemu przejście do dowolnej lokalizacji w pamięci i wykonanie kodu stamtąd.
• RBAC (kontrola dostępu oparta na rolach): Zwróć uwagę, że RBAC to nie to samo, co RSBAC, które przedstawimy później. RBAC to kontrola dostępu, z której mogą korzystać SELinux, Grsecurity itp. Domyślnie twórca pliku ma całkowitą kontrolę nad plikiem, podczas gdy RBAC wymusza kontrolę nad plikiem przez użytkownika root, niezależnie od tego, kto utworzył to. Dlatego wszyscy użytkownicy w systemie muszą przestrzegać reguł RBAC ustalonych przez administratora systemu.

Dodatkowo możemy również użyć następujących systemów kontroli dostępu, które służą do kontroli dostępu między procesami i obiekty. Zwykle musimy wybrać jeden z opisanych poniżej systemów, ponieważ w danym momencie może być używany tylko jeden z systemów kontroli dostępu. Do systemów kontroli dostępu należą:

• SELinux (Linux z podwyższonymi zabezpieczeniami)
• AppArmor (opancerzenie aplikacji)
• Grsecurity, który zawiera różne poprawki, które można zastosować do jądra, aby zwiększyć bezpieczeństwo całego systemu. Jeśli chcielibyśmy włączyć Grsecurity w jądrze, musimy użyć jądra obsługującego Grsecurity, które jest hardened-sources.
• RSBAC (kontrola dostępu oparta na zestawie reguł): Musimy używać jądra rsbac-sources zbudować jądro z obsługą rsbac.

Wszystko sprowadza się do wielkiego pytania, o którym mowa wcześniej? Warto kompilować? Naprawdę sprowadza się do tego, jak lub co zabezpieczasz i czy wysiłek jest wart zachodu? A może naprawdę będziesz w stanie zabezpieczyć to, czego nie chcesz widzieć wścibskich oczu?

Komentarze

• OK, dziękuję za wyjaśnienie wszystkich te technologie egzekwowania zabezpieczeń. Więc jeśli rozumiem twój punkt widzenia, te elementy są bardzo przydatne do poprawy bezpieczeństwa systemu; ale pytasz " czy warto kompilować? ". Dlaczego więc nie są one domyślnie włączone w niektórych głównych dystrybucjach? Czytałem, że PaX na pulpicie może zepsuć niektóre pliki binarne (słyszałem o javie lub firefoxie); czy to jedyny powód?
• Przyczyną, dla której PaX i grsecurity nie są domyślne w wielu dystrybucjach, jest polityka i ego. Twórcy obu z nich mają osobowości, które silnie kolidują z zespołem programistów jądra Linuksa. Oprócz tego nie chcą poświęcać czasu na podzielenie ich łatki na kawałki, które zostałyby zaakceptowane przez autorów, i zamiast tego poświęcają swój czas na opracowanie większej liczby funkcji bezpieczeństwa.
• Należy również pamiętać, że grsecurity jest nie jest systemem kontroli dostępu. Spender (twórca grsecurity) bardzo się irytuje, gdy ludzie nazywają to systemem kontroli dostępu, a następnie porównują go do SELinux. : P Grsecurity to kombinacja łatek na jądro, które zwiększają bezpieczeństwo jądra poprzez eliminację klas błędów. System kontroli dostępu RBAC, który ma, jest nieistotny w porównaniu z resztą. Funkcje bezpieczeństwa Grsecurity ' są tak rozbudowane, że zajmowałyby znacznie więcej miejsca, niż można by umieścić w jednym poście. Zajrzyj na grsecurity.net, aby zobaczyć dość obszerną listę.
• dodając pewne zabezpieczenia, ' jest tak mało, że ' w większości przypadków nie jest tego warte – Uh, to jest całkowicie niepoprawne. A bezpieczeństwo tak naprawdę nie ma nic wspólnego z ukrywaniem adresów. ' m zdumiony , że ta odpowiedź jest pozytywna.