![\"Kiss](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Den optimale l\u00f8sning ville v\u00e6re kun at overf\u00f8re de mest kritiske rettelser og s\u00e5rbarheder, men det er netop her, at den st\u00f8rste udfordring ligger i at identificere s\u00e5danne fejl. Det st\u00f8rste antal uventede problemer stammer fra brugen af C-sproget, som kr\u00e6ver stor omhu ved h\u00e5ndtering af hukommelse og pegere. Situationen kompliceres af, at mange potentielle rettelser af s\u00e5rbarheder ikke f\u00e5r tildelt CVE-identifikatorer eller f\u00f8rst f\u00e5r en s\u00e5dan identifikator lang tid efter, at rettelsen er offentliggjort. Under s\u00e5danne forhold er det meget sv\u00e6rt for producenterne at skelne mellem sekund\u00e6re rettelser og de kritiske problemer, der p\u00e5virker sikkerheden. If\u00f8lge statistikker bliver mere end 40% af s\u00e5rbarhederne rettet, inden der tildeles en CVE, og den gennemsnitlige forsinkelse mellem offentligg\u00f8relsen af en rettelse og tildelingen af en CVE er tre m\u00e5neder (dvs. i starten opfattes rettelsen som en almindelig fejl, men f\u00f8rst efter nogle m\u00e5neder bliver det klart, at der er tale om en lukning af en s\u00e5rbarhed).<\/p>\nSom et resultat af ikke at have en separat gren med rettelser til s\u00e5rbarheder og uden at modtage oplysninger om forbindelse mellem sikkerhed og de specifikke problemer, st\u00e5r producenterne af produkter baseret p\u00e5 Linux-kernen tilbage med at skulle overf\u00f8re alle rettelser fra de nyeste stabile grene kontinuerligt. Men dette arbejde kr\u00e6ver betydelige arbejdsressourcer og m\u00f8der modstand i virksomhederne p\u00e5 grund af frygt for regresive \u00e6ndringer, der kan forstyrre produktets normale funktion.<\/p>\n
Lad os minde om, at if\u00f8lge Linus Torvalds er alle fejl vigtige, og s\u00e5rbarheder b\u00f8r ikke adskilles fra andre former for fejl og prioriteres i en s\u00e6rskilt kategori. Dette synspunkt forklares ved, at det for den almindelige udvikler, der ikke specialiserer sig i sikkerhedsp\u00f8rgsm\u00e5l, ikke er indlysende, hvordan en rettelse kan have forbindelse til en potentiel s\u00e5rbarhed (for mange rettelser kr\u00e6ver det s\u00e6rskilt audit at forst\u00e5, at de vedr\u00f8rer sikkerheden). If\u00f8lge Linus b\u00f8r sikkerhedsspecialister fra teamene, der er ansvarlige for vedligeholdelse af pakkefiler med kernen i Linux-distributionerne, h\u00e5ndtere sp\u00f8rgsm\u00e5let om at identificere de potentielle s\u00e5rbarheder fra det samlede flow af rettelser.<\/p>\n
Kees Cook mener, at den eneste l\u00f8sning for at opretholde sikkerheden i kernen med rimelige langsigtede omkostninger er at overf\u00f8re ingeni\u00f8rer, der arbejder med portering af rettelser til lokale kerneversioner, til en koordineret indsats for at vedligeholde rettelser og s\u00e5rbarheder i den prim\u00e6re kerne (upstream). I sin nuv\u00e6rende form bruger mange producenter ikke de nyeste versioner af kernen i deres produkter og backporter rettelser p\u00e5 egen h\u00e5nd, hvilket betyder, at ingeni\u00f8rer i forskellige virksomheder duplikerer hinandens arbejde ved at l\u00f8se det samme problem.<\/p>\n
For eksempel, hvis 10 virksomheder, hvor hver har \u00e9n ingeni\u00f8r, der arbejder med backporting af de samme rettelser, omdirigerer disse ingeni\u00f8rer til at rette fejl i upstream, s\u00e5 kunne de i stedet for at portere \u00e9n rettelse, rette 10 forskellige fejl til f\u00e6lles fordel eller deltage i gennemgangen af foresl\u00e5ede \u00e6ndringer og forhindre, at fejlbeh\u00e6ftet kode bliver inkluderet i kernen. Ressourcerne kunne ogs\u00e5 rettes mod at skabe nye v\u00e6rkt\u00f8jer til test og analyse af kode, som ville g\u00f8re det muligt at opdage typiske klasser af fejl, der dukker op gentagne gange, tidligt i processen.<\/p>\n
Kees Cook foresl\u00e5r ogs\u00e5 at bruge automatiseret og fuzzing-testning mere aktivt direkte i udviklingsprocessen af kernen, anvende kontinuerlig integrationssystemer og afvise det for\u00e6ldede udviklingsstyringssystem via email. I \u00f8jeblikket hindres effektiv testning af, at de prim\u00e6re testprocesser er adskilt fra udviklingen og finder sted f\u00f8rst efter frigivelse af versioner. Kees anbefalede ogs\u00e5, at man for at reducere antallet af fejl bruger programmeringssprog, der sikrer mere a high level of security<\/a>, s\u00e5som Rust.<\/p>\n