W

szystkie firmy wydające własną dystrybucję (tj. zestaw programów rozpowszechnianych łącznie i dający po zainstalowaniu gotowy do użycia system) walczą o to, aby ich produkt był bezpieczny. Można stwierdzić, że każdy system jest na tyle bezpieczny, na ile odpowiednie środki zastosuje jego użytkownik. Wiele osób nie korzysta z dostarczonych im wraz z systemem metod zabezpieczania swoich danych. Największym problemem jest wyuczenie tej dyscypliny u użytkowników systemu. Kiedy istnieje przypadek, gdy obdarzamy swoim powszechnym zaufaniem wybraną dystrybucję, a ona zawodzi – rozpoczyna się przysłowiowe “polowanie na czarownice”. Wówczas twórcy, instytucje, programiści, autorzy oraz inne osoby odpowiedzialne za stworzenie samej funkcjonalności systemu stają się obiektem krytyki, zarzutów i ataków ze strony sfrustrowanej grupy użytkowników. Wykrycie luk w mechanizmach zabezpieczeń wywołuje dokładnie te same reakcje. Czy uzasadnione?

     Bezpieczeństwo zawsze było kompromisem pomiędzy wygodą poruszania się i funkcjonalnością, a kontrolą dostępu i eliminacją zagrożenia. Jest ono odwrotnie proporcjonalnie do komfortu oraz ułatwionego dostępu. Oczywiście w tym względzie pod pojęciem bezpieczeństwa kryje się ochrona danych oraz odporność systemów na awarie wynikające z ich nieuniknionej zawodności. Standardowy poziom bezpieczeństwa jest podnoszony z roku na rok, a w jego terminologii jest wykluczone tylko jedno wyrażenie: “całkowicie”. Prawidłowym stwierdzeniem w tym wypadku by było, że całkowicie bezpiecznym systemem jest ten, który nie jest podłączony do żadnej sieci, którego nikt nie może używać i nigdy nie zostanie uruchomiony. Z założenia jest on całkowicie bezpieczny, ale także całkowicie zbyteczny.

     Twórcy systemów operacyjnych są ściśle związani z światem handlu komputerowego. Na rynku wciąż pojawiają się nowe rozwiązania, udoskonalone wersje, a podstawą tego wszystkiego jest niska cena i łatwość w obsłudze. Powoduje to konieczność tworzenia prostych i funkcjonalnych systemów, co z kolei zwiększa szanse pojawienia się błędów i nieszczelności. Programiści stają więc przed niełatwym wyborem pomiędzy przeciwstawnymi z natury możliwościami. Niestety w wielu przypadkach – system łatwiejszy w obsłudze oznacza mniej bezpieczny. Użytkownicy żądają jednak produktu dobrze spełniającego swoją funkcję i równocześnie bezpiecznego. Problem nie kończy się tylko na tym, bowiem chcą również otwartych systemów, które są kompatybilne tzn. pozwalają na swobodny wybór poszczególnych elementów oprogramowania, co pozwalałoby na najbardziej ekonomiczne rozwiązania. Takie systemy przy złym wyborze i konfiguracji posiadają automatycznie niski poziom bezpieczeństwa. Innym źródłem słabości są błędy popełniane przez samych programistów. To co na początku wydaje się być ekscytującym zajęciem, z czasem zaczyna nudzić i prowadzić do rutyny. Wszystkie programy zazwyczaj kończy się w pośpiechu, gdyż nigdy nie ma czasu na spokojne dokończenie pracy. Kiedy pomysł jest już wykrystalizowany, użytkownicy z niecierpliwością czekają na jego materializację. Programista taki – w obawie przed złą opinią i uczestnictwie w wyścigu szczurów stara się jak najszybciej wywiązać z zadania i po drodze popełnia błędy. Jest to zjawisko bomby z opóźnionym zapłonem, która prędzej czy później wybuchnie. Pozostaje tylko stopniowe łagodzenie pola rażenia oraz naprawa szkód, poprzez nakładki i poprawki w kodzie.

     Oczywiście cały ten scenariusz jest tylko “ciemną stroną” mocy. Prawdą jest to, że systemy o otwartym kodzie już w samej strukturze posiadają zalety jeśli chodzi o kwestie bezpieczeństwa. Ich modularna budowa pozwala na eliminację słabych punktów oraz holistyczne wdrażanie zabezpieczeń, a dzięki dostępności kodu dla całej społeczności użytkowników nawet znudzony programista jest wspierany przez setki innych, którzy służą całemu projektowi swoją inwencją i spostrzeżeniami – często tworząc zgrany zespół zjednoczony przez ideę, a nie wartości materialne (oczywiście istnieją programiści, którzy zachowują wykryte luki tylko dla siebie – w mniejszy lub większy sposób czerpiąc z tego korzyści, ale i one z czasem są wykrywane podczas naturalnego procesu polepszania kodu). Anthony Nadalin, główny inżynier i dyrektor ds. projektowania zabezpieczeń w firmie IBM stwierdził: “Otwartość kodu zapewnia łatwy dostęp do technologii, na bazie której niezależni programiści będą mogli tworzyć nowatorskie rozwiązania”. Dzięki temu tempo doskonalenia funkcjonalności i bezpieczeństwa jest znacznie szybsze niż w typowym otoczeniu komercyjnych rozwiązań. Szczególnym odniesieniem ukazującym tą różnicę jest szybkość łatania dziur i wydawania poprawek, ponieważ w społeczności open source o problemach związanych z bezpieczeństwem mówi się otwarcie. Wystarczy od niechcenia wpisać w samym wujku Google w frazę: “linux security”, aby przekonać się, że ręka trzymana jest na pulsie.

     Aktualnie twórcy otwartych systemów bardzo starannie wybierają granicę kompromisu pomiędzy sprawnym działaniem i szczelnością, a cała gama dystrybucji pozwala na dokonanie wyboru pasującego pod charakter konkretnego użytkownika ceniącego sobie różne aspekty w systemie. W dodatku sama różnorodność powstającego oprogramowania już jest czynnikiem zwiększającym poziom bezpieczeństwa – z badań wynika – mimo to, że różne dystrybucje posiadają to samo jądro, to kody wykorzystujące luki (exploity) działają w stu procentach tylko na jednej odmianie systemu. Na podstawie nauki płynącej z przełamywanych pierwszych wersji systemów Uniksowych – Linux był już w trakcie tworzenia przygotowywany z myślą o bezpieczeństwie (np. narzędzia do tworzenia firewalli, możliwość przyznawania uprawnień użytkownikom). Wszystko to i wiele innych czynników jest tworzonych, ulepszanych, projektowanych na nowo, aby sprostać zapotrzebowaniom aktualnego rynku IT oraz samym użytkownikom, którzy są głównym napędem w tej maszynie. A co z samymi użytkownikami?

     Każdy może użytkować Linuksa, ale nie każdy może należeć do jego społeczności. Wiele użytkowników posiadających szczątkową i przekręconą wiedzę, na temat tego systemu oczekuje od niego maksymalnej wydajności najmniejszym własnym nakładem pracy i intelektu. To samo mylne wrażenie udziela się w jego płaszczyźnie bezpieczeństwa, które przecież zaczyna się już na poziomie pojedynczego użytkownika. Czynienie systemu bezpiecznym jest aspektem zarządzania nim z pogranicza – jak wiele innych – nauki i sztuki. Po instalacji w standardowym trybie większość dystrybucji Linuksa jest bardzo bogata w narzędzia i funkcje, ale pozostaje niezabezpieczonym systemem operacyjnym. Skoro zdecydowaliśmy się na daną dystrybucję, czy nawet system wypada zapoznać się z jego faktycznymi możliwościami i mechanizmami zabezpieczeń. Jeśli są one znikome, przecież zawsze możemy skorzystać z poza dystrybucyjnego oprogramowania – najistotniejszą sprawą jest dzisiaj, zdaniem producentów wykorzystanie już istniejących możliwości. Nie musimy być programistami, aby wspierać ruch open source – wystarczy, że docenimy fakt, że za darmo otrzymujemy bezpieczeństwo i funkcjonalność oraz produkty konkurujące czasami z najlepszymi odpowiednikami komercyjnymi. Bezpieczeństwo jest w końcu kwestią nie tylko techniczną, ale również społeczną. A jako społeczność musimy być w pełni świadomi zjawisk wewnętrznych, które mają zapewnić nam bezpieczeństwo. Starajmy się uczyć ich, bo być może jesteśmy coś winni ludziom tworzącym oprogramowanie, szczególnie to otwarte, i darmowe.

Felieton ten pochodzi z magazynu: Linux+ Nr 1 (117) Styczeń 2007.