Kees Cook från Google har uppmanat till en modernisering av processen för felhantering i Linux-kärnan

Kees Cook, tidigare huvudsystemadministratör för kernel.org och ledare för Ubuntu Security Team, som nu arbetar på Google för att säkerställa säkerheten för Android och ChromeOS, uttryckte sin oro över den nuvarande processen för att åtgärda fel i stabila versioner av kärnan. Veckovisa ungefär hundra korrigeringar inkluderas i de stabila versionerna, och efter stängningen av fönstret för ändringsupptagande närmar sig antalet för nästa release tusen (utvecklarna behåller korrigeringarna fram till fönstrets st stängning, och efter att '-rc1' har skapats publicerar de det som har samlats på en gång), vilket är för mycket och kräver stora arbetsinsatser för att stödja produkterna baserade på Linux-kärnan.

Enligt Kees ges processen för att hantera fel i kärnan inte tillräcklig uppmärksamhet, och kärnan saknar minst 100 ytterligare utvecklare för ett samordnat arbete inom detta område. Kärnans huvudutvecklare åtgärdar regelbundet fel, men det finns inga garantier för att dessa korrigeringar kommer att överföras till versioner av kärnan som används av tredjepartsproducenter. Användare av olika produkter baserade på Linux-kärnan har inte heller möjlighet att övervaka vilka fel som har åtgärdats och vilken kärna som används i deras enheter. Slutgiltigt är det producenterna som ansvarar för säkerheten hos sina produkter, men under de mycket intensiva publiceringarna av korrigeringar i kärnans stabila grenar har de ställts inför valet — att överföra alla korrigeringar, selektivt portera de mest viktiga eller att ignorera alla korrigeringar.

En optimal lösning skulle vara att endast överföra de mest kritiska bugfixarna och sårbarheterna, men den stora utmaningen ligger i att identifiera sådana fel från den övergripande strömmen. Det största antalet plötsliga problem uppstår på grund av användningen av språket C, som kräver stor noggrannhet när det gäller minne och pekare. Situationens svårighetsgrad ökar av att många potentiella sårbarhetsfixar inte får CVE-ID:n eller får sådana identifierare först efter en tid efter att fixen publicerats. Under dessa omständigheter är det mycket svårt för tillverkare att skilja mellan sekundära fixar och viktiga säkerhetsproblem. Statistiskt sett åtgärdas mer än 40% av sårbarheterna innan de tilldelas en CVE och den genomsnittliga fördröjningen mellan utgivningen av fixen och tilldelningen av CVE är tre månader (d.v.s. initialt uppfattas fixen som ett vanligt fel, men efter några månader blir det klart att det handlade om en åtgärdad sårbarhet).

I slutändan, utan en separat gren för att åtgärda sårbarheter och utan att få information om förhållandet till säkerheten under vissa problem, måste tillverkare av produkter baserade på Linux-kärnan kontinuerligt överföra alla fixar från de senaste stabila grenarna. Men detta arbete kräver stora arbetsinsatser och möter motstånd i företagen på grund av oro för regressiva förändringar som kan påverka produktens normala funktion.

Låt oss påminna om att enligt Linus Torvalds är alla fel viktiga och sårbarheter bör inte separeras från andra typer av fel och ges en särskilt prioriterad kategori. Denna åsikt förklaras av att det för en vanlig utvecklare, som inte specialiserar sig på säkerhetsfrågor, inte är uppenbart hur en fix länkar till en potentiell sårbarhet (för många fixar kräver endast en separat granskning för att förstå att de rör säkerhet). Enligt Linus bör säkerhetsspecialister i team som ansvarar för kärnpaketstöd i Linux-distributioner arbeta med att identifiera potentiella sårbarheter bland den allmänna strömmen av fixar.

Kees Cook anserar att den enda lösningen för att bibehålla kärnsäkerheten med rimliga långsiktiga kostnader är att företag omdirigerar ingenjörer som arbetar med att portera patchar till lokala kärnbyggnader till ett samordnat arbete för att underhålla patchar och sårbarheter i upstream-kärnan. I sin nuvarande form använder många tillverkare inte de nyaste versionerna av kärnan i sina produkter och backportar patchar på egen hand, vilket innebär att ingenjörer på olika företag duplicerar sitt arbete för att lösa samma problem.

Till exempel, om 10 företag, där varje företag har en ingenjör som backportar samma patchar, omdirigerar dessa ingenjörer till att åtgärda fel i upstream, skulle de istället för att portera en patch kunna åtgärda 10 olika fel till allas fördel eller delta i granskningen av föreslagna förändringar för att förhindra att felaktig kod inkluderas i kärnan. Resurser skulle också kunna riktas mot att skapa nya verktyg för testning och kodanalys som skulle kunna identifiera typiska felformer automatiskt i ett tidigt skede.

Kees Cook föreslår också att man mer aktivt använder automatiserad och fuzzing-testning direkt under utvecklingen av kärnan, tillämpar system för kontinuerlig integration och avstår från archaisk e-posthantering vid utveckling. För närvarande hindras effektiv testning av det faktum att de huvudsakliga testprocesserna är separerade från utvecklingen och sker först efter att releaserna har skapats. Kees rekommenderade också att använda programmeringsspråk som ger mer en hög säkerhetsnivå, såsom Rust.

Källa: opennet.ru