Ubuntu Wiki

Vad är UEFI Secure Boot?

UEFI Secure Boot är en verifieringsmekanism som säkerställer att den kod som startas av den fasta programvaran är tillförlitlig.

En korrekt och säker användning av UEFI Secure Boot kräver att varje binär kod som laddas vid uppstart valideras mot kända nycklar som finns i den fasta programvaran och som anger betrodda leverantörer och källor för binärkoden, eller betrodda specifika binärkoder som kan identifieras via kryptografisk hashning.

De flesta x86-hårdvaror levereras från fabriken förinstallerade med Microsoft-nycklar. Detta innebär att vi i allmänhet kan lita på att den fasta programvaran på dessa system litar på binärer som är signerade av Microsoft, och Linux-samhället förlitar sig i hög grad på detta antagande för att Secure Boot ska fungera. Det är samma process som används av till exempel Red Hat och SUSE.

Många ARM- och andra arkitekturer har också stöd för UEFI Secure Boot, men kanske inte förinstallerar nycklar i den fasta programvaran. På dessa arkitekturer kan det vara nödvändigt att återigen signera uppstartsavbildningar med ett certifikat som laddas in i den fasta programvaran av hårdvarans ägare.

Initiell genomförandeplan: Genomförandeplan.

Stödda arkitekturer

• amd64: En binär shim signerad av Microsoft och en binär grub signerad av Canonical finns i Ubuntus huvudarkiv som shim-signerad eller grub-efi-amd64-signerad.

• arm64: Från och med 20.04 (”focal”) finns en binär shim signerad av Microsoft och en binär grub signerad av Canonical i Ubuntus huvudarkiv som shim-signerad eller grub-efi-arm64-signerad. Det finns ett GRUB-bugg under utredning som måste lösas innan detta fungerar från början till slut.

Test av UEFI Secure Boot

Om du är intresserad av att testa Secure Boot på ditt system kan du läsa hur man gör här: UEFI/SecureBoot/Testing.

Hur UEFI Secure Boot fungerar på Ubuntu

På Ubuntu är alla förbyggda binärer som är avsedda att laddas som en del av uppstartsprocessen, med undantag för initrd-avbildningen, signerade av Canonicals UEFI-certifikat, som i sig självt är implicit betrodd genom att det är inbäddat i shim-laddaren, som i sig är signerad av Microsoft.

På arkitekturer eller system där förinstallerade signeringscertifikat från Microsoft inte finns tillgängliga eller laddas in i firmware, kan användarna ersätta de befintliga signaturerna på shim eller grub och ladda dem som de vill, genom att verifiera mot sina egna certifikat som importerats i systemets firmware.

När systemet startar laddar den fasta programvaran den binära shim-filen enligt vad som anges i firmware BootEntry-variablerna. Ubuntu installerar sitt eget BootEntry vid installationstillfället och kan uppdatera det varje gång GRUB bootloader uppdateras. Eftersom shimbinärfilen är signerad av Microsoft valideras och accepteras den av den fasta programvaran när den verifieras mot certifikat som redan finns i den fasta programvaran. Eftersom den binära shim-versionen innehåller ett Canonical-certifikat och en egen förtroendedatabas kan ytterligare delar av uppstartsmiljön, förutom att vara signerade av ett av de godtagbara certifikat som förinstallerats i den fasta programvaran, även vara signerade av Canonicals UEFI-nyckel.

Nästa sak som laddas av shim är avbildningen för andra steget. Detta kan vara en av två saker: antingen GRUB, om systemet startar normalt, eller MokManager, om nyckelhantering krävs, vilket konfigureras av firmwarevariabler (vanligtvis ändrade när systemet kördes tidigare).

Om systemet startar normalt laddas GRUB binärfilen (grub*.efi) och dess validering försöks mot alla tidigare kända betrodda källor. Den binära GRUB-filen för Ubuntu är signerad av Canonicals UEFI-nyckel, så den valideras framgångsrikt och uppstartsprocessen fortsätter.

Om uppstart sker för att fortsätta med nyckelhanteringsuppgifter laddas binärfilen MokManager (mm*.efi). Denna binärfil är uttryckligen betrodd av shim genom att den är signerad av en efemär nyckel som endast existerar medan shimbinärfilen byggs. Detta innebär att endast den binära MokManager-binärfilen som byggs med en viss binärfil för shim kommer att tillåtas att köras och begränsar möjligheten till kompromiss genom användning av komprometterade verktyg. MokManager gör det möjligt för alla användare som befinner sig i systemkonsolen att registrera nycklar, ta bort betrodda nycklar, registrera binära hashkoder och aktivera Secure Boot-validering på shim-nivå, men för de flesta uppgifter krävs det att ett tidigare fastställt lösenord anges för att bekräfta att användaren i konsolen verkligen är den person som begärt ändringarna. Sådana lösenord överlever bara under en enda körning av shim/MokManager och raderas så snart processen avslutas eller avbryts. När nyckelhanteringen är klar startas systemet om och fortsätter inte bara med uppstarten, eftersom ändringarna i nyckelhanteringen kan krävas för att uppstarten ska lyckas.

När systemet fortsätter att starta upp till GRUB laddar GRUB-processen in all nödvändig konfiguration (vanligtvis laddar GRUB-processen in konfiguration från ESP (EFI System Partition) och pekar på en annan konfigurationsfil på rot- eller uppstartspartitionen), som pekar på den kärnavbildning som ska laddas.

EFI-applikationer har fram till denna punkt full tillgång till systemets fasta programvara, inklusive tillgång till att ändra betrodda fasta programvaruvariabler, den kärna som ska laddas måste också valideras mot förtroendedatabasen. Officiella Ubuntu-kärnor signeras av Canonicals UEFI-nyckel, de valideras framgångsrikt och kontrollen överlåts till kärnan. Initrd-avbildningar valideras inte.

I fallet med inofficiella kärnor, eller kärnor som byggts av användare, måste ytterligare åtgärder vidtas om användare vill ladda sådana kärnor samtidigt som de behåller alla möjligheter som UEFI Secure Boot erbjuder. Alla kärnor måste signeras för att tillåtas laddas av GRUB när UEFI Secure Boot är aktiverad, så användaren måste fortsätta med sin egen signering. Alternativt kan användarna välja att inaktivera valideringen i shim när de startar upp med Secure Boot aktiverad på en officiell kärna genom att använda ”sudo mokutil –disable-validation”, ange ett lösenord när de blir tillfrågade och starta om, eller att inaktivera Secure Boot i firmware helt och hållet.

Här fram till nu möts varje misslyckande med att validera en avbildning som ska laddas av ett kritiskt fel som stoppar uppstartsprocessen. Systemet fortsätter inte att starta upp och kan automatiskt starta om efter en viss tid eftersom andra BootEntry-variabler kan innehålla giltiga och betrodda startvägar.

När de har laddats kommer validerade kärnor att inaktivera den fasta programvarans Boot Services, vilket innebär att privilegier tas bort och att man i praktiken övergår till användarläge, där tillgången till betrodda variabler är begränsad till skrivskyddad. Med tanke på de omfattande behörigheter som ges till kärnmoduler måste alla moduler som inte är inbyggda i kärnan också valideras när de laddas. Moduler som byggs och levereras av Canonical tillsammans med de officiella kärnorna är signerade av Canonicals UEFI-nyckel och är därför betrodda. Anpassade moduler kräver att användaren vidtar nödvändiga åtgärder för att signera modulerna innan de kan laddas av kärnan. Detta kan göras med hjälp av kommandot ”kmodsign” .

Osignerade moduler nekas helt enkelt av kärnan. Alla försök att lägga in dem med insmod eller modprobe misslyckas med ett felmeddelande.

Med tanke på att många användare behöver moduler från tredje part för att deras system ska fungera korrekt eller för att vissa enheter ska fungera, och att dessa moduler från tredje part kräver att de byggs lokalt på systemet för att anpassas till den körda kärnan, tillhandahåller Ubuntu verktyg för att automatisera och förenkla signeringsprocessen.

Hur kan jag göra icke-automatiserad signering av drivrutiner?

Vissa projekt kan kräva användning av anpassade kärndrivrutiner som inte är konfigurerade på ett sådant sätt att de fungerar med DKMS. I dessa fall bör man använda verktygen som ingår i paketet shim-signed: skriptet update-secureboot-policy är tillgängligt för att generera en ny MOK (om inga DKMS-byggda moduler har utlöst generering av en sådan redan).

Använd följande kommando för att registrera en befintlig nyckel i shim:

sudo update-secureboot-policy --enroll-key

Om ingen MOK finns kommer skriptet att avslutas med ett meddelande om detta. Om nyckeln redan är inskriven avslutas skriptet utan att göra någonting. Om nyckeln finns men inte visas som inskriven, kommer användaren att uppmanas att ange ett lösenord som ska användas efter omstart, så att nyckeln kan skrivas in.

Man kan generera en ny MOK med följande kommando:

sudo update-secureboot-policy --new-key

Och sedan registrera den nygenererade nyckeln i shim med det tidigare nämnda kommandot för den uppgiften.

Kärnmoduler kan sedan signeras med kommandot kmodsign (se UEFI/SecureBoot/Signing) som en del av deras byggprocess.

Säkerhetsimplikationer i hanteringen av maskinägarnycklar

Den MOK som genereras vid installationstillfället eller vid uppgradering är maskinspecifik, och tillåts endast av kärnan eller shim för att signera kärnmoduler, genom användning av en specifik KeyUsage OID (1.3.6.1.4.1.1.2312.16.1.1.2) som anger begränsningarna för MOK.

Nyare shim-versioner innehåller logik för att följa begränsningarna för nycklar som endast signerar moduler. Dessa nycklar kommer att tillåtas att registreras i den fasta programvaran i shims förtroendedatabas, men kommer att ignoreras när shim eller GRUB validerar avbildningar för att ladda in den fasta programvaran. Shims verify()-funktion kommer endast att validera bilder som undertecknats av nycklar som inte innehåller OID:en ”Module-signing only” (1.3.6.1.1.4.1.2312.16.1.2) KeyUsage. Ubuntu-kärnorna använder den globala förtroendedatabasen (som innehåller både shim- och firmware-databasen) och kommer att acceptera alla ingående nycklar som signeringsnycklar när kärnmoduler laddas.

Med tanke på de begränsningar som gäller för den automatiskt genererade MOK och det faktum att användare med superanvändaråtkomst till systemet och åtkomst till systemkonsolen för att ange det lösenord som krävs vid registrering av nycklar redan har högnivååtkomst till systemet; den genererade MOK-nyckeln förvaras i filsystemet som vanliga filer som ägs av root med enbart läsbehörighet. Detta anses vara tillräckligt för att begränsa tillgången till MOK för signering av illasinnade användare eller skript, särskilt med tanke på att det inte finns någon MOK på systemet om det inte krävs drivrutiner från tredje part för att den ska kunna signeras. Detta begränsar möjligheten till kompromiss genom missbruk av en genererad MOK-nyckel för signering av en skadlig kärnmodul. Detta är likvärdigt med att äventyra användarlandsprogrammen, vilket redan skulle vara möjligt med superanvändartillgång till systemet, och att säkra detta ligger utanför UEFI Secure Boot.

Förra system kan Secure Boot-validering ha inaktiverats i shim. Som en del av uppgraderingsprocessen kommer dessa system att migreras till att återaktivera Secure Boot-validering i shim och registrera en ny MOK-nyckel i förekommande fall.

MOK-generering och signeringsprocess

Nyckelgenerering och signeringsprocessen skiljer sig något beroende på om det rör sig om en helt ny installation eller en uppgradering av ett system som tidigare körde Ubuntu; dessa två fall är tydligt markerade nedan.

I alla fall, om systemet inte startar i UEFI-läge, kommer inga speciella steg för signering av kärnmoduler eller nyckelgenerering att ske.

Om Secure Boot är inaktiverat sker fortfarande MOK-generering och registrering, eftersom användaren senare kan aktivera Secure Boot. Systemet bör fungera korrekt om så är fallet.

Användaren installerar Ubuntu på ett nytt system

Användaren går igenom installationsprogrammet. I ett tidigt skede, när man förbereder installationen och endast om systemet kräver moduler från tredje part för att fungera, uppmanas användaren att ange ett systemlösenord som är tydligt markerat som att det krävs efter att installationen är klar, och medan systemet installeras genereras en ny MOK automatiskt utan ytterligare användarinteraktion.

Drivrutiner eller kärnmoduler från tredje part som systemet kräver byggs automatiskt när paketet installeras, och byggprocessen innehåller ett signeringssteg. Signeringssteget använder automatiskt den MOK som genererats tidigare för att signera modulen, så att den kan laddas omedelbart när systemet startas om och MOK:n finns med i systemets förtroendedatabas.

När installationen är klar och systemet startas om presenteras användaren vid den första uppstarten för MokManager-programmet (en del av den installerade shim-lastaren), som en uppsättning paneler i textläge som låter användaren registrera den genererade MOK:en. Användaren väljer ”Enroll MOK”, visas ett fingeravtryck av det certifikat som ska registreras och uppmanas att bekräfta registreringen. När detta är bekräftat kommer det nya MOK-certifikatet att läggas in i den fasta programvaran och användaren ombeds att starta om systemet.

När systemet startas om laddas vid behov drivrutiner från tredje part som undertecknats av den MOK som just registrerats.

Användaren uppgraderar ett UEFI-aktiverat Ubuntu-system till en ny version där systemet kräver drivrutiner från tredje part

Vid uppgradering uppgraderas shim- och shim-signerade paket. Det shim-signerade paketets uppgifter efter installationen fortsätter med att generera en ny MOK och uppmanar användaren att ange ett lösenord som tydligt nämns som nödvändigt när uppgraderingsprocessen är avslutad och systemet har startats om.

Under uppgraderingen uppgraderas kärnpaket och moduler från tredje part. Moduler från tredje part byggs om för de nya kärnorna och deras process efter byggandet fortsätter med att automatiskt signera dem med MOK.

Efter uppgraderingen rekommenderas användaren att starta om sitt system.

När användaren startar om presenteras MokManager-programmet (en del av den installerade shim-lastaren), som en uppsättning paneler i textläge som gör det möjligt för användaren att registrera den genererade MOK. Användaren väljer ”Enroll MOK”, visas ett fingeravtryck av det certifikat som ska registreras och uppmanas att bekräfta registreringen. Användaren uppmanas också att återaktivera valideringen av Secure Boot (i det fall den var inaktiverad), och MokManager kräver återigen en bekräftelse från användaren. När alla steg är bekräftade återaktiveras shimvalidering, den nya MOK:n läggs in i den fasta programvaran och användaren ombeds att starta om systemet.

När systemet startas om laddas vid behov drivrutiner från tredje part som undertecknats av den MOK som just registrerats.

I samtliga fall kommer installationen av en ny DKMS-modul (drivrutin från tredje part) att fortsätta för att signera den byggda modulen med MOK när systemet körs med UEFI Secure Boot aktiverat och en nyare version av shim. Detta kommer att ske utan användarinteraktion om det finns en giltig MOK-nyckel i systemet och den verkar redan vara registrerad.

Om det inte finns någon MOK eller om den befintliga MOK-nyckeln inte är registrerad kommer en ny nyckel att skapas automatiskt strax före signeringen och användaren kommer att uppmanas att registrera nyckeln genom att ange ett lösenord som kommer att krävas vid omstart.