Kees Cook, fost administrator principal de sistem pentru kernel.org și lider al echipei de securitate Ubuntu, care lucrează acum la Google pentru protecția Android și ChromeOS, și-a exprimat îngrijorarea cu privire la actualul proces de corectare a erorilor în ramurile stabile ale nucleului. În fiecare săptămână, aproximativ o sută de corecții sunt incluse în ramurile stabile, iar după închiderea ferestrei pentru primirea modificărilor, numărul ajunge aproape la o mie (dezvoltatorii rețin corecțiile până la închiderea ferestrei, iar după formarea „-rc1” publică totul odată), ceea ce este prea mult și necesită un efort considerabil pentru a menține produsele bazate pe nucleul Linux.
În opinia lui Kees, procesul de gestionare a erorilor în nucleu nu primește atenția cuvenită și nucleul are nevoie de cel puțin 100 de dezvoltatori suplimentari pentru a coordona activitatea în acest domeniu. Dezvoltatorii principali ai nucleului corectează regulat erorile, dar nu există nicio garanție că aceste corecții vor fi integrate în versiunile nucleului folosite de producători terți. Utilizatorii diferitelor produse bazate pe nucleul Linux nu au, de asemenea, posibilitatea de a controla ce erori au fost corectate și ce nucleu este folosit în dispozitivele lor. În cele din urmă, producătorii sunt responsabili pentru securitatea produselor lor, dar, în condițiile unei intensități foarte mari a publicării corecțiilor în ramurile stabile ale nucleului, aceștia s-au aflat în fața unei alegeri — să integreze toate corecțiile, să portreze selectiv cele mai importante sau să ignore toate corecțiile.
În concluzie, fără un ram separat pentru corecțiile vulnerabilităților și fără informații legate de securitatea problemei, producătorii de produse bazate pe nucleul Linux sunt nevoiți să transfere constant toate corecțiile din ultimele ramuri stabile. Dar această muncă necesită resurse semnificative și se confruntă cu rezistență în cadrul companiilor din cauza temerii de a provoca modificări regresive ce ar putea afecta funcționarea normală a produsului.
Să ne amintim că, potrivit lui Linus Torvalds, toate erorile sunt importante și vulnerabilitățile nu ar trebui să fie separate de alte tipuri de erori, fiind scoase într-o categorie prioritară. Această opinie este justificată prin faptul că pentru un dezvoltator obișnuit, care nu este specializat în probleme de securitate, nu este evidentă legătura dintre corecție și o potențială vulnerabilitate (pentru multe corecții, doar realizarea unui audit separat permite identificarea legăturii lor cu securitatea). În opinia lui Linus, problema identifikării vulnerabilităților din fluxul general de corecții ar trebui să fie gestionată de specialiștii în securitate din echipele responsabile pentru suportul pachetelor cu nucleul în distribuțiile Linux.
Kees Cook consideră că singura soluție pentru menținerea securității nucleului cu costuri raționale pe termen lung este transferul inginerilor care se ocupă cu portarea corecțiilor în compilările locale ale nucleului, la o colaborare coordonată pentru a susține corecturile și vulnerabilitățile din nucleul principal (upstream). În forma sa actuală, mulți producători folosesc în produsele lor versiuni mai vechi ale nucleului și aplică corecții cu forțe proprii, ceea ce face ca inginerii din diferite companii să își dubleze munca, rezolvând aceeași problemă.
De exemplu, dacă 10 companii, fiecare având câte un inginer responsabil cu portarea acelorași corecții, își redirecționează acești ingineri pentru a corecta erori în upstream, atunci aceștia ar putea, în loc să porteze o corecție, să rezolve 10 erori diferite pentru beneficiul comun sau să se alăture revizuirii modificărilor propuse și să evite includerea codului cu erori în nucleu. Resursele ar putea fi de asemenea îndreptate către crearea unor instrumente noi pentru testarea și analiza codului, care ar permite identificarea automată timpurie a claselor tipice de erori care apar repetat.
Kees Cook propune, de asemenea, utilizarea mai activă a testării automatizate și fuzzing-testării direct în procesul de dezvoltare a nucleului, aplicarea sistemelor de integrare continuă și abandonarea gestionării arhaice a dezvoltării prin email. În prezent, testării eficiente îi stă în cale faptul că principalele procese de testare sunt separate de dezvoltare și au loc doar după formarea versiunilor. Kees a recomandat, de asemenea, folosirea unor limbaje care facilitează mai bine dezvoltarea pentru a reduce numărul de erori, nivel ridicat de securitate, cum ar fi Rust.
Sursa: opennet.ro
