Kees Cook, bývalý CSO na kernel.org a vedoucí bezpečnostního týmu Ubuntu, který nyní pracuje pro Google na zabezpečení Androidu a ChromeOS, vyjádřil znepokojení nad současným procesem oprav chyb ve stabilních větvích jádra. Každý týden je ve stabilních větvích zahrnuta asi stovka oprav a po zavření okna pro přijímání změn do dalšího vydání se to blíží tisícovce (správci drží opravy do zavření okna a po vytvoření „-rc1“ publikovat ty nahromaděné najednou), což je příliš mnoho a vyžaduje spoustu práce pro produkty údržby založené na jádře Linuxu.
Podle Keyse není procesu práce s chybami v jádře věnována náležitá pozornost a jádru chybí minimálně 100 dalších vývojářů pro koordinovanou práci v této oblasti. Vývojáři jádra pravidelně opravují chyby, ale není zaručeno, že tyto opravy budou přeneseny na varianty jádra používané třetími stranami. Uživatelé různých produktů založených na jádře Linuxu také nemají žádný způsob, jak kontrolovat, které chyby jsou opraveny a které jádro je v jejich zařízeních použito. Dodavatelé jsou v konečném důsledku zodpovědní za bezpečnost svých produktů, ale s velmi vysokou mírou záplat ve stabilních větvích jádra byli postaveni před volbu mezi zpětným portováním všech záplat, selektivním portováním nejdůležitějších nebo ignorováním všech záplat.
Optimálním řešením by byla migrace pouze nejdůležitějších oprav a zranitelností, ale hlavním problémem je izolace takových chyb z obecného toku. Většina problémů, které se objevují, je způsobena použitím jazyka C, který vyžaduje velkou opatrnost při práci s pamětí a ukazateli. Aby toho nebylo málo, mnoho potenciálních oprav zranitelnosti není opatřeno identifikátory CVE nebo takový identifikátor obdrží nějakou dobu po zveřejnění opravy. Za takových podmínek je pro výrobce velmi obtížné oddělit drobné opravy od velkých bezpečnostních problémů. Podle statistik je více než 40 % zranitelností opraveno před přidělením CVE a průměrná prodleva mezi vydáním opravy a přidělením CVE je tři měsíce (tj. nejprve je oprava vnímána jako běžná chyba, ale až po několika měsících se ukáže, že zranitelnost byla opravena).
Výsledkem je, že bez samostatné větve s opravami zranitelností a bez přijímání informací o bezpečnostním připojení konkrétního problému mohou výrobci produktů založených na linuxovém jádru průběžně přenášet všechny opravy z čerstvých stabilních větví. Tato práce ale vyžaduje hodně práce a ve firmách naráží na odpor kvůli obavám z regresivních změn, které mohou narušit běžný provoz produktu.
Připomeňme, že podle Linuse Torvaldse jsou všechny chyby důležité a zranitelnosti by neměly být odděleny od ostatních typů chyb a přidělovány do samostatné vyšší prioritní kategorie. Tento názor je vysvětlen skutečností, že pro běžného vývojáře, který se nespecializuje na bezpečnostní otázky, není souvislost mezi opravou a potenciální zranitelností zřejmá (u mnoha oprav vám pouze samostatný audit umožní pochopit, že se týkají bezpečnosti ). Podle Linuse je na bezpečnostních týmech v týmech odpovědných za údržbu balíčků jádra na linuxových distribucích, aby izolovaly potenciální zranitelnosti z obecného toku oprav.
Kees Cook věří, že jediným řešením, jak udržet jádro v bezpečí za rozumnou dlouhodobou cenu, je pro společnosti přesunout inženýry podílející se na portování záplat na lokální sestavení jádra, aby spolupracovali a koordinovaně udržovali záplaty a zranitelnosti v upstream jádře. V současné podobě mnoho výrobců nepoužívá nejnovější verzi jádra ve svých produktech a opravy backportu samostatně, tzn. ukazuje se, že inženýři v různých společnostech si navzájem duplikují práci a řeší stejný problém.
Pokud například 10 společností, každou s jedním inženýrem podporujícím stejné opravy, přesměruje tyto inženýry, aby opravili chyby upstream, pak místo přenesení jedné opravy mohli opravit 10 různých chyb pro obecné dobro nebo se připojit k revizi navrhovaných změn. a zabránit zahrnutí chybového kódu do jádra. Zdroje by také mohly být věnovány vytváření nových nástrojů pro testování a analýzu kódu, které by v rané fázi umožnily automaticky identifikovat typické třídy chyb, které se znovu a znovu objevují.
Kees Cook také navrhuje aktivnější využívání automatizovaného a fuzzing testování přímo v procesu vývoje jádra, použití systémů kontinuální integrace a opuštění archaického řízení vývoje prostřednictvím e-mailu. V současné době brání efektivnímu testování skutečnost, že hlavní testovací procesy jsou odděleny od vývoje a probíhají až po vytvoření verzí. Keys také doporučil používat bezpečnější jazyky, jako je Rust, aby se omezily chyby.
Zdroj: opennet.ru