OpenWall Linux
15
marca 2004
Tomasz Grabowski
OpenWall
Linux (Owl) to dość wyjątkowa dystrybucja Linuksa. Głównym celem, który przyświeca
tworzącemu ją zespołowi jest stworzenie systemu, zapewniającego maksymalny poziom bezpieczeństwa
zaraz po zainstalowaniu, bez dodatkowych konfiguracji. W porównaniu więc do takich dystrybucji jak Debian czy
Redhat, Owl zawiera tylko podstawowe usługi, które są niezbędne do działania systemu. Nie znajdziemy
tu standardowo uruchomionego serwera FTP, WWW czy telnetu. Zamiast tego administrator ma do dyspozycji w pełni funkcjonalny
system, na którym może zacząć instalować i konfigurować niezbędne usługi. Wydawać
by się mogło, że takie rozwiązanie nie jest atrakcyjne z punktu widzenia użytkownika. Okazuje się
jednak, że o ile w zastosowaniach domowych Owl zupełnie by się nie sprawdził, o tyle jako podstawa do
serwerów dedykowanych do pojedynczych usług, takich jak FTP, serwer poczty czy WWW, nadaje się znakomicie.
Jego atutami są bowiem szybkość instalacji oraz niespotykany w innych dystrybucjach poziom bezpieczeństwa.
Zwykle twórcy dystrybucji Linuksa nie przejmują się poziomem bezpieczeństwa oferowanym przez
pakiety, które wręcz na wyścigi dodają do swoich dystrybucji. Cała ich energia związana z
bezpieczeństwem systemu skupiona jest na usuwaniu pojawiających się błędów. Takie podejście
nie jest dobre z punktu widzenia administratora systemu. Wybierając oprogramowanie, którego chce on użyć
na swoim serwerze, musi kierować się głównie własną intuicją. Niektórzy czytelnicy
być może uznają, że zamiast słowa „intuicja” powinienem był użyć określenia
„wiedza” lub „doświadczenie”. Niestety w praktyce większość tego typu decyzji
podejmowana jest na podstawie obiegowych opinii o danym oprogramowaniu bądź też ilości znalezionych w
nim w przeszłości błędów. Dane takie obarczone są jednak wieloma błędami i nie zawsze
prowadzą do właściwych wniosków. Ponadto czasem, mając nawet duże doświadczenie w tej
dziedzinie, decyzja taka nie jest prosta. Dla przykładu, instalując serwer poczty, administrator przykładający
duża wagę do bezpieczeństwa swojego systemu raczej nie zdecyduje się na instalowanie Sendmaila. Jednak
już stanowczy wybór pomiędzy Postfixem, Eximem czy Qmailem staje się problemem. Trzeba by zaglądnąć
w kod tego oprogramowania, sprawdzić w jaki sposób jest pisane, czy autor zwraca uwagę na bezpieczeństwo.
Jednym słowem bez przeprowadzenia audytu bezpieczeństwa wybór pomiędzy tymi serwerami poczty będzie
się opierał głównie na intuicji administratora.
Tworzenie dystrybucji Owl zapoczątkował
Solar Designer – osoba dobrze znana w branży związanej z bezpieczeństwem w sieciach komputerowych. Podszedł
on do zagadnienia w zupełnie odmienny sposób. Zamiast skupiać się na eliminowaniu pojawiających
się błędów, postanowił on stworzyć dystrybucję, która od razu zawierałaby
najbezpieczniejsze oprogramowanie i najskuteczniejsze zabezpieczenia. Polityka włączania oprogramowania do OpenWall
Linux jest więc bardzo restrykcyjna. Każdy program, który działa z uprawnieniami roota lub też
jako demon nasłuchuje na jakimś publicznie otwartym porcie, jest dokładnie sprawdzany. Nawet, jeśli kod
programu nie zawiera żadnych konkretnych błędów, ale pisany jest w sposób budzący wątpliwości,
oprogramowanie nie jest włączane do dystrybucji. Jeśli dany program przejdzie wstępna selekcję, rozważane
są możliwości zwiększenia poziomu jego bezpieczeństwa. Osiągane jest to np. za pomocą pisania
odpowiednich patchy, które powodują np. tzw. separację przywilejów. Dokładniej opisane jest to
na przykładzie oprogramowania popa3d w ramce „Separacja przywilejów”. Oprócz tego tworzone
są specjalne dzienniki audytów dołączone do każdego pakietu oprogramowania, po przeczytaniu których
możemy zdecydować czy zapewniany przez dany program poziom bezpieczeństwa nam odpowiada.
Jest to więc
pierwsza dystrybucja Linuksa, której oprogramowanie jest sprawdzane pod kątem bezpieczeństwa zanim zostanie
do niej dodane. Używając programów zawartych standardowo w dystrybucji mamy więc pewność,
że korzystamy z najbezpieczniejszego obecnie zestawu narzędzi OpenSource. Oczywiście oprócz oprogramowania
dołączonego standardowo, mamy możliwość instalacji także dowolnych innych programów.
Mogą to być pakiety RPM (znane z dystrybucji RedHat Linux) oraz oczywiście oprogramowanie kompilowane ze źródeł.
Czy jednak w takiej sytuacji korzystanie z Owl ma jeszcze jakieś uzasadnienie? Okazuje się, że tak. Do dystrybucji
dodano bowiem wiele interesujących ulepszeń, zwiększających poziom bezpieczeństwa całego systemu.
Znajdziemy tu między innymi patch na kernel, dzięki któremu wykonanie niektórych rodzajów ataków
jest bardzo utrudnione lub wręcz uniemożliwione. Pakiet tcb, którego autorem jest Polak Rafał Wojtczuk,
umożliwia zastąpienie niezbyt udanej koncepcji przechowywania haseł w pliku /etc/shadow, bezpieczniejszą
metodą zakładania plików z hasłami osobno dla każdego użytkownika. Rozwiązanie to jest
całkowicie przezroczyste dla starych aplikacji i nie wymaga ich rekompilacji. Standardowe serwisy systemowe, takie jak
Crond, Syslogd czy Klogd zostały odpowiednio przerobione w taki sposób, aby ewentualne zawarte w nich błędy
nie wpłynęły na bezpieczeństwo całego systemu. Dodatkowo część pakietów została
specjalnie na potrzeby Owl przeniesiona z systemów z rodziny *BSD.
Instalacja OpenWall Linux może się
na początek wydać dość skomplikowana. Jest to niestety wynikiem raczej skąpej dokumentacji. Jednak
już po pierwszej udanej instalacji wszystko staje się oczywiste i stawianie kolejnych serwerów nie trwa dłużej
niż kilkanaście minut. Całość instaluje się z płytki CD, lub przy wykorzystaniu wcześniejszej
instalacji Owl – nie ma niestety na razie możliwości instalacji przez sieć, aczkolwiek autorzy zapowiadają
dodanie takiej opcji w przyszłości. Pierwszą dużą różnicę w stosunku do innych dystrybucji
Linuksa widać już po pierwszym wystartowaniu systemu. Jedyny demon, który otwiera publiczny port to OpenSSH.
Nie ma tu żadnych chargen, daytime, echo i innych temu podobnych niepotrzebnych usług. Jeśli chodzi o ilość
standardowo instalowanych programów z ustawionym SUID’em (takie programy działają z innymi przywilejami
niż te, które ma użytkownik uruchamiający dany program) to jest to ograniczone do absolutnego minimum.
Jednym słowem system nie wymaga po prostu żadnych dodatkowych konfiguracji mających na celu podniesienie poziomu
jego bezpieczeństwa (tzw. „system hardening”). Aby skorzystać z dodatkowego oprogramowania znajdującego
się w OpenWall Linux, musimy pobrać je ze strony FTP projektu (lub któregoś z jej mirrorów np.
w Polsce), a następnie wydać np. polecenie „make buildworld”. W ten sposób system skompiluje
całe dostępne oprogramowanie, zaaplikuje odpowiednie patche i stworzy pakiety RPM. Możemy następnie zainstalować
je wszystkie za pomocą polecenia „make installworld” lub też wybrać z nich tyle te, które
są nam aktualnie potrzebne. Standardowo każdy pakiet zostanie skonfigurowany w jak najbezpieczniejszy sposób,
np. serwer FTP będzie zezwalał tylko na logowanie się anonimowych użytkowników, a serwer poczty
będzie się zajmował dostarczaniem tylko poczty lokalnej. Administrator ma więc pełną kontrolę
nad tym, co działa w jego systemie, gdyż aby zezwolić programowi na potencjalnie niebezpieczną rzecz,
musi to świadomie włączyć w odpowiednim pliku konfiguracyjnym. O ile dla doświadczonego administratora
nie jest żadnym problemem, o tyle dla kogoś początkującego stanowi to dużą przeszkodę.
Przy instalowaniu każdego dodatkowego pakietu musi on bowiem skonfigurować go zgodnie ze swoimi wymaganiami. Na
pewno nie można więc nazwać Owl-a systemem przyjaznym dla użytkownika. Nie chodzi tu tylko o samą
instalację, ale także o późniejszą eksploatację. Przykładowo, domyślna wartość
umask w OpenWall Linux to 077. Oznacza to, że jeśli stworzymy w nim jakiś plik, to nie będzie on dostępny
dla nikogo oprócz jego właściciela. Użytkownicy innych dystrybucji są przyzwyczajeni, że każdy
stworzony przez nich plik jest od razu dostępny także wszystkim innym użytkownikom. Różnica ta
może więc powodować wiele problemów np. w różnego rodzaju skryptach i programach. Przykłady
takie można mnożyć.
Kto więc powinien rozważać zastosowanie OpenWall Linux? Przede wszystkim
administratorzy systemów, które świadczą usługi typowo publiczne (np. serwer FTP, poczty, grup
dyskusyjnych, DNS). Owl zawiera już w sobie oprogramowanie niezbędne do postawienia takiego serwera. Biorąc
pod uwagę to wszystko, co zostało napisane powyżej, możemy mieć pewność, że zdecydowana
większość błędów pojawiająca się w oprogramowaniu Linuksowym po prostu nie będzie
nas dotyczyła. Nawet, jeśli nie zdążymy na czas zainstalować odpowiedniego patcha, pozostałe
mechanizmy zawarte w OpenWall Linuks prawdopodobnie i tak uchronią nas przez całkowitą kompromitacja systemu.
Za przykład niech posłuży fakt, że mimo iż w lutym tego roku pojawiło się kilka nowych
błędów w kernelach z rodziny 2.4.x, to użytkownicy jądra 2.4.23-ow2 z dystrybucji OpenWall Linux
datowanego na 5 stycznia, nie są na te błędy podatni.
Oprócz serwerów publicznych warto
też rozważyć możliwość użycia Owl-a w systemach wieloużytkownikowych, w których
bezpieczeństwo odgrywa bardzo ważną rolę. Użytkownicy, którzy mają świadomość,
że pracują na systemie na którym znajdują się bardzo ważne dane, na pewno będą bardziej
wyrozumiali w stosunku do zabezpieczeń stosowanych w Owl-u.
OpenWall Linux doskonale nada się także jako
serwer wewnątrz firmy, przechowujący np. bazy danych, z których korzystają komputery pracowników.
We wszystkich powyższych przypadkach szybkość instalacji Owl-a oraz zapewniany przez niego wysoki poziom
bezpieczeństwa przełoży się na konkretne korzyści dla firmy oraz administratora.
Nie wolno jednak
zapominać o tym, że w zasadzie każde dodatkowe zabezpieczenie wiąże się najczęściej
z utratą pewnej funkcjonalności. Nie inaczej jest też w przypadku Owl-a. Mimo, że znaczna część
zastosowanych tutaj zabezpieczeń jest przeźroczysta dla użytkownika i aplikacji to jednak trudno polecać
ten system do użytku domowego czy też jako serwer świadczący wiele usług na raz. W obu tych przypadkach
ilość czasu potrzebna na instalację i konfigurację dodatkowych pakietów oprogramowania (spoza Owl-a)
może być znacząca. W takiej sytuacji lepsze efekty osiągnie się instalując taką dystrybucję
jak Debian bądź RedHat, a następnie podnosząc jej poziom bezpieczeństwa stosując odpowiednie
patche i wyłączając niepotrzebne usługi.
Z całą pewnością jednak OpenWall Linux
jest systemem, o którym należy pamiętać instalując kolejny serwer w firmie. W przypadku niektórych
zastosowań jego atuty są bowiem trudne do przecenienia.
RAMKA „Seperacja przywilejów”.
Schemat ze strony:
http://www.openwall.com/presentations/Owl/mgp00016.html
Niektóre programy
muszą działać z przywilejami użytkownika root. Jest im to potrzebne np. do nasłuchiwania na niektórych
portach lub dostępu do plików systemowych. Oczywiście większość operacji, które takie
programy wykonują, może być z powodzeniem przeprowadzana przy użyciu mniejszy przywilejów (np.
niebezpieczne zazwyczaj działania na łańcuchach znaków). Okazuje się, że w praktyce można
dość skutecznie podzielić program na te wątki, które potrzebują praw administratora, oraz
te, które tych praw nie potrzebują. Na schemacie widzimy przykład separacji przywilejów w oprogramowaniu
popa3d, służącym do odbierania poczty. Program startuje z prawami roota, jednak od razu dzielony jest na dwa
wątki. Pierwszy wątek zaczyna nasłuchiwać na porcie 110, a następnie zostaje zamknięty w katalogu
/var/empty oraz pozbywa się swoich praw administratora. W takim stanie czeka na połączenia od użytkowników.
Jest to jedyna część programu widziana z zewnątrz. Jeśli znalazłby się z niej jakikolwiek
błąd pozwalający na przejęcie kontroli nad programem, to atakujący otrzymałby tylko i wyłącznie
dostęp do katalogu /var/empty. Nic poza tym. W przypadku, gdy z programu korzysta prawowity użytkownik, po przesłaniu
loginu i hasła, dane te przesyłane są do drugiego wątku. Ten działa nadal z prawami roota. Tworzy
więc kolejny wątek, który tym razem zajmuje się tylko weryfikacją podanych danych. Jeśli i
ten krok zakończy się sukcesem (użytkownik podał właściwy login i hasło) to program pozbędzie
się już ostatecznie przywilejów administratora, przyjmie przywileje konkretnego użytkownika i zezwoli
na dalszą komunikację. Jak widać ilość kodu programu, który jest wykonywany jako użytkownik
root, została zdecydowanie zmniejszona. Prawdopodobieństwo wystąpienia krytycznego błędu bezpieczeństwa
jest dużo niższe, a ewentualny audyt kodu staje się dużo prostszy, gdyż najbardziej zagrożone
fragmenty kodu stanowią zaledwie kilka procent całości.