Kees Cook, bývalý CSO kernel.org a vedúci bezpečnostného tímu Ubuntu, ktorý teraz pracuje pre Google na zabezpečení Androidu a ChromeOS, vyjadril znepokojenie nad súčasným procesom odstraňovania chýb v stabilných vetvách jadra. Každý týždeň je v stabilných vetvách zahrnutých asi sto opráv a po zatvorení okna na prijatie zmien do ďalšieho vydania sa to blíži k tisícke (správcovia podržia opravy, kým sa okno nezavrie a po vytvorení „-rc1“ zverejniť nahromadené naraz), čo je príliš veľa a vyžaduje veľa práce pre produkty údržby založené na jadre Linuxu.
Procesu práce s chybami v jadre sa podľa Keysa nevenuje náležitá pozornosť a jadru chýba minimálne 100 ďalších vývojárov na koordinovanú prácu v tejto oblasti. Vývojári jadra opravujú chyby pravidelne, ale nie je zaručené, že tieto opravy budú prenesené na varianty jadra používané tretími stranami. Používatelia rôznych produktov založených na jadre Linuxu tiež nemajú možnosť kontrolovať, ktoré chyby sú opravené a ktoré jadro sa používa v ich zariadeniach. Dodávatelia sú v konečnom dôsledku zodpovední za bezpečnosť svojich produktov, ale s veľmi vysokou mierou záplat v stabilných vetvách jadra boli konfrontovaní s voľbou medzi spätným portovaním všetkých záplat, selektívnym portovaním najdôležitejších alebo ignorovaním všetkých záplat.
Optimálnym riešením by bola migrácia iba najdôležitejších opráv a zraniteľností, ale hlavným problémom je izolácia takýchto chýb zo všeobecného toku. Väčšina problémov, ktoré sa objavia, je spôsobená použitím jazyka C, ktorý si vyžaduje veľkú pozornosť pri práci s pamäťou a ukazovateľmi. Aby toho nebolo málo, mnoho opráv potenciálnych zraniteľností nie je vybavených identifikátormi CVE alebo takýto identifikátor dostávajú nejaký čas po zverejnení opravy. Za takýchto podmienok je pre výrobcov veľmi ťažké oddeliť drobné opravy od veľkých bezpečnostných problémov. Podľa štatistík je viac ako 40 % zraniteľností opravených pred pridelením CVE a priemerné oneskorenie medzi vydaním opravy a priradením CVE je tri mesiace (t. j. najprv je oprava vnímaná ako bežná chyba, ale až po niekoľkých mesiacoch sa ukáže, že chyba zabezpečenia bola opravená).
Výsledkom je, že bez toho, aby mali samostatnú vetvu s opravami zraniteľností a bez prijímania informácií o bezpečnostnom spojení konkrétneho problému, výrobcovia produktov založených na linuxovom jadre môžu nepretržite prenášať všetky opravy z čerstvých stabilných vetiev. Ale táto práca si vyžaduje veľa práce a v spoločnostiach naráža na odpor kvôli strachu z regresívnych zmien, ktoré môžu narušiť normálnu prevádzku produktu.
Pripomeňme, že podľa Linusa Torvaldsa sú všetky chyby dôležité a zraniteľné miesta by sa nemali oddeľovať od iných typov chýb a prideľovať ich do samostatnej kategórie vyššej priority. Tento názor je vysvetlený skutočnosťou, že pre bežného vývojára, ktorý sa nešpecializuje na bezpečnostné otázky, nie je súvislosť medzi opravou a potenciálnou zraniteľnosťou zrejmá (pri mnohých opravách iba samostatný audit umožňuje pochopiť, že sa týkajú bezpečnosti ). Podľa Linusa je na bezpečnostných tímoch v tímoch zodpovedných za údržbu balíkov jadra v distribúciách Linuxu, aby izolovali potenciálne zraniteľnosti od všeobecného toku záplat.
Kees Cook verí, že jediným riešením, ako udržať jadro v bezpečí za rozumnú dlhodobú cenu, je pre spoločnosti presunúť inžinierov zapojených do portovania záplat na lokálne zostavy jadra, aby spolupracovali a koordinovane udržiavali záplaty a zraniteľné miesta v upstream jadre. V súčasnej podobe mnohí výrobcovia vo svojich produktoch nepoužívajú najnovšiu verziu jadra a opravy backportu samostatne, t.j. ukazuje sa, že inžinieri v rôznych spoločnostiach si navzájom duplikujú prácu a riešia ten istý problém.
Napríklad, ak 10 spoločností, každá s jedným inžinierom, ktorý podporuje rovnaké opravy, presmeruje týchto inžinierov, aby opravili chyby upstream, potom namiesto prenosu jednej opravy môžu opraviť 10 rôznych chýb pre spoločné dobro alebo sa pripojiť k preskúmaniu navrhovaných zmien. zabrániť zahrnutiu chybového kódu do jadra. Zdroje by sa mohli venovať aj vytváraniu nových nástrojov na testovanie a analýzu kódu, ktoré by umožnili v počiatočnom štádiu automaticky identifikovať typické triedy chýb, ktoré sa znova a znova objavujú.
Kees Cook tiež navrhuje aktívnejšie využívanie automatizovaného a fuzzing testovania priamo v procese vývoja jadra, používanie systémov kontinuálnej integrácie a upustenie od archaického riadenia vývoja prostredníctvom e-mailu. Efektívnemu testovaniu v súčasnosti bráni skutočnosť, že hlavné testovacie procesy sú oddelené od vývoja a vyskytujú sa až po vytvorení verzií. Keys tiež odporúča používať bezpečnejšie jazyky, ako je Rust, aby sa znížili chyby.
Zdroj: opennet.ru