Kis Kuk (Kees Cook), bývalý hlavný systémový administrátor kernel.org a líder Ubuntu Security Team, dnes pracujúci vo firme Google na zabezpečení Android a ChromeOS, vyjadril obavy ohľadom aktuálneho procesu opravovania chýb v stabilných vetvách jadra. Týždenne sa do stabilných vetiev zahrňuje približne sto opráv, a po uzavretí okna na prijímanie zmien do nasledujúceho vydania to dosahuje takmer tisíc (správcovia zadržiavajú opravy do uzávierky, a po vytvorení „-rc1“ publikujú všetky nahromadené naraz), čo je príliš veľa a vyžaduje veľké náklady na prácu na produktoch založených na jadre Linux.
Podľa Kisa sa procesu práce s chybami v jadre nevenuje dostatočná pozornosť a jadru chýba aspoň 100 ďalších vývojárov na koordinovanú prácu v tejto oblasti. Hlavní vývojári jadra pravidelne opravujú chyby, ale nie sú žiadne záruky, že tieto opravy budú prenesené do variantov jadra používaných externými výrobcami. Používatelia rôznych produktov založených na jadre Linux tiež nemajú možnosť sledovať, ktoré chyby boli opravené a aké jadro sa používa v ich zariadeniach. V konečnom dôsledku za bezpečnosť svojich produktov zodpovedajú výrobcovia, ale v podmienkach veľmi vysokej intenzity publikovania opráv v stabilných vetvách jadra sa ocitli pred voľbou — previesť všetky opravy, selektívne prenášať najdôležitejšie alebo ignorovať všetky opravy.
Nakoniec, bez samostatnej vetvy na opravy zraniteľností a bez získavania informácií o súvislosti s bezpečnosťou danej problémy, výrobcom produktov založených na jadre Linux zostáva nepretržite prenášať všetky opravy z nových stabilných vetiev. Ale táto práca si vyžaduje veľa pracovného času a v spoločnostiach sa stretáva s odporom z obavy z možného výskytu regresívnych zmien, ktoré by mohli narušiť normálnu funkcionalitu produktu.
Pripomíname, že podľa názoru Linusa Torvalda sú všetky chyby dôležité a zraniteľnosti by sa nemali oddeliť od iných druhov chýb a vyčleniť do samostatnej, prioritnej kategórie. Toto stanovisko je odôvodnené tým, že pre bežného vývojára, ktorý sa špecializuje na otázky bezpečnosti, nie je zrejmá súvislosť opravy s potenciálnou zraniteľnosťou (pre mnohé opravy len vykonanie samostatného auditu umožňuje pochopiť, že sa týkajú bezpečnosti). Podľa Linusa by otázkami vyčleňovania potenciálnych zraniteľností z celkového toku opráv mali byť poverení odborníci na bezpečnosť z tímov zodpovedných za podporu balíkov s jadrom v distribúciách Linux.
Kees Cook považuje za jediné riešenie na zabezpečenie jadra pri rozumných dlhodobých nákladoch previesť inžinierov, ktorí sa zaoberajú portovaním opráv do lokálnych zostavení jadra, na spoločnú koordinovanú prácu na údržbe opráv a zraniteľností v hlavnom jadre (upstream). V súčasnej podobe mnoho výrobcov používa vo svojich produktoch nie najnovšie verzie jadra a spätne portujú opravy vlastnými silami, čo znamená, že inžinieri v rôznych spoločnostiach duplicujú prácu navzájom, riešiac tú istú problém.
Napríklad, ak 10 spoločností, z ktorých každá má jedného inžiniera zaoberajúceho sa spätne portovaním tých istých opráv, presmeruje týchto inžinierov na opravu chýb v upstream, mohli by namiesto portovania jednej opravy opraviť 10 rôznych chýb pre spoločné dobro alebo sa zapojiť do recenzovania navrhovaných zmien a zabrániť zahrnutiu chybného kódu do jadra. Zdroje by sa tiež mohli nasmerovať na vytváranie nových nástrojov na testovanie a analýzu kódu, ktoré by umožnili automaticky identifikovať typické triedy chýb, ktoré sa znova a znova objavujú už v počiatočných fázach.
Kees Cook tiež navrhuje aktívnejšie využívať automatizované a fuzzing testovanie priamo počas procesu vývoja jadra, aplikovať systémy kontinuálnej integrácie a vzdať sa archaického riadenia vývoja cez email. V súčasnosti efektívnemu testovaniu bráni to, že hlavné procesy testovania sú oddelené od vývoja a prebiehajú až po vytvorení vydaní. Kees tiež odporučil na zníženie počtu chýb používať pri vývoji jazyky, ktoré poskytujú viac vysoká úroveň bezpečnosti, ako je Rust.
Zdroj: opennet.ru
