Kees gotuje Tworzę post na blogu, w którym zgłosił zastrzeżenia dotyczące procesu naprawy błędów trwa w stabilnych gałęziach jądra Linuksa i czy? wspominam, że z tygodnia na tydzień uwzględniono około stu poprawek na stabilnych gałęziach, co jest zbyt duże i wymaga dużego wysiłku, aby utrzymać produkty oparte na jądrze Linuksa.
Według Keesa, proces obsługi błędów jądra jest pomijany i w jądrze brakuje co najmniej 100 dodatkowych programistów do pracy w skoordynowany sposób w tym obszarze. Wspominając również, że główni programiści jądra regularnie naprawiają błędy, ale nie ma gwarancji, że te poprawki zostaną przeniesione na warianty jądra innych firm.
Czyniąc to, wspomina, że użytkownicy różnych produktów opartych na jądrze Linuksa również nie mają możliwości kontrolowania, które błędy zostały naprawione i które jądro jest używane na ich urządzeniach. Ostatecznie to dostawcy są odpowiedzialni za bezpieczeństwo swoich produktów, ale w obliczu bardzo wysokiego wskaźnika łat na stabilne gałęzie jądra, musieli wybrać migrację wszystkich łat, migrację selektywną tych najważniejszych lub zignorowanie wszystkich łat. .
Twórcy jądra wyższego szczebla mogą naprawiać błędy, ale nie mają kontroli nad tym, co dalszy dostawca zdecyduje się włączyć do swoich produktów. Użytkownicy końcowi mogą wybierać swoje produkty, ale generalnie nie mają kontroli nad tym, które błędy są naprawione lub jakie jądro jest używane (problem sam w sobie). Ostatecznie dostawcy są odpowiedzialni za zapewnienie bezpieczeństwa rdzeni produktów.
Kees gotuje sugeruje, że optymalnym rozwiązaniem byłoby przeniesienie tylko najważniejszych poprawek i podatności, ale głównym problemem jest oddzielenie tych błędów od ogólnego przepływu, ponieważ większość pojawiających się problemów jest konsekwencją użycia języka C, który wymaga dużej ostrożności podczas pracy z pamięcią i wskaźnikami.
Co gorsza, wiele potencjalnych poprawek luk w zabezpieczeniach nie jest oznaczonych identyfikatorami CVE lub nie otrzymuje identyfikatora CVE jakiś czas po wydaniu poprawki.
W takim środowisku producentom bardzo trudno jest oddzielić drobne poprawki od poważnych problemów związanych z bezpieczeństwem. Według statystyk ponad 40% podatności jest usuwanych przed przypisaniem CVE, a średnio opóźnienie między wydaniem poprawki a przypisaniem CVE wynosi trzy miesiące (czyli na początku rozwiązanie postrzega jako częsty błąd,
W rezultacie nie posiadanie osobnej gałęzi z poprawkami na podatności i nie otrzymywania informacji o połączeniu z bezpieczeństwem tego lub innego problemu, producenci produktów opartych na jądrze Linux muszą stale przenosić wszystkie poprawki nowych stabilnych oddziałów. Ale ta praca jest pracochłonna i napotyka na opór ze strony firm z powodu obaw przed regresywnymi zmianami, które mogłyby zakłócić normalne działanie produktu.
Klucze kucharz uważa, że jedynym rozwiązaniem zapewniającym bezpieczeństwo jądra przy rozsądnych kosztach na dłuższą metę jest przeniesienie inżynierów łatek do szalonych kompilacji jądral współpracować w skoordynowany sposób aby utrzymać łatki i luki w pierwotnym jądrze. W obecnej sytuacji wielu dostawców nie stosuje najnowszych wersji jądra w swoich produktach i poprawek backportów na własną rękę, to znaczy okazuje się, że inżynierowie z różnych firm powielają się nawzajem, rozwiązując ten sam problem.
Na przykład, jeśli 10 firm, każda z inżynierem obsługującym te same poprawki, przekieruje tych inżynierów, aby naprawili błędy wcześniej, zamiast migrować jedną poprawkę, mogliby naprawić 10 różnych błędów dla ogólnej korzyści lub zebrać się, aby je przejrzeć. . I unikaj dołączania błędnego kodu do jądra. Zasoby można również wykorzystać do stworzenia nowych narzędzi do analizy kodu i testowania, które automatycznie wykrywałyby na wczesnym etapie typowe klasy błędów, które pojawiają się w kółko.
Klucze kucharz proponuje również bardziej aktywne korzystanie z automatycznego testowania i fuzzingu bezpośrednio w procesie rozwoju jądra, korzystaj z systemów ciągłej integracji i porzucaj archaiczne zarządzanie rozwojem poprzez e-mail.
źródło: https://security.googleblog.com