Googles Keith Cook efterlyste en modernisering av processen för att åtgärda buggar i kärnan. Linux

Kees Cook, tidigare chefssystemadministratör för kernel.org och ledare Ubuntu Säkerhetsteamet arbetar nu på Google för att garantera säkerheten Android och ChromeOS, uttryckte oro över den nuvarande processen att åtgärda buggar i stabila kärngrenar. Omkring hundra korrigeringar inkluderas i stabila grenar varje vecka, och efter att fönstret för ändringsacceptans stängs närmar sig antalet tusen (underhållare behåller korrigeringarna tills fönstret stängs och släpper sedan de ackumulerade korrigeringarna på en gång efter att "-rc1"-utgåvan har skapats). Detta är för många och kräver mycket ansträngning för att underhålla kärnbaserade produkter. Linux.

Enligt Kies får inte kärnans buggfixning den uppmärksamhet den förtjänar, och kärnan saknar minst 100 ytterligare utvecklare för att samordna arbetet inom detta område. Kärnutvecklare fixar regelbundet buggar, men det finns ingen garanti för att dessa korrigeringar kommer att återportas till kärnversioner som används av tredjepartsleverantörer. Användare av olika kärnbaserade produkter Linux Det finns inte heller något sätt att kontrollera vilka buggar som har åtgärdats eller vilken kärna som används i deras enheter. I slutändan är tillverkarna ansvariga för säkerheten för sina produkter, men med tanke på den intensiva takten med vilken patchar publiceras i stabila kärngrenar står de inför ett val: backporta alla korrigeringar, selektivt backporta de viktigaste eller ignorera alla korrigeringar.

Den optimala lösningen vore att endast portera de viktigaste korrigeringarna och sårbarheterna, men att isolera dessa buggar från det allmänna flödet är den största utmaningen. Det största antalet framväxande problem uppstår vid användningen av C-språket, vilket kräver stor försiktighet när man arbetar med minne och pekare. Situationen förvärras av det faktum att många potentiella sårbarhetskorrigeringar inte tilldelas CVE-identifierare eller får sådana identifierare någon gång efter att patchen publicerats. Under dessa omständigheter är det mycket svårt för leverantörer att skilja mindre korrigeringar från viktiga säkerhetsproblem. Enligt statistik åtgärdas över 40 % av sårbarheterna innan de tilldelas en CVE, och den genomsnittliga fördröjningen mellan patchsläpp och CVE-tilldelning är tre månader (dvs. en korrigering uppfattas initialt som en enkel bugg, men först efter flera månader blir det tydligt att en sårbarhet har åtgärdats).

Som ett resultat, utan en separat gren med sårbarhetsåtgärder och utan att ta emot information om säkerhetskopplingen för ett visst problem, kan tillverkare av kärnbaserade produkter Linux Det enda alternativet som återstår är att kontinuerligt migrera alla fixar från de senaste stabila grenarna. Detta arbete är dock arbetsintensivt och möter motstånd inom företag på grund av oro för att införa regressiva förändringar som kan störa produktens normala drift.

Som en påminnelse anser Linus Torvalds att alla buggar är viktiga, och sårbarheter bör inte separeras från andra typer av buggar eller prioriteras. Detta beror på att för den genomsnittliga utvecklaren som inte specialiserar sig på säkerhet är sambandet mellan en fix och en potentiell sårbarhet inte omedelbart uppenbart (för många fixar avslöjar endast en separat granskning att de är säkerhetsrelaterade). Enligt Linus bör frågan om att identifiera potentiella sårbarheter från det allmänna patchflödet hanteras av säkerhetsspecialister från de team som ansvarar för att underhålla kärnpaket i distributioner. Linux.

Kees Cook anser att den enda lösningen för att upprätthålla kärnsäkerheten till en rimlig långsiktig kostnad är att företagen flyttar ingenjörerna som är involverade i portering av korrigeringar till lokala kärnbyggnader till en gemensam, koordinerad ansträngning för att upprätthålla korrigeringar och sårbarheter i huvudkärnan (uppströms). ). I sin nuvarande form använder många tillverkare inte de senaste kärnversionerna i sina produkter och backporterar korrigeringarna internt, d.v.s. Det visar sig att ingenjörer i olika företag duplicerar varandras arbete och löser samma problem.

Om till exempel 10 företag, vart och ett med en ingenjör som backportar samma korrigeringar, fokuserar dessa ingenjörer på att åtgärda buggar uppströms, så skulle de istället för att backporta en enda korrigering kunna åtgärda 10 olika buggar för det gemensamma bästa eller delta i granskningen av föreslagna ändringar och förhindra att buggig kod inkluderas i kärnan. Resurser skulle också kunna riktas mot att skapa nya verktyg för testning och kodanalys som automatiskt skulle identifiera återkommande typer av buggar tidigt.

Keith Cook föreslår också en mer aktiv användning av automatiserad och fuzz-testning direkt under kärnutvecklingen, användning av kontinuerliga integrationssystem och övergivande av arkaisk e-postbaserad utvecklingshantering. För närvarande hämmas effektiv testning av det faktum att de huvudsakliga testprocesserna är separerade från utveckling och sker efter utgåvor. Keith rekommenderade också att man använder språk som ger mer robust stöd under utveckling för att minska antalet fel. hög säkerhet, såsom Rost.

Källa: opennet.ru