HomeAbout MeSecurityDCLinuxEee PCMusic3D GraphicsRobotsContact Me

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.