Kees Cook z Google wezwał do modernizacji procesu pracy nad błędami w jądrze Linuksa

Kees Cook, były główny administrator systemów kernel.org i lider zespołu bezpieczeństwa Ubuntu, obecnie pracujący w Google nad zapewnieniem bezpieczeństwa Androida i ChromeOS, wyraził obawy dotyczące obecnego procesu naprawy błędów w stabilnych gałęziach jądra. Co tydzień do stabilnych gałęzi wprowadzanych jest około stu poprawek, a po zamknięciu okna przyjmowania zmian do następnej wersji liczba ta zbliża się do tysiąca (programiści wstrzymują poprawki do zamknięcia okna, a po utworzeniu wersji „-rc1” publikują je wszystkie naraz), co jest zbyt dużą liczbą i wymaga ogromnych nakładów pracy na utrzymanie produktów opartych na jądrze Linux.

Według Keese, proces pracy z błędami w jądrze nie jest odpowiednio doceniany, a brakuje co najmniej 100 dodatkowych programistów, aby prace w tej dziedzinie były skoordynowane. Główni deweloperzy jądra regularnie naprawiają błędy, ale nie ma żadnych gwarancji, że te poprawki zostaną przeniesione do wersji jądra używanych przez producentów zewnętrznych. Użytkownicy różnych produktów opartych na jądrze Linux nie mają także możliwości śledzenia, które błędy zostały naprawione i które jądro jest używane w ich urządzeniach. Ostatecznie odpowiedzialność za bezpieczeństwo ich produktów spoczywa na producentach, ale w obliczu ogromnej intensywności publikacji poprawek w stabilnych gałęziach jądra, zostali postawieni przed wyborem — wprowadzać wszystkie poprawki, selektywnie przenosić te najważniejsze lub ignorować wszystkie poprawki.

Optymalne rozwiązanie stanowiłoby przeniesienie tylko najważniejszych poprawek i luk, jednak problemem jest wydzielenie takich błędów z ogólnego strumienia. Najwięcej problemów wynika z użycia języka C, który wymaga dużej precyzji w pracy z pamięcią i wskaźnikami. Dodatkowo, wiele potencjalnych poprawek luk nie ma przypisanych identyfikatorów CVE lub otrzymuje taki identyfikator dopiero po pewnym czasie od opublikowania poprawki. W takich warunkach producentom niezwykle trudno jest rozróżnić drugorzędne poprawki od istotnych problemów wpływających na bezpieczeństwo. Statystyki pokazują, że ponad 40% luk jest usuwanych przed przypisaniem CVE, a średni czas opóźnienia między wydaniem poprawki a przypisaniem CVE wynosi trzy miesiące (tzn. na początku poprawka jest traktowana jak zwykły błąd, ale dopiero po kilku miesiącach staje się jasne, że nastąpiło usunięcie luki).

W związku z tym, nie mając oddzielnej gałęzi z poprawkami luk oraz nie otrzymując informacji o powiązaniu konkretnego problemu z bezpieczeństwem, producenci oprogramowania opartego na jądrze Linux są zmuszeni nieustannie przenosić wszystkie poprawki z najnowszych stabilnych gałęzi. Praca ta wymaga jednak znacznych zasobów i w firmach napotyka opór z powodu obaw o wystąpienie regresji, które mogą zakłócić normalne działanie produktu.

Przypomnijmy, że zdaniem Linusa Torvaldsa, wszystkie błędy są ważne i luki nie powinny być oddzielane od innych rodzajów błędów oraz wyróżniane w osobną, wyżej priorytetową kategorię. Takie zdanie uzasadnione jest tym, że dla przeciętnego programisty, który nie specjalizuje się w zagadnieniach bezpieczeństwa, związek poprawki z potencjalną luką nie jest oczywisty (w przypadku wielu poprawek jedynie przeprowadzenie oddzielnego audytu pozwala zrozumieć, że dotyczą one bezpieczeństwa). Według Linusa, kwestie wydzielenia potencjalnych luk z ogólnego strumienia poprawek powinny być zajęciem specjalistów bezpieczeństwa z zespołów odpowiedzialnych za wsparcie pakietów z jądrem w dystrybucjach Linux.

Kees Cook uważa, że jedynym rozwiązaniem dla zachowania bezpieczeństwa jądra przy rozsądnych długoterminowych kosztach jest przesunięcie inżynierów zajmujących się przenoszeniem poprawek do lokalnych wersji jądra do wspólnej, skoordynowanej pracy nad utrzymywaniem poprawek i luk w zabezpieczeniach w głównym jądrze (upstream). W obecnej formie wielu producentów używa w swoich produktach starszych wersji jądra i własnoręcznie wprowadza poprawki, co prowadzi do tego, że inżynierowie w różnych firmach powielają swoją pracę, rozwiązując ten sam problem.

Na przykład, jeśli 10 firm, w każdej z których jeden inżynier zajmuje się wprowadzaniem tych samych poprawek, przestawi tych inżynierów na naprawę błędów w upstream, to zamiast przenosić jedną poprawkę mogą naprawić 10 różnych błędów dla ogólnej korzyści lub dołączyć do przeglądu proponowanych zmian, unikając wprowadzenia błędnego kodu do jądra. Zasoby można również przekierować na tworzenie nowych narzędzi do testowania i analizy kodu, które pozwoliłyby na wczesnym etapie automatycznie identyfikować typowe klasy błędów, które pojawiają się wielokrotnie.

Kees Cook proponuje również bardziej aktywne wykorzystanie automatyzacji i testów fuzzingowych bezpośrednio w procesie rozwoju jądra, stosowanie systemów ciągłej integracji oraz rezygnację z archaicznego zarządzania rozwojem poprzez e-mail. Obecnie skutecznemu testowaniu przeszkadza fakt, że główne procesy testowania są oddzielone od rozwoju i odbywają się dopiero po sformowaniu wersji. Kees zalecił także stosowanie języków programowania, które zapewniają większą wysoki poziom bezpieczeństwa, takie jak Rust.

Źródło: opennet.ru