Kees Cook, tidigare chefssystemadministratör för kernel.org och ledare för Ubuntu Security Team som nu arbetar på Google för att säkra Android och ChromeOS, uttryckte oro över den nuvarande processen för att fixa buggar i de stabila grenarna av kärnan. Varje vecka är ett hundratal fixar inkluderade i de stabila grenarna, och efter att fönstret för att acceptera ändringar i nästa utgåva är stängt, närmar det sig tusen (underhållarna håller fixarna tills fönstret stängs och efter bildandet av " -rc1” de publicerar de ackumulerade på en gång), vilket är för många och kräver mycket arbete för underhållsprodukter baserade på Linux-kärnan.
Enligt Keys ägnas inte processen att arbeta med fel i kärnan vederbörlig uppmärksamhet och kärnan saknar minst 100 ytterligare utvecklare för koordinerat arbete inom detta område. De viktigaste kärnutvecklarna fixar regelbundet buggar, men det finns ingen garanti för att dessa korrigeringar kommer att överföras till kärnvarianter som används av tredje part. Användare av olika produkter baserade på Linux-kärnan har inte heller något sätt att kontrollera vilka buggar som fixas och 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 den mycket höga intensiteten av att publicera korrigeringar i stabila kärngrenar, ställdes de inför ett val - portera alla korrigeringar, portera selektivt de viktigaste eller ignorera alla korrigeringar .
Den optimala lösningen skulle vara att bara migrera de viktigaste korrigeringarna och sårbarheterna, men att isolera sådana fel från det allmänna flödet är huvudproblemet. Det största antalet problem som dyker upp är en konsekvens av att använda C-språket, vilket kräver stor noggrannhet när man arbetar med minne och pekare. För att göra saken värre är många potentiella sårbarhetskorrigeringar inte försedda med en CVE-identifierare, eller tilldelas en CVE-identifierare en tid efter att korrigeringen har publicerats. I en sådan miljö är det mycket svårt för tillverkare att skilja mindre korrigeringar från viktiga säkerhetsproblem. Enligt statistik är mer än 40 % av sårbarheterna åtgärdade innan en CVE tilldelas, och i genomsnitt är fördröjningen mellan releasen av en fix och tilldelningen av en CVE tre månader (dvs. till en början uppfattas fixen som en vanlig bugg, men först efter flera månader står det klart att sårbarheten har åtgärdats).
Som ett resultat, utan en separat gren med korrigeringar för sårbarheter och utan att ta emot information om säkerhetsanslutningen för ett visst problem, lämnas tillverkare av produkter baserade på Linux-kärnan att kontinuerligt överföra alla korrigeringar från de senaste stabila grenarna. Men detta arbete kräver mycket arbete och möter motstånd i företag på grund av rädsla för uppkomsten av regressiva förändringar som kan störa produktens normala funktion.
Låt oss komma ihåg att enligt Linus Torvalds är alla fel viktiga och sårbarheter bör inte separeras från andra typer av fel och tilldelas en separat kategori med högre prioritet. Denna åsikt förklaras av det faktum att för en vanlig utvecklare som inte är specialiserad på säkerhetsfrågor är kopplingen mellan en fix och en potentiell sårbarhet inte uppenbar (för många fixar är det bara en separat granskning som gör det möjligt att förstå att de rör säkerhet ). Enligt Linus bör säkerhetsspecialister från de team som ansvarar för att underhålla kärnpaket i Linux-distributioner vara involverade i att identifiera potentiella sårbarheter från den allmänna strömmen av patchar.
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 t.ex. 10 företag, var och en med en ingenjör som backporterar samma korrigeringar, omtilldelade dessa ingenjörer till att fixa buggar i uppströmsströmmen, så kan de istället för att backportera en korrigering fixa 10 olika buggar för gemensam nytta eller gå med i granskningen av föreslagna ändringar och förhindrar buggykod från att inkluderas i kärnan. Resurser skulle också kunna ägnas åt att skapa nya verktyg för att testa och analysera kod som skulle möjliggöra tidig upptäckt av vanliga felklasser som dyker upp om och om igen.
Kees Cook föreslår också att man mer aktivt använder automatiserade och otydliga tester direkt i kärnutvecklingsprocessen, använder kontinuerliga integrationssystem och överger arkaisk utvecklingshantering via e-post. För närvarande hämmas effektiv testning av det faktum att de huvudsakliga testprocesserna är separerade från utveckling och inträffar efter att utgåvorna bildats. Nycklar rekommenderas också att använda språk som ger en högre säkerhetsnivå, såsom Rust, vid utveckling för att minska antalet fel.
Källa: opennet.ru