Bezpieczny Linux to Linux wyposażony we właściwe łaty i kompetentnie skonfigurowany. Standardową dystrybucję Linuxa, tak jak dowolną standardową wersję dowolnego innego systemu operacyjnego, trudno uznać za bezpieczną.

W swoich początkach Internet był bardzo przyjaznym miejscem. Użytkownicy stanowili małą, elitarną grupę, w której panowało spore wzajemne zaufanie. Echa tego zaufania widać dzisiaj bardzo dosadnie w słabościach wykorzystywanych powszechnie protokołów sieciowych, które wtedy właśnie opracowywano. Podstawowe zasady rządzące nimi oraz wynikające z nich problemy, takie jak niechciana poczta (spam), podszywanie się (spoofing) czy zalewanie pakietami powodujące niestabilność bądź niedostępność systemu (flooding), przyprawiają dziś o ból głowy administratorów i użytkowników sieci.

Podobnie sprawa miała się z bezpieczeństwem serwerów i komputerów. Niby zdawano sobie sprawę, że włamanie jest możliwe, ale prawie nikt się tym nie przejmował, bo przecież "wszyscy się znamy i obowiązują zasady". Niestety z czasem, gdy Internet zaczął rozwijać się lawinowo (mniej więcej dwukrotny przyrost liczby maszyn podłączanych w każdym roku), krąg jego użytkowników zaczął obejmować również osoby o mniej przyjaznym nastawieniu. Jednocześnie próba ukrycia się w gęstwinie hostów stawała się coraz łatwiejsza. Filozofia hit and run wymusiła zatem na twórcach systemów operacyjnych wypracowanie nowych zasad obrony.

Spuścizna i tradycja

Systemy Linux, a także większość systemów unixopodobnych, takich jak rodzina BSD, zawsze fascynowały. Ich instalacja, konfiguracja i wdrażanie na początku ich kariery zarezerwowana była jedynie dla wąskiej grupy specjalistów. W tej chwili w większości posiadają one rozbudowane graficznie narzędzia instalacyjne, dzięki czemu ich wdrożenie zaczyna przypominać operację znaną z Windows. Błędem byłoby jednak myśleć, że w dziedzinie bezpieczeństwa taki automatyzm w czymkolwiek pomaga. W dalszym ciągu potrzeba odpowiedniej wiedzy do przeprowadzenia właściwej, czyli bezpiecznej konfiguracji, pozostaje w pełnej mocy.

Linux praktycznie od zarania opierał się, podobnie jak jego pierwowzór, na modelu bezpieczeństwa DAC (Discretionary Access Control). Polegał on, mówiąc w dużym skrócie, na polityce określonej przez użytkownika zasobu (np. pliku). To właściciel określał, kto i jak może postępować z zasobem. Nad nim stał jeszcze root, czyli "systemowy wszechmogący". Takie podejście okazuje się jednak źródłem kłopotów. Jeśli przechwycimy, np. wykorzystując podatność na przepełnienie bufora, działanie procesu z prawami roota (w wielu przypadkach takie prawa są potrzebne bardzo wielu procesom, często tylko na chwilę, ale jednak), uzyskujemy nieograniczony dostęp praktycznie do całego systemu, a więc całkowity wpływ na jego działanie.

Kłopot ze standardowymi mechanizmami bezpieczeństwa w systemach unixowych zaowocował pojawieniem się bezpiecznych Unixów, a później także bezpiecznych Linuxów. Czyżby więc Unix i Linux nie były aż tak bezpieczne, jak się powszechnie słyszy? Coś w tym jest - systemowi DAC opisanemu powyżej daleko do doskonałości. Niepokój budzi już choćby istnienie konta, którego uprawnienia są nieograniczone, a które musi być co jakiś czas użyte, np. w celu zaalokowania portu sieciowego.

Także i w aplikacjach działających w tych systemach można spodziewać się niedociągnięć, które pozwalają na zmianę toru ich działania dzięki wykorzystaniu określonych technik nadużyć. Scenariusze takie jak wyścig (race condition), przepełnienie stosu (stack overflow) lub sterty (heap overflow) albo np. ciągi formatujące (formatting string) to nadużycia, których pomimo ciągłego doskonalenia kodu od lat nie udaje się uniknąć. Najlepszy przykład to system pocztowy Sendmail. Nadużycia takie pozwalają z kolei na wykonywanie kodu z prawami administratora, które jest przyczyną wszelkich problemów.

Zrobić, co zrobić trzeba

Twórcy "bezpiecznych linuxów" starają się wyplenić z Linuxa praprzyczyny problemów z bezpieczeństwem. W większości przypadków owo utwardzanie polega na modyfikacji standardowej dystrybucji, w przeważającej mierze za pomocą metod czystko konfiguracyjnych (a dodatkowo poprzez łaty na jądro systemu). Do tego wystarczy zmienić nazwę, dodając słowo trusted lub hardened - i gotowe, co nie znaczy, że wartość takiego rozwiązania jest znikoma - wręcz przeciwnie. Takie podejście reprezentuje kilka niezależnych od siebie projektów open source, pokrywających funkcjonalnie mniej więcej to, czego potencjalni użytkownicy sobie życzą.

Tego rodzaju projekty są od siebie podobne, także pod tym względem, że nie zaspokają wszystkich potrzeb użytkowników. Jeśli chodzi o ochronę przed wykorzystaniem niewłaściwego działania aplikacji (jak różnego typu "przepełnienia") wykorzystywane są powszechnie dostępne łaty na jądro Linuxa, eliminujące lub minimalizujące ryzyko wystąpienia takiego problemu. Tu warto wskazać projekt OpenWall lub projekt GrSecurity, a dokładniej sekcję PaX.

Remedium na drugą bolączkę, czyli istnienie konta "systemowego wszechmogącego", jest zastosowanie zmodyfikowanej filozofii zasad dostępu - MAC (Mandatory Access Control). Tutaj można wymienić takie projekty, jak SE Linux, RSBAC, LIDS, a także GrSecurity. Filozofia ta, w uproszczeniu, określa zasady dostępu (np. przez listy dostępowe lub tzw. role systemowe) do zasobów określone z góry przez system operacyjny, a nie przez użytkownika.

Reguły tworzenia ról są konserwatywne i polegają na uniemożliwieniu wykonania czegokolwiek, by następnie odblokować jedynie uprawnienia niezbędne do poprawnego funkcjonowania w określonej roli. W takich systemach root, czyli administrator "wszechmogący" traci swoje nieograniczone uprawnienia. Mówiąc ściślej, konto superużytkownika pozostaje, jednak służy wyłącznie do definiowania uprawnień pozostałych użytkowników, w tym także i roota. Przywileje takiego użytkownika konstruowane są jednak w taki sposób, by nie można z nich było skorzystać w trakcie normalnego, codziennego funkcjonowania systemu, a w konsekwencji, aby przejęcie jego uprawnień było praktycznie niemożliwe.

Będąc bezpiecznym, Linux wciąż może być jeszcze bardziej bezpieczny. Jeśli intruz przepełni bufor i wykona na stosie swój kod, stanie w sytuacji, w której będzie mógł zrobić tylko to, na co pozwalają mu listy dostępowe. Przy właściwej konfiguracji nie powinny pozwalać na zbyt wiele. Opisane tu dwa poziomy zabezpieczeń działają więc w dwu różnych płaszczyznach i wzajemnie się uzupełniają. Dopiero połączenie łat na system z restrykcyjnym podejściem do uprawnień stanowi solidne wzmocnienie konstrukcji systemu pod względem bezpieczeństwa.

Niechęć do niezwykłego

Dlaczego zatem, pomimo udowodnionej skuteczności, stosowanie tych dwu technik nie jest powszechne? Dlaczego trzeba sięgać po specjalizowane dystrybucje? Być może świadomość i wiedza fachowa wciąż nie są na poziomie, który pozwalałby na wykonanie pewnych operacji samodzielnie bez obaw o pomyłkę. Wciąż nie doczekaliśmy się (może poza SE Linuxem) integracji takich rozwiązań w oficjalnych wydaniach kernela, mamy więc do czynienia z wiedzą tajemną skrzętnie chronioną przez firmy zajmujące się usługami wdrożeniowymi.

Pozostaje także problem instalacji i konfiguracji zasad dostępu. Choć istnieją gotowe do wykorzystania schematy list dostępowych lub specjalne mechanizmy generujące takie listy, wciąż potrzeba dużego nakładu pracy, chęci i wiedzy, aby docelowy system właściwie skonfigurować. Właściwie oznacza tu nie tylko bezpiecznie, ale także w sposób, który nie zaburzy pracy ważnej aplikacji, np. serwera bazy danych.

Brak powszechnego zainteresowania utwardzonymi wersjami Linuxa jest także wynikiem tego, że wiele firm po prostu nie odczuwa potrzeby dodatkowego zwiększania poziomu bezpieczeństwa, co nie znaczy, że ich nie potrzebują. Firmy zadowalają się najczęściej najnowszymi wersjami w przekonaniu, że jest to rozwiązanie dla nich dostatecznie bezpieczne. Są i powody czysto biznesowe: po co zatrudniać specjalistę z prawdziwego zdarzenia do instalacji i konfiguracji "bezpiecznego Linuxa" skoro "zwykły Linux" zainstaluje nam szybko i tanio znajomy informatyk. W małych firmach to norma, w większych myślenie (na ich szczęście) ewoluuje w kierunku stosowania systemów maksymalnie zabezpieczonych.

Wielki skok wciąż daleko

W ostatnich latach w sferze "bezpiecznego Linuxa" wydarzyło się tak naprawdę stosunkowo niewiele. Wciąż jego koncepcja opiera się na pomysłach i założeniach wypracowanych jeszcze w poprzednim wieku. Zwolennicy Windows mogliby z tego wyciągnąć wniosek, że oto Windows w ostatnich latach ewoluował pod względem bezpieczeństwa, a Linux stoi w miejscu. To jednak tylko ekwilibrystyka, bo poziom, z którego Windows startował, był delikatnie mówiąc, żenujący.

Nie można przy tym nie zauważyć, że w systemach Windows powoli pojawiają się koncepcje, które w Linuxie istnieją jeśli nie od zarania, to przynajmniej od bardzo wielu lat. Mechanizmy uniemożliwiający wykonywanie stosu co do koncepcji zgodne z rozwiązaniami PaX i OpenWall, a wprowadzone niedawno domyślne wyłączanie usług i wymuszanie ich włączania przez administratora również ma w świecie Linuxa długie tradycje.

Ani świat open source, ani też świat komercyjny nie dokonały dotychczas żadnego wielkiego przełomu w dziedzinie bezpieczeństwa systemów. Być może przy dzisiejszym stanie wiedzy i dorobku informatyki niewiele nowego da się wymyślić. Być może wielki skok jakościowy w tej dziedzinie będzie możliwy dopiero wtedy, gdy całkowicie od podstaw opracowany zostanie nowy model systemu operacyjnego, bezpieczny z definicji. Czy jednak znajdą się chętni, by na taki system pisać aplikacje, które będą spełniać wyśrubowane wymagania? Być może system idealnie bezpieczny to system bez aplikacji, a więc... absurd?