Paul Souders/Getty ImagesI en ny hvitbok, Vendor Kjerner, feil og stabilitet, infrastrukturprogramvaren og Rocky Linux-selskapet CIQ presenterer et overbevisende argument for at Linux-leverandørkjerner er plaget med sikkerhetssårbarheter på grunn av de mangelfulle ingeniørprosessene som backport fikser.
Også: De tre beste Linux 6.9 kjerneoppgraderingene
Selv om dette kan sjokkere noen, er det en åpen hemmelighet i Linux-fellesskapet. Som Greg Kroah-Hartman, Linux stabil kjerne vedlikeholder og et fremtredende medlem av kjernesikkerhetsteamet, nylig sa: For å være sikker, bør du alltid bruke den siste langsiktige stabile kjernen. Stikkordet her er “siste.” Det er ikke nok å bruke en LTS. Du må bruke den mest oppdaterte utgivelsen for å være så sikker som mulig.
Dessverre er det nesten ingen som gjør det. Likevel, som Google Linux-kjerneingeniør Kees Cook forklarte, “Så hva skal en leverandør gjøre? Svaret er enkelt: hvis det er smertefullt: Oppdater kontinuerlig til den nyeste kjerneutgivelsen, enten major eller stabil."
Hvorfor? Som Kroah-Hartman forklarte, “Enhver feil har potensial til å være et sikkerhetsproblem på kjernenivå.”
Jonathan Corbet, Linux-kjerneutvikler og LWN-sjefredaktør, var enig: “I kjernen kan omtrent enhver feil, hvis du er smart nok, utnyttes til å kompromittere systemet. Kjernen er på et unikt sted i systemet … den gjør mange vanlige feil om til sårbarheter."
Det CIQ-ingeniørene Ronnie Sahlberg, Jonathan Maple og Jeremy Allison gjorde var å sette harde tall bak denne posisjonen. Papiret deres viser at – med dagens ingeniørpraksis – er nesten alle leverandørkjerner iboende usikre og at det er umulig å sikre disse kjernene.
Det er fordi Linux-leverandørkjerner har blitt opprettet ved å ta et øyeblikksbilde av en spesifikk Linux-utgivelse og deretter tilbakeportere valgte rettelser etter hvert som endringer skjer i oppstrøms git-treet. Denne metoden, utviklet i en tid da enhetsdrivere utenfor treet var utbredt, har som mål å forbedre stabiliteten og sikkerheten ved å velge endringer i bakporten. Denne artikkelen undersøker hvordan dette fungerer i praksis ved å analysere endringshastigheten og feilantallet i Red Hat Enterprise Linux (RHEL) 8.8, kjerneversjon 4.18.0-477.27.1, og sammenligne det med oppstrømskjerner fra kernel.org.
Også: Hvordan Red Hat omfavner AI for å lage systemadministratorer' livet lettere
Selv om programmererne undersøkte RHEL 8.8 spesifikt, er dette et generelt problem. De ville ha funnet de samme resultatene hvis de hadde undersøkt SUSE, Ubuntu eller Debian Linux. Rullende utgivelser av Linux-distroer som Arch, Gentoo og OpenSUSE Tumbleweed slipper stadig de siste oppdateringene, men de brukes ikke i bedrifter.
Deres analyse av RHEL 8.8-kjernen avslører 111 750 individuelle forpliktelser i endringsloggen. Disse dataene, selv om de ikke beskriver innholdet eller størrelsen på forpliktelsene, gir en generell forståelse av tilbakeporteringsprosessen. Til å begynne med var det en jevn hastighet på tilbakeportering, men denne reduserte rundt november 2021 og igjen betydelig i november 2022, tilsvarende utgivelsen av henholdsvis RHEL 8.5 og RHEL 8.7. Dette mønsteret, mener forfatterne, reflekterer et skifte mot mer konservativ backporting for å forbedre stabiliteten etter hvert som den store utgivelsessyklusen skrider frem.
Undersøkelsen deres fant 5034 ufiksede feil i RHEL 8.6; 4 767 ufiksede feil i RHEL 8.7; og 4 594 ufiksede feil i RHEL 8.8.
Disse tallene representerer kjente feil med oppstrømsrettinger som ikke er tilbakeportert til RHEL. Det tidligere opphøret av backporting i RHEL 8.6 og 8.7 har ført til flere ufiksede feil sammenlignet med RHEL 8.8. Red Hats praksis med å ikke publisere de fullstendige kildekodeendringene øker kompleksiteten, noe som resulterer i mulige falske positive og negative i dataene CIQ måtte jobbe med. Til tross for disse begrensningene, rapporterer CIQ at manuelle kontroller tyder på en høy nøyaktighet når det gjelder å identifisere manglende rettelser.
Også: Ubuntu 24.04: Denne flotte nye Linux-distroen er ikke bare rask – det er en festning
sterk>
I motsetning til antagelsen om at feil blir raskt fikset oppstrøms, vedvarer mange i lengre perioder før de løses. Denne forsinkelsen påvirker kjernekvaliteten, ettersom den langsomme tilbakeporteringsprosessen resulterer i et økende antall kjente, ufiksede feil, som undergraver kjernestabilitet og sikkerhet over tid.
Siden Linux-kjerneutviklere har tatt over administrasjonen av Linux' s Common Vulnerabilities and Exposures (CVEs), 270 nye CVEer i mars 2024 og 342 i april 2024 er rapportert. Disse er allerede fikset i den stabile Linux-kjerne git-grenen.
Likevel understreker de rene tallene viktigheten av å bruke stabile oppstrømskjerner for økt sikkerhet. Volumet av nye CVEer og mangelen på en embargoperiode for rettelser nødvendiggjør en proaktiv tilnærming fra organisasjoner for å evaluere og adressere disse sårbarhetene.
Dessuten, selv om RHEL 8.8 ikke har blitt aktivt utviklet siden slutten av 2022, påvirker fortsatt omtrent 10 % av alle nyoppdagede feil den. RHEL 8.8s siste store sett med feilrettinger kom i mai 2023. Det samme gjelder andre, eldre (men fortsatt støttede) enterprise Linux-distros. Enda mer urovekkende, ifølge CIQ: “Noen av de manglende rettelsene vi undersøkte er eksplisitt avslørt som å kunne utnyttes fra brukerplass.”
Også: Linus Torvalds tar på seg onde utviklere, maskinvarefeil og 'morsomt' AI-hype
Derfor konkluderte CIQ-teamet at den tradisjonelle leverandørkjernemodellen, preget av selektiv backporting, er feil. Det økende antallet kjente, ufiksede feil antyder at leverandørkjerner er mindre sikre enn oppstrøms stabile kjerner. Teamet tar til orde for et skifte mot å bruke stabile kjernegrener fra kernel.org for bedre sikkerhet og feilhåndtering.
I følge forfatterne, “skaper dette et sterkt insentiv” for sikkerhetsbevisste kunder å ta i bruk stabile kjerner fremfor leverandørspesifikke. De hevder, “Vi tror at den eneste realistiske måten for en kunde å vite at de kjører en kjerne som er så sikker som mulig, er å bytte til en stabil kjernegren.”
Denne artikkelen er ikke en kritikk av de dedikerte Linux-leverandørens kjerneingeniører. I stedet er det en invitasjon for industrien til å samle seg bak kernel.org stabile kjerner som den optimale langsiktige løsningen. Et slikt skifte vil tillate ingeniører å fokusere mer på å fikse kundespesifikke feil og forbedre funksjoner i stedet for den arbeidskrevende tilbakeporteringsprosessen.
Derfor har de fire kritiske konklusjoner:
Leverandørkjernemodellen er ødelagt og kan ikke repareres. Leverandørkjerner er iboende usikre, med sensyklusstabiliserte leverandørkjerner som er spesielt sårbare.
Det store antallet kjente åpne feil gjør det upraktisk å analysere eller klassifisere dem alle.
Oppstrøms stabile kjerner gir betydelig bedre beskyttelse mot sikkerhetssårbarheter og feil i kjernekoden.
Også: Denne bakdøren ble nesten infisert Linux overalt: The XZ Utils close call
Så, vil leverandører gjøre dette? Av alle de gode sikkerhetsgrunnene til å gå over til oppstrøms stabile kjerner, er det motargumenter som koker ned til dette: Hvis du alltid oppgraderer til den nyeste kjernen, kan du også få stabilitetsproblemer. Et program som fungerer helt fint med 4.18.0-477.27.1-kjernen fungerer kanskje ikke med 4.18.0-477.27.1.el8_8. Selvfølgelig, i det spesifikke tilfellet, fikset den nyere kjernen en viktig sikkerhetsfeil.
Det hele kommer ned til en delikat balansegang mellom sikkerhet og stabilitet. Noen topp Linux-kjerneutviklere og CIQ kommer ned på siden av sikkerheten. Vi får se hva resten av Linux-leverandørfellesskapet har å si.