Linus Torvalds har inkluderet et dokument i kernen, som regulerer processen for behandling af sikkerhedsrelaterede fejl, definerer trusselsmodellen, forklarer, hvilke fejl i kernen der betragtes som sårbarheder, og gennemgår håndtering af fejl, der er blevet identificeret ved hjælp af AI. Dokumentet er udarbejdet af Willy Tarreau, forfatteren af HAProxy og en langvarig udvikler af Linux-kernen, der har haft ansvaret for vedligeholdelsen af flere stabile versioner af kernen. Det er baseret på de aftaler, der blev nået under diskussionen af nyligt opdagede kritiske sårbarheder i kernen, som blev afsløret før publiceringen af rettelserne, og for hvilke det ved hjælp af AI var muligt straks at skabe fungerende exploits.
Den største del af de sikkerhedsrelaterede fejl skal håndteres offentligt for at tiltrække den bredest mulige offentlighed og finde den optimale løsning. Kun kritiske meddelelser om sårbarheder, der let kan udnyttes, som udgør en trussel mod mange brugere og muliggør udvidede privilegier eller funktioner, foreslås sendt til en separat privat mailingliste.
Sårbarheder, der identificeres ved hjælp af AI-assistenter, bør altid diskuteres offentligt, da sådanne problemer ofte opdages samtidigt af flere forskere. Det er dog ikke nødvendigt at afsløre exploit i rapporten — det er tilstrækkeligt at nævne, at det er tilgængeligt, og at det kan sendes privat som svar på anmodning fra den ansvarlige.
Regler for indsendelse af rapporter, der er oprettet ved hjælp af AI-assistenter, beskrives separat. Der sendes mange sådanne rapporter, og de kan til tider hjælpe med at identificere fejl i dårligt anmeldte dele af koden, men de ansvarlige ignorerer ofte dem på grund af lav kvalitet og unøjagtigheder. De primære krav til rapporter, der er oprettet med AI's hjælp, er:
- Kortfattethed, uden overflødige ord og med angivelse af kernen og vigtige detaljer i starten.
- Kun ren tekst uden Markdown-tags og dekoration.
- Forståelse af trusselsmodellen og angivelse af kontrollerede fakta (for eksempel «fejlen giver enhver bruger CAP_NET_ADMIN»), og ikke teoretiske tanker og spekulationer om konsekvenserne af sårbarheden.
- Før du sender rapporten, skal du grundigt teste effektiviteten af exploit'et, der er genereret via AI, og sikre dig, at du kan reproducere problemet.
- Involvering af AI til udvikling og testning af en løsning på det identificerede problem.
Ifølge statistikker om følgefejl indsender flertallet af fejlrapporter, der præsenteres som løsninger på sikkerhedsproblemer, ikke reelle sikkerhedsproblemer og bør behandles som almindelige fejl. En trusselmodel for Linux-kerne er beskrevet for at skelne mellem sårbarheder og almindelige fejl. Blandt de muligheder og garantier, hvis overtrædelse kan betragtes som sårbarhed:
- Isolering på brugerniveau: adgang til filer kun for ejeren, procesminne er utilgængeligt for andre brugere, ptrace er forbudt for andres processer, isolering af IPC og netværkskommunikation.
- Beskyttelse baseret på capabilities: uden CAP_SYS_ADMIN kan man ikke ændre kernelkonfigurationen, hukommelsen, systemtilstanden; uden CAP_NET_ADMIN kan man ikke ændre netværksindstillinger eller opsnappe trafik; uden CAP_SYS_PTRACE kan man ikke spore processer fra andre brugere.
- Bruger-ID-namespacet (CONFIG_USER_NS) tillader ikke-privilegerede brugere at skabe deres isolerede miljøer, der ikke kan påvirke det globale namespace, såsom at ændre tiden, indlæse moduler og montere bloklagringsenheder.
- Debuginterfaces (/proc/kmsg, perf, debugfs), som kan give adgang til følsomme oplysninger, er kun tilgængelige efter eksplicit adgangsgodkendelse fra administrator.
Muligheder, som ikke betragtes som sårbarheder:
- Brug af forældede kernelversioner.
- Kompilering med aktive muligheder for udviklere eller sikkerhedsreducerende indstillinger (f.eks. CONFIG_NOMMU).
- Sikkerhedsindstillinger for sysctl, kommandolinjeindstillinger, filsystemrettigheder, capabilities eller åbning af privilegeret adgang til ikke-privilegerede brugere (f.eks. skriveadgang til procfs og debugfs).
- Problemer i funktioner, der kun er beregnet til udvikling og debugging af kernen, såsom LOCKDEP, KASAN og FAULT_INJECTION, som ikke er beregnet til at blive aktiveret i produktionskonfigurationer.
- Problemer med drivere, moduler og subsystemer i STAGING-sektionen eller markeret som eksperimentelle, usikre eller ubrugelige.
- Brug af tredjeparts kernelmoduler eller uofficielle kerneforks.
- Krav om overdrevne privilegier, såsom behovet for at udføre handlinger med root-rettigheder eller fra en bruger, der har CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO og CAP_SYS_MODULE-rettigheder.
- Teoretiske angreb, der kræver laboratorieforhold, milliarder af forsøg, emulering eller modificering af hardware, uforholdsmæssige omkostninger og urealistiske konfigurationer (f.eks. systemer med titusinder af CPU-kerner).
- Omgåelse af beskyttelsesmekanismer (f.eks. ASLR) uden at demonstrere et exploit. Manglende argumentkontroller og returnerede fejlkoder, der ikke har åbenlyse konsekvenser.
- Tilfældige informationslækager, der ikke kontrolleres af angribere, såsom resterende data i fejlmeldinger og lækager af adresser/pegepinde til kerne-minne uden direkte mulighed for udnyttelse.
- Fejl ved montering af beskadigede diskbilleder, hvis driveren ikke er angivet som egnet til brug med upålidelige medier. Problemer med diskbilleder, der opdages og løses ved at køre fsck-værktøjet.
- Angreb, der kræver fysisk adgang til udstyret, modificering af hardware eller tilslutning af hardwareenheder som DMA-angrebskort og logikanalysatorer, hvis systemet ikke specifikt er konfigureret til at beskytte mod sådanne angreb (IOMMU).
- Regressionsfejl med funktionalitet og ydeevne, der løses ved at justere rettigheder og grænser.
Kilde: opennet.ru
