Kees Cook, nekdanji glavni sistemski skrbnik kernel.org in vodja varnostne ekipe Ubuntu, ki zdaj dela pri Googlu za zaščito Androida in ChromeOS, je izrazil zaskrbljenost glede trenutnega postopka odpravljanja napak v stabilnih vejah jedra. Vsak teden je v stabilne veje vključenih približno sto popravkov, po zaprtju okna za sprejemanje sprememb v naslednji izdaji pa se približa tisoč (vzdrževalci zadržijo popravke, dokler se okno ne zapre in po oblikovanju » -rc1« objavijo nakopičene naenkrat), kar je preveč in zahteva veliko dela za vzdrževalne izdelke, ki temeljijo na jedru Linuxa.
Po Keysovih besedah se procesu dela z napakami v jedru ne posveča dovolj pozornosti in jedru manjka vsaj 100 dodatnih razvijalcev za usklajeno delo na tem področju. Glavni razvijalci jedra redno popravljajo napake, vendar ni nobenega zagotovila, da bodo ti popravki preneseni na različice jedra, ki jih uporabljajo tretje osebe. Uporabniki različnih izdelkov, ki temeljijo na jedru Linuxa, prav tako nimajo možnosti nadzora, katere napake so odpravljene in katero jedro se uporablja v njihovih napravah. Konec koncev so proizvajalci odgovorni za varnost svojih izdelkov, a zaradi zelo visoke intenzivnosti objavljanja popravkov v stabilnih vejah jedra so bili postavljeni pred izbiro - prenesti vse popravke, selektivno prenesti najpomembnejše ali prezreti vse popravke. .
Optimalna rešitev bi bila selitev samo najpomembnejših popravkov in ranljivosti, vendar je izolacija takšnih napak iz splošnega toka glavni problem. Največ težav, ki se pojavljajo, je posledica uporabe jezika C, ki zahteva veliko previdnost pri delu s pomnilnikom in kazalci. Da bi bile stvari še hujše, številni možni popravki ranljivosti nimajo identifikatorja CVE ali pa jim je identifikator CVE dodeljen nekaj časa po objavi popravka. V takšnem okolju proizvajalci zelo težko ločijo manjše popravke od pomembnih varnostnih vprašanj. Po statističnih podatkih je več kot 40 % ranljivosti odpravljenih, preden je dodeljen CVE, v povprečju pa je zamik med izdajo popravka in dodelitvijo CVE tri mesece (tj. sprva se popravek dojema kot redna napaka, vendar šele po nekaj mesecih postane jasno, da je bila ranljivost odpravljena).
Posledično brez ločene veje s popravki ranljivosti in brez prejemanja informacij o varnostni povezavi določenega problema proizvajalci izdelkov, ki temeljijo na jedru Linuxa, ostanejo neprekinjeno prenašali vse popravke iz najnovejših stabilnih vej. A to delo zahteva veliko dela in se v podjetjih sooča z odporom zaradi strahu pred pojavom regresivnih sprememb, ki bi lahko motile normalno delovanje izdelka.
Naj spomnimo, da so po Linusu Torvaldsu vse napake pomembne in ranljivosti ne bi smeli ločevati od drugih vrst napak in jih dodeliti v ločeno kategorijo višje prioritete. To mnenje je razloženo z dejstvom, da za običajnega razvijalca, ki se ne ukvarja z varnostnimi vprašanji, povezava med popravkom in morebitno ranljivostjo ni očitna (za številne popravke le ločena revizija omogoča razumevanje, da zadevajo varnost ). Po Linusovih besedah bi morali strokovnjaki za varnost iz skupin, odgovornih za vzdrževanje paketov jedra v distribucijah Linuxa, sodelovati pri prepoznavanju potencialnih ranljivosti v splošnem toku popravkov.
Kees Cook verjame, da je edina rešitev za vzdrževanje varnosti jedra po razumnih dolgoročnih stroških, da podjetja premaknejo inženirje, ki sodelujejo pri prenosu popravkov v lokalne zgradbe jedra, v skupno, usklajeno prizadevanje za vzdrževanje popravkov in ranljivosti v glavnem jedru (navzgor ). V sedanji obliki številni proizvajalci v svojih izdelkih ne uporabljajo najnovejših različic jedra in popravke prenašajo v backport interno, tj. Izkazalo se je, da inženirji v različnih podjetjih podvajajo delo drug drugega in rešujejo isti problem.
Na primer, če 10 podjetij, od katerih ima vsak en inženir, ki prenaša iste popravke, prerazporedi te inženirje, da popravljajo napake navzgor, potem lahko namesto prenosa enega popravka popravijo 10 različnih napak v skupno korist ali se pridružijo pregledu predlaganih sprememb. in prepreči vključitev hroščaste kode v jedro. Sredstva bi lahko namenili tudi ustvarjanju novih orodij za testiranje in analizo kode, ki bi omogočila zgodnje odkrivanje običajnih razredov napak, ki se vedno znova pojavljajo.
Kees Cook prav tako predlaga dejavnejšo uporabo avtomatiziranega in fuzzing testiranja neposredno v procesu razvoja jedra, uporabo sistemov za stalno integracijo in opustitev arhaičnega upravljanja razvoja prek e-pošte. Trenutno učinkovito testiranje ovira dejstvo, da so glavni procesi testiranja ločeni od razvoja in se pojavijo po oblikovanju izdaj. Keys tudi priporoča uporabo jezikov, ki zagotavljajo višjo raven varnosti, kot je Rust, pri razvoju za zmanjšanje števila napak.
Vir: opennet.ru