Keesas Cookas, buvęs kernel.org CSO ir Ubuntu saugos komandos vadovas, dabar dirbantis „Google“, kad apsaugotų „Android“ ir „ChromeOS“, išreiškė susirūpinimą dėl dabartinio klaidų taisymo proceso stabiliose branduolio šakose. Kiekvieną savaitę į stabilias šakas įtraukiama apie šimtas pataisymų, o uždarius pakeitimų priėmimo į kitą leidimą langą artėja prie tūkstančio (prižiūrėtojai pataisymus laiko iki uždarymo lango, o suformavus „-rc1“ paskelbti sukauptus iš karto), o tai yra per daug ir reikalauja daug darbo priežiūros produktams, kurių pagrindas yra Linux branduolys.
Keys teigimu, darbo su branduolio klaidomis procesui neskiriamas deramas dėmesys ir branduoliui trūksta mažiausiai 100 papildomų kūrėjų koordinuotam darbui šioje srityje. Pagrindiniai branduolio kūrėjai reguliariai taiso klaidas, tačiau nėra garantijos, kad šie pataisymai bus perkelti į trečiųjų šalių naudojamus branduolio variantus. Įvairių produktų, pagrįstų Linux branduoliu, vartotojai taip pat negali kontroliuoti, kurios klaidos yra ištaisytos ir kuris branduolys naudojamas jų įrenginiuose. Pardavėjai galiausiai yra atsakingi už savo produktų saugumą, tačiau esant labai dideliam pataisų dažniui stabiliose branduolio atšakose, jie turėjo pasirinkti: perkelti visus pataisas atgal, pasirinktinai perkelti svarbiausius arba ignoruoti visus pataisymus.
Optimalus sprendimas būtų migruoti tik svarbiausius pataisymus ir pažeidžiamumus, tačiau tokių klaidų izoliavimas nuo bendro srauto yra pagrindinė problema. Dauguma iškylančių problemų kyla dėl C kalbos naudojimo, dėl kurio reikia labai atsargiai dirbti su atmintimi ir rodyklėmis. Dar blogiau tai, kad daugelis galimų pažeidžiamumo pataisymų nepateikiami su CVE identifikatoriais arba gauna tokį identifikatorių praėjus tam tikram laikui po pataisos paskelbimo. Tokiomis sąlygomis gamintojams labai sunku atskirti smulkius pataisymus nuo didelių saugumo problemų. Remiantis statistika, daugiau nei 40% pažeidžiamumų yra pataisoma prieš priskiriant CVE, o vidutinis delsa nuo pataisos išleidimo iki CVE priskyrimo yra trys mėnesiai (t. y. iš pradžių pataisa suvokiama kaip įprasta. klaidą, tačiau tik po kelių mėnesių paaiškėja, kad pažeidžiamumas ištaisytas).
Dėl to, neturėdami atskiros šakos su pažeidžiamumų pataisymais ir negaudami informacijos apie tam tikros problemos saugumo ryšį, Linux branduolio pagrindu pagamintų produktų gamintojams belieka nuolat perkelti visus pataisymus iš naujų stabilių šakų. Tačiau šis darbas reikalauja daug darbo jėgos ir susiduria su pasipriešinimu įmonėse dėl baimės regresinių pokyčių, galinčių sutrikdyti normalų gaminio veikimą.
Prisiminkite, kad, pasak Linuso Torvaldso, visos klaidos yra svarbios ir pažeidžiamumų nereikėtų atskirti nuo kitų tipų klaidų ir priskirti atskirai aukštesnio prioriteto kategorijai. Tokia nuomonė paaiškinama tuo, kad paprastam kūrėjui, kuris nesispecializuoja saugos klausimais, ryšys tarp pataisymo ir galimo pažeidžiamumo nėra akivaizdus (daugelio pataisymų atveju tik atskiras auditas leidžia suprasti, kad jie susiję su sauga ). Linuso teigimu, už Linux platinimų branduolio paketų priežiūrą atsakingos saugos komandos turi atskirti galimus pažeidžiamumus nuo bendro pataisų srauto.
Keesas Cookas mano, kad vienintelis sprendimas užtikrinti branduolio saugumą už pagrįstą ilgalaikę kainą yra įmonėms perkelti inžinierius, susijusius su pataisų perkėlimu į vietines branduolio versijas, kad jie bendradarbiautų ir koordinuotų, kad išlaikytų pataisas ir pažeidžiamumus ankstesniame branduolyje. Dabartiniu pavidalu daugelis gamintojų savo gaminiuose naudoja ne naujausią branduolio versiją ir backport pataisymus savarankiškai, t.y. pasirodo, kad skirtingų įmonių inžinieriai dubliuoja vienas kito darbus, spręsdami tą pačią problemą.
Pavyzdžiui, jei 10 įmonių, kurių kiekvienoje yra vienas inžinierius, remiantis tuos pačius pataisymus, nukreipia tuos inžinierius, kad ištaisytų klaidas, tada, užuot perkėlus vieną pataisą, jos galėtų ištaisyti 10 skirtingų klaidų bendram labui arba prisijungti prie siūlomų pakeitimų peržiūros. užkirsti kelią klaidingo kodo įtraukimui į branduolį. Ištekliai taip pat galėtų būti skirti kuriant naujus testavimo ir kodo analizės įrankius, kurie leistų ankstyvoje stadijoje automatiškai nustatyti tipines klaidų klases, kurios iškyla vėl ir vėl.
Keesas Cookas taip pat siūlo aktyviau naudoti automatizuotą ir neaiškią testavimą tiesiogiai pagrindiniame kūrimo procese, naudoti nuolatines integravimo sistemas ir atsisakyti archajiško kūrimo valdymo el. paštu. Šiuo metu efektyvų testavimą apsunkina tai, kad pagrindiniai testavimo procesai yra atskirti nuo kūrimo ir vyksta susiformavus leidimams. Keys taip pat rekomendavo naudoti saugesnes kalbas, pvz., Rust, kad sumažintų klaidas.
Šaltinis: opennet.ru