Kees Cook, tidligere sjefsystemadministrator for kernel.org og leder av Ubuntu Security Team som nå jobber hos Google for å sikre Android og ChromeOS, uttrykte bekymring for den nåværende prosessen med å fikse feil i de stabile grenene til kjernen. Hver uke er rundt hundre rettelser inkludert i stabile grener, og etter at vinduet for å akseptere endringer i neste utgivelse er lukket, nærmer det seg tusen (vedlikeholderne holder rettelsene til vinduet lukkes, og etter dannelsen av " -rc1” de publiserer de akkumulerte på en gang), noe som er for mange og krever mye arbeid for vedlikeholdsprodukter basert på Linux-kjernen.
I følge Keys er prosessen med å jobbe med feil i kjernen ikke viet behørig oppmerksomhet, og kjernen mangler minst 100 ekstra utviklere for koordinert arbeid på dette området. De viktigste kjerneutviklerne fikser regelmessig feil, men det er ingen garanti for at disse rettelsene vil bli overført til kjernevarianter som brukes av tredjeparter. Brukere av ulike produkter basert på Linux-kjernen har heller ingen mulighet til å kontrollere hvilke feil som er fikset og hvilken kjerne som brukes i enhetene deres. Til syvende og sist er produsentene ansvarlige for sikkerheten til produktene sine, men med den svært høye intensiteten av å publisere rettelser i stabile kjernegrener, sto de overfor et valg – porter alle rettelsene, porter selektivt de viktigste, eller ignorer alle rettelsene .
Den optimale løsningen ville være å migrere bare de viktigste rettelsene og sårbarhetene, men å isolere slike feil fra den generelle flyten er hovedproblemet. Det største antallet problemer som dukker opp er en konsekvens av bruk av C-språket, som krever stor forsiktighet når man jobber med hukommelse og pekere. For å gjøre vondt verre, er mange potensielle sårbarhetsoppdateringer ikke utstyrt med en CVE-identifikator, eller blir tildelt en CVE-identifikator en tid etter at oppdateringen er publisert. I et slikt miljø er det svært vanskelig for produsenter å skille mindre reparasjoner fra viktige sikkerhetsproblemer. I følge statistikk er mer enn 40 % av sårbarhetene fikset før en CVE blir tildelt, og i gjennomsnitt er forsinkelsen mellom utgivelsen av en rettelse og tildelingen av en CVE tre måneder (dvs. at rettelsen først oppfattes som en vanlig feil, men først etter flere måneder blir det klart at sårbarheten er fikset).
Som et resultat, uten en egen gren med rettelser for sårbarheter og uten å motta informasjon om sikkerhetstilkoblingen til et bestemt problem, får produsenter av produkter basert på Linux-kjernen kontinuerlig overføre alle rettelser fra de siste stabile grenene. Men dette arbeidet krever mye arbeid og møter motstand i bedrifter på grunn av frykt for fremveksten av regressive endringer som kan forstyrre den normale driften av produktet.
La oss minne om at i følge Linus Torvalds er alle feil viktige og sårbarheter bør ikke skilles fra andre typer feil og tildeles en egen høyere prioritert kategori. Denne oppfatningen forklares med det faktum at for en vanlig utvikler som ikke spesialiserer seg på sikkerhetsspørsmål, er sammenhengen mellom en rettelse og en potensiell sårbarhet ikke åpenbar (for mange rettelser er det kun en separat revisjon som gjør det mulig å forstå at de gjelder sikkerhet ). Ifølge Linus bør sikkerhetsspesialister fra teamene som er ansvarlige for vedlikehold av kjernepakker i Linux-distribusjoner være involvert i å identifisere potensielle sårbarheter fra den generelle strømmen av oppdateringer.
Kees Cook mener at den eneste løsningen for å opprettholde kjernesikkerhet til en rimelig langsiktig kostnad er at selskaper flytter ingeniørene som er involvert i portering av rettelser til lokale kjernebygg til en felles, koordinert innsats for å opprettholde rettelser og sårbarheter i hovedkjernen (oppstrøms). ). I sin nåværende form bruker mange produsenter ikke de nyeste kjerneversjonene i produktene sine og gir tilbakemeldinger internt, dvs. Det viser seg at ingeniører i forskjellige selskaper dupliserer hverandres arbeid, og løser det samme problemet.
For eksempel, hvis 10 selskaper, hver med en ingeniør som backporterer de samme rettelsene, omdisponerte disse ingeniørene til å fikse feil i oppstrøms, så i stedet for å backportere én rettelse, kunne de fikse 10 forskjellige feil til felles fordel eller bli med i gjennomgangen av foreslåtte endringer og forhindrer buggy-kode fra å bli inkludert i kjernen. Ressurser kan også brukes til å lage nye verktøy for testing og analyse av kode som vil tillate tidlig oppdagelse av vanlige klasser av feil som dukker opp igjen og igjen.
Kees Cook foreslår også mer aktivt å bruke automatisert og uklar testing direkte i kjerneutviklingsprosessen, bruke kontinuerlige integrasjonssystemer og forlate arkaisk utviklingsadministrasjon via e-post. For tiden er effektiv testing hemmet av det faktum at de viktigste testprosessene er atskilt fra utvikling og skjer etter at utgivelsene er dannet. Keys anbefalte også å bruke språk som gir et høyere sikkerhetsnivå, for eksempel Rust, ved utvikling for å redusere antall feil.
Kilde: opennet.ru