Kees kuhaju Pravim post na blogu u kojem je izazvao zabrinutost zbog procesa ispravljanja grešaka u tijeku u stabilnim granama Linux kernela i je li to spomenuti da je iz tjedna u tjedan uključeno stotinjak ispravki na stabilnim granama, što je previše i zahtijeva mnogo napora za održavanje proizvoda zasnovanih na Linux jezgri.
Prema Kees -u, proces rukovanja greškama jezgre je zaobiđen i kernelu nedostaje najmanje 100 dodatnih programera da koordinirano rade u ovoj oblasti. Uz napomenu da veliki programeri kernela redovito ispravljaju greške, ali nema garancije da će se ti popravci prenijeti na varijante jezgre trećih strana.
Pritom napominje da korisnici različitih proizvoda zasnovanih na jezgri Linuxa također nemaju načina kontrolirati koje su greške ispravljene i koje se jezgro koristi na njihovim uređajima. Na kraju, dobavljači su odgovorni za sigurnost svojih proizvoda, ali suočeni s vrlo velikom stopom zakrpa na stabilnim granama jezgre, suočeni su s izborom migracije svih zakrpa, selektivne migracije najvažnijih ili zanemarivanja svih zakrpa. .
Programeri uzvodnog kernela mogu popraviti greške, ali nemaju kontrolu nad onim što proizvođač daljeg toka izabere da uključi u svoje proizvode. Krajnji korisnici mogu birati svoje proizvode, ali općenito nemaju kontrolu nad ispravljenim greškama ili jezgrom koja se koristi (problem sam po sebi). Konačno, prodavci su odgovorni za čuvanje jezgra svojih proizvoda.
Kees kuhaju sugerira da bi optimalno rješenje bilo prijenos samo najvažnijih ispravki i ranjivosti, ali glavni problem je odvojiti ove greške od općeg tijeka, budući da je većina nastalih problema posljedica upotrebe jezika C, koji zahtijeva mnogo pažnje pri radu s memorijom i pokazivačima.
Da stvar bude gora, mnogi potencijalni popravci ranjivosti nisu označeni CVE identifikatorima ili ne primaju CVE identifikator neko vrijeme nakon objavljivanja zakrpe.
U takvom okruženju proizvođačima je vrlo teško odvojiti manje popravke od velikih sigurnosnih pitanja. Prema statistikama, više od 40% ranjivosti uklanja se prije dodjele CVE -a, a u prosjeku je kašnjenje između izdanja popravka i dodjele CVE -a tri mjeseca (to jest, na početku se rješenje smatra uobičajenom greškom,
Kao rezultat, nema odvojenu granu s popravcima za ranjivosti i ne prima informacije o vezi sa sigurnošću ovog ili onog problema, proizvođači proizvoda zasnovanih na jezgri Linuxa moraju stalno prenositi sve popravke novih stabilnih ogranaka. No, ovaj posao je dugotrajan i nailazi na otpor kompanija zbog straha od regresivnih promjena koje bi mogle poremetiti normalan rad proizvoda.
Keys Cook vjeruje da je jedino rješenje za održavanje jezgre sigurnom po razumnoj cijeni na duži rok premještanje inženjera zakrpa za lude jezgreda radim zajedno na koordiniran način za održavanje zakrpa i ranjivosti u uzvodnom jezgru. Kako sada stoji, mnogi dobavljači ne koriste najnovije verzije kernela u svojim proizvodima i popravkama zaostalih podataka, što znači da se inženjeri iz različitih kompanija međusobno dupliciraju, rješavajući isti problem.
Na primjer, ako 10 kompanija, od kojih svaka ima inženjera koji podržava iste popravke, preusmjeri te inženjere da popravljaju greške uzvodno, umjesto da migriraju jednu ispravku, mogle bi popraviti 10 različitih grešaka radi ukupne koristi ili se okupiti kako bi pregledale greške. Predložene promjene . I izbjegavajte uključivanje grešaka u kernel. Resursi se također mogu koristiti za stvaranje novih alata za analizu koda i testiranje koji bi automatski u ranoj fazi automatski otkrili tipične klase grešaka koje se pojavljuju uvijek iznova.
Keys Cook također predlaže aktivniju upotrebu automatiziranog testiranja i fuziranja direktno u procesu razvoja kernela, koristite sisteme kontinuirane integracije i napustite arhaično upravljanje razvojem putem e-pošte.
Izvor: https://security.googleblog.com