hvad er UEFI Secure Boot?

UEFI Secure boot er en verifikationsmekanisme til at sikre, at kode lanceret af er tillid til. korrekt, sikker brug af UEFI Secure Boot kræver, at hver binær indlæst ved opstart er valideret mod kendte nøgler, der angiver betroede leverandører og kilder til binære filer eller betroede specifikke binære filer, der kan identificeres via kryptografisk hashing.

de fleste H86-apparater kommer fra fabrikken, der er forudindlæst med Microsoft-nøgler. Dette betyder, at vi generelt kan stole på firmaet på disse systemer for at stole på binære filer, der er underskrevet af Microsoft, og vi er stærkt afhængige af denne antagelse for, at Secure Boot fungerer. Dette er den samme proces, der bruges af Red Hat og SUSE, for eksempel.

mange ARM og andre arkitekturer understøtter også UEFI Secure Boot, men er muligvis ikke forudindlæste nøgler i programmet. På disse arkitekturer kan det være nødvendigt at underskrive boot-billeder med et certifikat, der er indlæst af ejeren af udstyret.

indledende implementeringsplan: implementeringsplan.

Understøttede arkitekturer

• amd64: en shim-binær underskrevet af Microsoft og grub-binær underskrevet af Canonical findes i Ubuntu-hovedarkivet som shim-signeret eller grub-efi-amd64-signeret.

• arm64: fra 20.04 (‘focal’) leveres en shim-binær underskrevet af Microsoft og grub-binær underskrevet af Canonical i Ubuntu-hovedarkivet som shim-signeret eller grub-efi-arm64-signeret. Der er en GRUB bug under undersøgelse, der skal løses, før dette virker ende til ende.

testing UEFI Secure Boot

Hvis du er interesseret i at teste Secure Boot på dit system, se vejledningen her: UEFI/SecureBoot / Testing.

Sådan fungerer UEFI Secure Boot på Ubuntu

på Ubuntu er alle forudbyggede binære filer, der er beregnet til at blive indlæst som en del af opstartsprocessen, med undtagelse af initrd-billedet, underskrevet af Canonical ‘ s UEFI-certifikat, som i sig selv implicit er tillid til ved at være indlejret i shim-loader, selv underskrevet af Microsoft.

på arkitekturer eller systemer, hvor forudindlæste signeringscertifikater fra Microsoft ikke er tilgængelige eller indlæst i Microsoft, kan brugerne erstatte de eksisterende signaturer på shim eller grub og indlæse dem, som de ønsker, og kontrollere mod deres egne certifikater, der er importeret i systemets program.

når systemet starter, indlæser systemet shim binær som angivet i BootEntry variabler. Ubuntu installerer sin egen BootEntry på installationstidspunktet og kan opdatere den når som helst GRUB bootloader opdateres. Da shim binær er underskrevet af Microsoft; det valideres og accepteres af firmaet, når det verificeres mod certifikater, der allerede findes i firmaet. Da shim binary integrerer et kanonisk certifikat såvel som sin egen tillidsdatabase, kan yderligere elementer i opstartsmiljøet ud over at blive underskrevet af et af de acceptable certifikater, der er forudindlæst i programmet, underskrives af Canonical ‘ s UEFI-nøgle.

den næste ting, der er indlæst af shim, er billedet i anden fase. Dette kan være en af to ting: enten GRUB, hvis systemet starter normalt; eller MokManager, hvis nøglestyring er påkrævet, som konfigureret af fastvarevariabler (normalt ændret, når systemet tidligere kørte).

Hvis opstart normalt; GRUB binær (grub*.efi) er indlæst, og dens Validering forsøges mod alle tidligere kendte pålidelige kilder. GRUB-binæren til Ubuntu er underskrevet af den kanoniske UEFI-nøgle, så den valideres med succes, og opstartsprocessen fortsætter.

Hvis opstart for at fortsætte med nøgleadministrationsopgaver, er mokmanager binary (mm*.efi) er indlæst. Denne binære er eksplicit betroet af shim ved at blive underskrevet af en flygtig nøgle, der kun eksisterer, mens shim-binæren bygges. Dette betyder, at kun mokmanager-binæren, der er bygget med en bestemt shim-binær, får lov til at køre og begrænser muligheden for kompromis fra brugen af kompromitterede værktøjer. MokManager tillader enhver bruger, der er til stede på systemkonsollen, at tilmelde nøgler, fjerne betroede nøgler, tilmelde binære hashes og skifte sikker Opstartsvalidering på shim-niveau, men de fleste opgaver kræver, at der indtastes en tidligere indstillet adgangskode for at bekræfte, at brugeren på konsollen faktisk er den person, der anmodede om ændringer. Sådanne adgangskoder overlever kun på tværs af et enkelt løb af shim / MokManager; og ryddes, så snart processen er afsluttet eller annulleret. Når nøglestyring er afsluttet, genstartes systemet og fortsætter ikke blot med opstart, da nøgleadministrationsændringerne muligvis er nødvendige for at fuldføre opstarten.

Når systemet fortsætter med at starte til GRUB; GRUB-processen indlæser enhver påkrævet konfiguration (normalt indlæser konfiguration fra ESP (EFI System Partition) og peger på en anden konfigurationsfil på rod-eller bootpartitionen), som peger den på kernebilledet, der skal indlæses. EFI-applikationer op til dette punkt med fuld adgang til systemvareprogrammet, herunder adgang til at ændre pålidelige Firmavariabler, skal kernen, der skal indlæses, også valideres mod tillidsdatabasen. Officielle Ubuntu-kerner underskrives af den kanoniske UEFI-nøgle, de valideres med succes, og kontrol overleveres til kernen. Initrd-billeder er ikke valideret.

i tilfælde af uofficielle kerner eller kerner, der er bygget af brugere, skal der tages yderligere skridt, hvis brugerne ønsker at indlæse sådanne kerner, mens de bevarer de fulde muligheder i UEFI Secure Boot. Alle kerner skal underskrives for at få lov til at indlæse af GRUB, når UEFI Secure Boot er aktiveret, så brugeren skal fortsætte med deres egen signering. Alternativt kan brugerne ønsker at deaktivere validering i shim mens startet med Secure Boot aktiveret på en officiel kerne ved hjælp af ‘sudo mokutil –disable-validation’, giver en adgangskode, når du bliver bedt om, og genstart; eller at deaktivere Secure Boot i helt.

indtil dette tidspunkt mødes enhver manglende validering af et billede, der skal indlæses, med en kritisk fejl, der stopper opstartsprocessen. Systemet fortsætter ikke med at starte, og kan automatisk genstarte efter en periode, da andre BootEntry-variabler kan indeholde opstartsstier, der er gyldige og pålidelige. når de er indlæst, deaktiverer validerede kerner Opstartstjenesterne, hvorved privilegier falder og effektivt skifter til brugertilstand; hvor adgang til pålidelige variabler er begrænset til skrivebeskyttet. I betragtning af de brede tilladelser, der gives til kernemoduler, skal ethvert modul, der ikke er indbygget i kernen, også valideres ved indlæsning. Moduler bygget og afsendt af Canonical med de officielle kerner er underskrevet af Canonical UEFI nøgle og som sådan, er tillid til. Specialbyggede moduler kræver, at brugeren tager de nødvendige skridt til at underskrive modulerne, før de indlæser dem, er tilladt af kernen. Dette kan opnås ved at bruge kommandoen’ kmodsign’.

usignerede moduler afvises simpelthen af kernen. Ethvert forsøg på at indsætte dem med insmod eller modprobe mislykkes med en fejlmeddelelse.

i betragtning af at mange brugere kræver tredjepartsmoduler for at deres systemer kan fungere korrekt eller for at nogle enheder skal fungere; og at disse tredjepartsmoduler kræver opbygning lokalt på systemet, der skal monteres på den kørende kerne, giver Ubuntu værktøj til at automatisere og forenkle signeringsprocessen.

Hvordan kan jeg gøre ikke-automatiseret signering af drivere?

nogle projekter kræver muligvis brug af brugerdefinerede kernedrivere, der ikke er konfigureret på en sådan måde, at de fungerer med DKMS. I disse tilfælde skal folk gøre brug af de værktøjer, der er inkluderet i den shim-underskrevne pakke: update-secureboot-policy-scriptet er tilgængeligt for at generere en ny MOK (hvis ingen DKMS-byggede moduler allerede har udløst generering af en).

brug følgende kommando til at tilmelde en eksisterende nøgle til shim:

sudo update-secureboot-policy --enroll-key

Hvis der ikke findes nogen MOK, afsluttes scriptet med en meddelelse herom. Hvis nøglen allerede er tilmeldt, vil scriptet afslutte, gør ingenting. Hvis nøglen findes, men den ikke vises at være tilmeldt, bliver brugeren bedt om en adgangskode, der skal bruges efter genstart, så nøglen kan tilmeldes.

man kan generere en ny MOK ved hjælp af følgende kommando:

sudo update-secureboot-policy --new-key

og derefter tilmelde den nyligt genererede nøgle til shim med den tidligere nævnte kommando til den opgave.

kernemoduler kan derefter underskrives med kommandoen kmodsign (se UEFI/SecureBoot / signering) som en del af deres byggeproces.

sikkerhedsmæssige implikationer i Maskinejerns nøgleadministration

den MOK, der genereres på installationstidspunktet eller ved opgradering, er maskinspecifik og kun tilladt af kernen eller shim at underskrive kernemoduler ved hjælp af en specifik KeyUsage OID (1.3.6.1.4.1.2312.16.1.2), der angiver MOK ‘ s begrænsninger.

seneste shim versioner omfatter logik til at følge begrænsningerne i modul-signering-only nøgler. Disse nøgler får lov til at blive indskrevet i shims tillidsdatabase, men vil blive ignoreret, når shim eller GRUB validerer billeder, der skal indlæses i shim. Shims verify () – funktion vil kun validere billeder signeret af nøgler, der ikke omfatter “Module-signering only” (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. Ubuntu-kernerne bruger global trust-databasen (som inkluderer både shim ‘ er og firmaets) og accepterer en hvilken som helst af de inkluderede nøgler som signeringsnøgler, når du indlæser kernemoduler.

i betragtning af de begrænsninger, der pålægges den automatisk genererede MOK, og det faktum, at brugere med superbrugeradgang til systemet og adgang til systemkonsollen for at indtaste den adgangskode, der kræves, når de tilmelder nøgler, allerede har adgang på højt niveau til systemet; den genererede MOK-nøgle opbevares på filsystemet som almindelige filer, der ejes af root med skrivebeskyttede tilladelser. Dette anses for tilstrækkeligt til at begrænse adgangen til MOK til signering af ondsindede brugere eller scripts, især i betragtning af at der ikke findes MOK på systemet, medmindre det kræver tredjepartsdrivere. Dette begrænser muligheden for kompromis fra misbrug af en genereret MOK-nøgle til at underskrive et ondsindet kernemodul. Dette svarer til kompromis med userland-applikationerne, som allerede ville være muligt med superbrugeradgang til systemet, og sikring af dette er uden for UEFI Secure Boot.

tidligere systemer kan have haft Sikker Boot Validering deaktiveret i shim. Som en del af opgraderingsprocessen migreres disse systemer til at genaktivere sikker Bootvalidering i shim og tilmelde en ny MOK-nøgle, når det er relevant.

MOK generation and signing process

nøglegenerering og signeringsproces er lidt anderledes baseret på, om vi har at gøre med en helt ny installation eller en opgradering af systemet, der tidligere kørte Ubuntu; disse to tilfælde er tydeligt markeret nedenfor.

i alle tilfælde, hvis systemet ikke starter i UEFI-tilstand, sker der ingen specielle kernemodulsigneringstrin eller nøglegenerering.

hvis Secure Boot er deaktiveret, sker MOK generation og tilmelding stadig, da brugeren senere kan aktivere Secure Boot. Systemet skal fungere ordentligt, hvis det er tilfældet.

brugeren installerer Ubuntu på et nyt system

brugeren træder gennem installationsprogrammet. Tidligt, når du forbereder dig på at installere, og kun hvis systemet kræver, at tredjepartsmoduler fungerer, bliver brugeren bedt om en systemadgangskode, der tydeligt er markeret som påkrævet, når installationen er afsluttet, og mens systemet installeres, genereres en ny MOK automatisk uden yderligere brugerinteraktion.

tredjepartsdrivere eller kernemoduler, der kræves af systemet, bygges automatisk, når pakken er installeret, og byggeprocessen inkluderer et signeringstrin. Signeringstrinnet bruger automatisk MOK genereret tidligere til at underskrive modulet, således at det straks kan indlæses, når systemet genstartes, og MOK er inkluderet i systemets tillidsdatabase.

når installationen er afsluttet, og systemet genstartes, bliver brugeren ved første opstart præsenteret for mokmanager-programmet (en del af den installerede shim-loader) som et sæt tekstmoduspaneler, som alle brugeren til at tilmelde den genererede MOK. Brugeren vælger” Tilmeld MOK”, får vist et fingeraftryk af certifikatet for at tilmelde sig og bliver bedt om at bekræfte tilmeldingen. Når det er bekræftet, indtastes den nye MOK i programmet, og brugeren bliver bedt om at genstarte systemet.

når systemet genstarter, indlæses tredjepartsdrivere, der er underskrevet af den netop tilmeldte MOK, efter behov.

brugeren opgraderer et UEFI-aktiveret Ubuntu-system til en ny udgivelse, hvor systemet kræver tredjepartsdrivere

ved opgradering opgraderes shim-og shim-signerede pakker. Den shim-signerede pakkesopgaver efter installation fortsætter med at generere en ny MOK og beder brugeren om en adgangskode, der tydeligt nævnes som påkrævet, når opgraderingsprocessen er afsluttet, og systemet genstartes.

under opgraderingen opgraderes kernepakkerne og tredjepartsmodulerne. Tredjepartsmoduler genopbygges til de nye kerner, og deres post-build-proces fortsætter med automatisk at underskrive dem med MOK.

efter opgradering anbefales brugeren at genstarte deres system.

ved genstart præsenteres brugeren for mokmanager-programmet (en del af den installerede shim-loader) som et sæt teksttilstandspaneler, som alle brugeren skal tilmelde den genererede MOK. Brugeren vælger” Tilmeld MOK”, får vist et fingeraftryk af certifikatet for at tilmelde sig og bliver bedt om at bekræfte tilmeldingen. Brugeren får også en prompt til at genaktivere Sikker Boot validering (i tilfælde af at den blev fundet deaktiveret); og MokManager kræver igen bekræftelse fra brugeren. Når alle trin er bekræftet, aktiveres shim-Validering igen, den nye MOK indtastes i programmet, og brugeren bliver bedt om at genstarte systemet.

når systemet genstarter, indlæses tredjepartsdrivere, der er underskrevet af den netop tilmeldte MOK, efter behov.

i alle tilfælde, når systemet kører med UEFI Secure Boot aktiveret og en nylig version af shim; installationen af ethvert nyt DKMS-modul (tredjepartsdriver) fortsætter med at underskrive det indbyggede modul med MOK. Dette sker uden brugerinteraktion, hvis der findes en gyldig MOK-nøgle på systemet og ser ud til allerede at være tilmeldt.

Hvis der ikke findes nogen MOK, eller den eksisterende MOK ikke er tilmeldt, oprettes en ny nøgle automatisk lige før underskrivelsen, og brugeren bliver bedt om at tilmelde nøglen ved at angive en adgangskode, der kræves ved genstart.