Kees Cook, bývalý hlavní systémový administrátor kernel.org a vedoucí týmu pro zabezpečení Ubuntu, který nyní pracuje ve společnosti Google na zabezpečení Androidu a ChromeOS, vyjádřil obavy o současný proces opravy chyb v stabilních větvích jádra. Každý týden je do stabilních větví zahrnuto přibližně sto oprav, a po uzavření okna příjmu změn do dalšího vydání se blíží k tisíci (doprovodné týmy zadržují opravy do uzavření okna, a po vytvoření „-rc1“ publikačně shromážděné najednou), což je příliš mnoho a vyžaduje to velké úsilí při udržování produktů založených na jádře Linux.
Podle Keesa se procesu práce s chybami v jádře nevěnuje dostatečná pozornost a jádru chybí minimálně 100 dalších vývojářů pro koordinovanou práci v této oblasti. Hlavní vývojáři jádra pravidelně opravují chyby, ale není žádná záruka, že tyto opravy budou přeneseny do verzí jádra používaných třetími výrobci. Uživatelé různých produktů založených na jádře Linux také nemají možnost sledovat, jaké chyby byly opraveny a jaké jádro je používáno v jejich zařízení. Nakonec za bezpečnost svých produktů odpovídají výrobci, ale za podmínek velmi vysoké intenzity publikování oprav ve stabilních větvích jádra byli postaveni před volbu — přenášet všechny opravy, selektivně portovat to nejdůležitější nebo ignorovat všechny opravy.
V důsledku toho, bez samostatné větve s opravami zranitelností a bez informací o souvislosti s bezpečností daného problému, zbývá výrobcům produktů založených na jádře Linuxu neustále přenášet všechny opravy z nových stabilních větví. Ale tato práce vyžaduje velké pracovní úsilí a ve firmách naráží na odpor kvůli obavám z možných regresivních změn, které by mohly narušit normální chod produktu.
Připomeňme, že podle názoru Linuse Torvaldse jsou všechny chyby důležité a zranitelnosti by se neměly oddělovat od ostatních typů chyb a vyčleňovat do samostatné prioritní kategorie. Toto stanovisko je vysvětleno tím, že pro běžného vývojáře, který se nespecializuje na bezpečnostní otázky, není zřejmá souvislost opravy s potenciální zranitelností (pro mnohé opravy pouze provedení samostatného auditu umožňuje pochopit, že se týkají bezpečnosti). Podle Linuse by se otázkami vyčleňování potenciálních zranitelností z běžného toku oprav měli zabývat specialisté na bezpečnost z týmů odpovědných za podporu balíčků s jádrem v distribucích Linuxu.
Kees Cook věří, že jediným řešením pro udržení bezpečnosti jádra při rozumných dlouhodobých nákladech je převod inženýrů, kteří se ve firmách zabývají portováním oprav do místních verzí jádra, na koordinovanou práci na správě oprav a zranitelností v hlavním jádře (upstream). V současné podobě mnoho výrobců používá ve svých produktech nikoli nejnovější verze jádra a zpětně integrují opravy vlastními silami, což vede k tomu, že inženýři v různých společnostech duplicují práci, když řeší stejný problém.
Například pokud 10 společností, z nichž každá má jednoho inženýra zabývajícího se zpětným integrováním stejných oprav, přeorientuje tyto inženýry na opravu chyb v upstreamu, mohli by místo portování jedné opravy opravit 10 různých chyb pro společné dobro nebo se zapojit do přezkoumávání navrhovaných změn a zabránit tak začlenění chybného kódu do jádra. Zdroje by také mohly být směrovány na vytváření nových nástrojů pro testování a analýzu kódu, které by v rané fázi automaticky odhalily typické třídy chyb, které se objevují znovu a znovu.
Kees Cook také navrhuje aktivněji využívat automatizované a fuzzingové testování přímo v rámci vývoje jádra, zavádět systémy kontinuální integrace a vzdát se archaického řízení vývoje prostřednictvím e-mailu. V současné době účinnému testování brání to, že hlavní procesy testování jsou odděleny od vývoje a probíhají až po vytvoření vydání. Kees také doporučil používat při vývoji jazyky, které zajistí méně vysokou úroveň bezpečnosti, jako je Rust.
Zdroj: opennet.ru
