Ubuntu Wiki

Hvad er UEFI Secure Boot?

UEFI Secure boot er en verifikationsmekanisme, der sikrer, at kode, der lanceres af firmware, er pålidelig.

En korrekt og sikker brug af UEFI Secure Boot kræver, at hver binær fil, der indlæses ved opstart, valideres i forhold til kendte nøgler i firmwaren, der angiver pålidelige leverandører og kilder til binærfilerne eller pålidelige specifikke binærfiler, der kan identificeres via kryptografisk hashing.

De fleste x86-hardware leveres fra fabrikken forudindlæst med Microsoft-nøgler. Det betyder, at vi generelt kan stole på, at firmwaren på disse systemer stoler på binære filer, der er signeret af Microsoft, og Linux-fællesskabet er i høj grad afhængig af denne antagelse, for at Secure Boot kan fungere. Det er den samme proces, der f.eks. anvendes af Red Hat og SUSE.

Mange ARM-arkitekturer og andre arkitekturer understøtter også UEFI Secure Boot, men de kan ikke forudindlæse nøgler i firmwaren. På disse arkitekturer kan det være nødvendigt at re-signere boot images med et certifikat, der er indlæst i firmwaren af ejeren af hardwaren.

Initial implementeringsplan: Implementeringsplan.

Støttede arkitekturer

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

• arm64: Fra og med 20.04 (“focal”) findes der i Ubuntu-hovedarkivet en binær shim-binær signeret af Microsoft og en binær grub-binær signeret af Canonical som shim-signeret eller grub-efi-arm64-signeret. Der er en GRUB-fejl under undersøgelse, som skal løses, før dette fungerer ende til ende.

Test af UEFI Secure Boot

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

Sådan fungerer UEFI Secure Boot på Ubuntu

På Ubuntu er alle prækomponerede binære filer, der er beregnet til at blive indlæst som en del af opstartsprocessen, med undtagelse af initrd-aftrykket, signeret af Canonicals UEFI-certifikat, som selv er implicit betroet ved at være indlejret i shim-loader, der selv er signeret af Microsoft.

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

Når systemet starter op, indlæser firmwaren den binære shim-version som angivet i firmwarens BootEntry-variabler. Ubuntu installerer sit eget BootEntry på installationstidspunktet og kan opdatere det hver gang GRUB-bootloaderen opdateres. Da shim-binærfilen er signeret af Microsoft, valideres og accepteres den af firmwaren, når den verificeres i forhold til certifikater, der allerede findes i firmwaren. Da shim-binærfilen indlejrer et Canonical-certifikat samt sin egen tillidsdatabase, kan yderligere elementer i opstartsmiljøet, ud over at være signeret af et af de acceptable certifikater, der er forudindlæst i firmwaren, også være signeret af Canonicals UEFI-nøgle.

Den næste ting, der indlæses af shim, er andet trin-aftryk. Det kan være en af to ting: enten GRUB, hvis systemet starter normalt op, eller MokManager, hvis nøglehåndtering er påkrævet, som konfigureret af firmwarevariabler (som regel ændret, da systemet tidligere kørte).

Hvis der startes normalt; GRUB-binærfilen (grub*.efi) indlæses, og dens validering forsøges i forhold til alle tidligere kendte pålidelige kilder. GRUB-binærfilen til Ubuntu er signeret af Canonical UEFI-nøglen, så den valideres med succes, og opstartsprocessen fortsætter.

Hvis opstart skal fortsætte med nøglehåndteringsopgaver, indlæses MokManager-binærfilen (mm*.efi). Denne binære fil er eksplicit betroet af shim ved at være signeret af en flygtig nøgle, der kun eksisterer, mens den binære shim-fil er ved at blive bygget. Det betyder, at kun den binære MokManager-binærfil, der er bygget med en bestemt shim-binærfil, får lov til at køre, og det begrænser muligheden for kompromittering ved brug af kompromitterede værktøjer. MokManager giver enhver bruger, der er til stede på systemkonsollen, mulighed for at registrere nøgler, fjerne betroede nøgler, registrere binære hashes og slå Secure Boot-validering til 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 har anmodet om ændringer. Sådanne adgangskoder overlever kun på tværs af en enkelt kørsel af shim / MokManager; og de slettes, så snart processen er afsluttet eller annulleret. Når nøglehåndteringen er afsluttet, genstartes systemet og fortsætter ikke blot med at starte op, da ændringerne i nøglehåndteringen kan være nødvendige for at gennemføre opstarten med succes.

Når systemet fortsætter opstart til GRUB; GRUB-processen indlæser enhver nødvendig konfiguration (normalt indlæsning af konfiguration fra ESP (EFI System Partition), der peger på en anden konfigurationsfil på root- eller boot-partitionen), som vil pege den til det kerneaftryk, der skal indlæses.

EFI-applikationer har indtil dette punkt fuld adgang til systemets firmware, herunder adgang til at ændre betroede firmwarevariabler, den kerne, der skal indlæses, skal også valideres i forhold til tillidsdatabasen. Officielle Ubuntu-kerner, der er signeret af Canonical UEFI-nøglen, valideres med succes, og kontrollen overdrages til kernen. Initrd-images bliver ikke valideret.

Hvis der er tale om uofficielle kerner eller kerner, der er bygget af brugere, skal der tages yderligere skridt, hvis brugerne ønsker at indlæse sådanne kerner, samtidig med at de beholder alle mulighederne i UEFI Secure Boot. Alle kerner skal være signeret for at få lov til at blive indlæst af GRUB, når UEFI Secure Boot er aktiveret, så brugeren skal selv foretage sin egen signering. Alternativt kan brugere ønske at deaktivere validering i shim, mens de starter op med Secure Boot aktiveret på en officiel kerne ved at bruge “sudo mokutil –disable-validation”, angive en adgangskode, når de bliver bedt om det, og genstarte; eller at deaktivere Secure Boot i firmware helt og holdent.

Hertil er enhver manglende validering af et image, der skal indlæses, mødt med en kritisk fejl, som stopper opstartsprocessen. Systemet fortsætter ikke med at starte op, og kan automatisk genstarte efter et stykke tid, da andre BootEntry-variabler kan indeholde opstartsstier, der er gyldige og betroede.

Når de er indlæst, vil validerede kerner deaktivere firmwarens Boot Services, hvorved de mister privilegier og effektivt skifter til brugertilstand; hvor adgangen til betroede 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, der er bygget og leveret af Canonical sammen med de officielle kerner, er signeret af Canonical UEFI-nøglen og er som sådan betroede. Brugerdefinerede moduler kræver, at brugeren tager de nødvendige skridt til at signere modulerne, før de kan indlæses af kernen. Dette kan opnås ved at bruge kommandoen “kmodsign” .

Usignerede moduler bliver simpelthen afvist af kernen. Ethvert forsøg på at indsætte dem med insmod eller modprobe vil mislykkes med en fejlmeddelelse.

I betragtning af at mange brugere har brug for tredjepartsmoduler for at få deres systemer til at fungere korrekt eller for at få nogle enheder til at fungere; og at disse tredjepartsmoduler kræver, at de bygges lokalt på systemet for at blive tilpasset den kørende kerne, tilbyder Ubuntu værktøj til at automatisere og forenkle signeringsprocessen.

Hvordan kan jeg lave ikke-automatisk signering af drivere?

Nogle projekter kan kræve brug af brugerdefinerede kerne-drivere, som ikke er sat op på en sådan måde, at de fungerer med DKMS. I disse tilfælde bør folk gøre brug af de værktøjer, der er inkluderet i shim-signed-pakken: scriptet update-secureboot-policy er tilgængeligt til at generere en ny MOK (hvis ingen DKMS-byggede moduler har udløst generering af en sådan allerede).

Brug følgende kommando til at indskrive en eksisterende nøgle i shim:

sudo update-secureboot-policy --enroll-key

Hvis der ikke findes nogen MOK, vil scriptet afsluttes med en meddelelse herom. Hvis nøglen allerede er tilmeldt, afsluttes scriptet uden at gøre noget. Hvis nøglen findes, men det ikke vises, at den er indskrevet, vil brugeren blive bedt om at angive et kodeord, som skal bruges efter genstart, så nøglen kan indskrives.

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

sudo update-secureboot-policy --new-key

Og derefter indskrive den nyligt genererede nøgle i shim med den tidligere nævnte kommando til denne opgave.

Kernelmoduler kan derefter signeres med kommandoen kmodsign (se UEFI/SecureBoot/Signing) som en del af deres opbygningsproces.

Sikkerhedsimplikationer i Machine-Owner Key management

Den MOK, der genereres på installationstidspunktet eller ved opgradering, er maskinspecifik og kun tilladt af kernen eller shim til at signere kernemoduler ved brug af en specifik KeyUsage OID (1.3.6.1.4.4.1.1.2312.16.1.1.2), der angiver MOK’ens begrænsninger.

Nyere shim-versioner indeholder logik til at følge begrænsningerne for nøgler, der kun signerer moduler. Disse nøgler vil få lov til at blive tilmeldt firmwaren i shim’s trustdatabase, men vil blive ignoreret, når shim eller GRUB validerer images til indlæsning i firmwaren. Shims verify()-funktion vil kun validere billeder, der er signeret af nøgler, som ikke indeholder OID’en “Module-signing only” (1.3.6.6.1.1.4.1.1.2312.16.1.1.2) KeyUsage. Ubuntu-kernerne bruger den globale trustdatabase (som omfatter både shim- og firmware-databasen) og accepterer alle de inkluderede nøgler som signeringsnøgler ved indlæsning af kernemoduler.

I betragtning af de begrænsninger, der er pålagt 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 ved registrering af 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 at være tilstrækkeligt til at begrænse adgangen til MOK til signering for ondsindede brugere eller scripts, især i betragtning af at der ikke findes nogen MOK på systemet, medmindre det kræver drivere fra tredjepart. Dette begrænser muligheden for kompromittering som følge af misbrug af en genereret MOK-nøgle til signering af et ondsindet kernemodul. Dette svarer til at kompromittere brugerlandsprogrammer, hvilket allerede ville være muligt med superbrugeradgang til systemet, og sikring af dette er uden for UEFI Secure Boot’s anvendelsesområde.

På tidligere systemer kan Secure Boot-validering have været deaktiveret i shim. Som en del af opgraderingsprocessen vil disse systemer blive migreret til genaktivering af Secure Boot-validering i shim og registrering af en ny MOK-nøgle, hvis det er relevant.

MOK-generering og signeringsproces

Nøglegenerering og signeringsprocessen er lidt forskellig alt efter, om der er tale om en helt ny installation eller en opgradering af et system, der tidligere kørte Ubuntu; disse to tilfælde er tydeligt markeret nedenfor.

I alle tilfælde, hvis systemet ikke starter op i UEFI-tilstand, vil der ikke ske nogen særlige trin for signering af kernemodulet eller nøglegenerering.

Hvis Secure Boot er deaktiveret, sker MOK-generering og registrering stadig, da brugeren senere kan aktivere Secure Boot. De systemet bør fungere korrekt, hvis det er tilfældet.

Brugeren installerer Ubuntu på et nyt system

Brugeren går gennem installationsprogrammet. Tidligt, når installationen forberedes, og kun hvis systemet kræver moduler fra tredjeparter for at fungere, bliver brugeren bedt om en systemadgangskode, som er tydeligt markeret som værende nødvendig, når installationen er færdig, og mens systemet installeres, genereres en ny MOK automatisk uden yderligere brugerinteraktion.

Drivere eller kernemoduler fra tredjepart, som systemet kræver, bliver automatisk bygget, når pakken installeres, og byggeprocessen omfatter et signeringstrin. Signeringstrinnet bruger automatisk den tidligere genererede MOK til at signere modulet, således at det straks kan indlæses, når systemet er genstartet, og MOK’en er inkluderet i systemets tillidsdatabase.

Når installationen er afsluttet, og systemet genstartes, præsenteres brugeren ved første opstart for MokManager-programmet (en del af den installerede shim-loader), som et sæt paneler i teksttilstand, der alle brugeren til at tilmelde den genererede MOK. Brugeren vælger “Enroll MOK”, får vist et fingeraftryk af det certifikat, der skal tilmeldes, og bliver bedt om at bekræfte tilmeldingen. Når det er bekræftet, indlæses det nye MOK i firmwaren, og brugeren bliver bedt om at genstarte systemet.

Når systemet genstartes, indlæses drivere fra tredjeparter, der er underskrevet af den MOK, der netop er tilmeldt, efter behov.

Brugeren opgraderer et UEFI-aktiveret Ubuntu-system til en ny version, hvor systemet kræver drivere fra tredjepart

Ved opgraderingen opgraderes shim- og shim-signerede pakker. Den shim-signerede pakkes post-installationsopgaver fortsætter med at generere en ny MOK og beder brugeren om en adgangskode, der tydeligt nævnes som værende nødvendig, når opgraderingsprocessen er afsluttet, og systemet er genstartet.

Under opgraderingen opgraderes kernelpakkerne og tredjepartsmoduler. Tredjepartsmoduler genopbygges til de nye kerner, og deres post-build-proces fortsætter med automatisk at signere dem med MOK’en.

Efter opgraderingen anbefales det brugeren at genstarte sit system.

Ved genstart præsenteres brugeren for MokManager-programmet (en del af den installerede shim-loader), som et sæt af paneler i teksttilstand, der alle brugeren til at tilmelde den genererede MOK. Brugeren vælger “Enroll MOK”, får vist et fingeraftryk af det certifikat, der skal tilmeldes, og bliver bedt om at bekræfte tilmeldingen. Brugeren bliver også præsenteret for en anmodning om at genaktivere validering af Secure Boot (i tilfælde af at det blev konstateret, at den var deaktiveret), og MokManager kræver igen en bekræftelse fra brugeren. Når alle trin er bekræftet, genaktiveres shim-validering, den nye MOK indtastes i firmware, og brugeren bliver bedt om at genstarte systemet.

Når systemet genstartes, vil drivere fra tredjeparter, der er underskrevet af den netop indskrevne MOK, blive indlæst efter behov.

I alle tilfælde, når systemet kører med UEFI Secure Boot aktiveret og en nyere version af shim, vil installationen af ethvert nyt DKMS-modul (driver fra tredjepart) fortsætte med at signere det indbyggede modul med MOK’en. Dette vil ske uden brugerinteraktion, hvis der findes en gyldig MOK-nøgle på systemet, som allerede synes at være registreret.

Hvis der ikke findes nogen MOK, eller hvis den eksisterende MOK ikke er tilmeldt, vil der automatisk blive oprettet en ny nøgle lige før signeringen, og brugeren vil blive bedt om at tilmelde nøglen ved at angive et kodeord, som vil blive krævet ved genstart.