Linus Torvalds – zasłużenie nazywany ojcem systemu Linux – nie od dziś znany jest z ciętego języka i skłonności do wygłaszania radykalnych opinii i obserwacji. Kilka dni temu mieliśmy kolejną okazję się o tym przekonać, kiedy to Torvalds najpierw nie przebierając w słowach zbeształ pracujących nad kodem Linuksa specjalistów od bezpieczeństwa, a następnie udzielił całej społeczności deweloperów zestawu porad na temat tego, jak wedle niego powinno wyglądać zabezpieczanie kodu.
Wszystko zaczęło się od dość niewinnej dyskusji – Kees Cook, programista Google Pixel, zgłosił kilka zmian z zakresu bezpieczeństwa do jądra systemu Linux. Chodziło m.in. o wprowadzenie mechanizmu, który blokowałby możliwość kopiowania danych z określonych obszarów pamięci. Służyć temu miała tzw. biała lista, zawierająca informacje o dopuszczonych do kopiowania obszarach. Taka zmiana byłaby dość radykalna, więc nowy mechanizm miał w pierwszej fazie implementacji działać w trybie awaryjnym.
Dyskusja nad zaproponowanymi zmianami szybko przerodziła w dość ostrą wymianę zdań – przy czym stroną „radykalną” w sporze był Linus Torvalds. W dość radykalnych słowach tłumaczył on bowiem, że niektórzy deweloperzy odpowiedzialni za funkcje zabezpieczające wykazują bardzo niezdrową, jego zdaniem, tendencję do „utwardzania” systemu i blokowania wszelkich aplikacji, odwołań i mechanizmów, które poprzez nieprawidłowe działanie mogą spowodować problemy z bezpieczeństwem. Linus Torvalds twierdzi tymczasem, że nie jest to rozwiązanie problemu, a jedynie zamiataniem pod dywan problemów związanych z działaniem kodu aplikacyjnego. Według niego, programiści, zamiast przeanalizować co powoduje nieprawidłowe działanie kodu i usunąć ową przyczynę, po prostu blokują sprawiającą problemy aplikację. „Problemy z bezpieczeństwem to po prostu błędy w oprogramowaniu (…) Wprowadzanie poprawek związany z bezpieczeństwem nigdy nie powinno sprowadzać się do zabijania procesów” – napisał Torvalds.
Niektórzy deweloperzy odpowiedzialni za funkcje zabezpieczające wykazują bardzo niezdrową, jego zdaniem, tendencję do „utwardzania” systemu i blokowania wszelkich aplikacji, odwołań i mechanizmów, które poprzez nieprawidłowe działanie mogą spowodować problemy z bezpieczeństwem.
Jego zdaniem moment, który typowy programista odpowiedzialny za bezpieczeństwo traktuje jako zakończenie sprawy (tzn. moment, w którym wprowadza on do kodu komendę blokującą wadliwie działającą funkcję) tak naprawdę powinien być postrzegany jako początek procesu rozwiązywania problemu. Oznacza to tyle, że zidentyfikowano problem i tymczasowo zabezpieczono oprogramowanie – a teraz deweloperzy powinni ustalić, co powodowało, że dany proces działał niepoprawnie i usunąć ową przyczynę.
Po pewnym czasie Torvalds się oczywiście zreflektował – przeprosił uczestników dyskusji za mocne słowa, tłumacząc irytację przepracowaniem i stresem. Nie wycofał się jednak absolutnie ze swoich słów na temat tego, jak jego zdaniem powinna wyglądać praca programistów odpowiedzialnych za bezpieczeństwo. Co więcej, sformułował zestaw porad dla nich:
• programiści powinni traktować proces rozwoju funkcji utwardzających oprogramowanie jako cel sam w sobie, a nie jako środek pozwalający ograniczyć skutki błędów w kodzie aplikacyjnym.
• podczas wprowadzania takich funkcji, pierwszym krokiem zawsze powinno być po prostu zgłoszenie problemu, a nie zabijanie procesów, czy blokowanie dostępu do wybranych obszarów pamięci.
• działania mające na celu poprawienie bezpieczeństwa oprogramowania powinny być realizowane w sposób nie powodujący szkód i ograniczeń w działaniu aplikacji.
