Vad är UEFI Secure Boot?

UEFI Secure boot är en verifieringsmekanism för att säkerställa att kod som startas av firmware är betrodd.

korrekt, säker användning av UEFI Secure Boot kräver att varje binär laddad vid uppstart valideras mot kända nycklar, som finns i firmware, som betecknar betrodda leverantörer och källor för binärerna, eller betrodda specifika binärer som kan identifieras via kryptografisk hashing.

de flesta x86-hårdvaror kommer från fabriken förinstallerad med Microsoft-nycklar. Det betyder att vi i allmänhet kan lita på firmware på dessa system för att lita på binärer som är signerade av Microsoft, och Linux-samhället är starkt beroende av detta antagande för att Secure Boot ska fungera. Detta är samma process som används av Red Hat och SUSE, till exempel.

många ARM-och andra arkitekturer stöder också UEFI Secure Boot, men kanske inte är förladdningsnycklar i firmware. På dessa arkitekturer kan det vara nödvändigt att signera om startbilder med ett certifikat som laddas i firmware av maskinvaruägaren.

inledande genomförandeplan: genomförandeplan.

arkitekturer som stöds

• amd64: en shim-binär signerad av Microsoft och grub binär signerad av Canonical tillhandahålls i Ubuntu huvudarkiv som shim-signerad eller grub-efi-amd64-signerad.

• arm64: från och med 20.04 (’focal’) tillhandahålls en shim-binär signerad av Microsoft och grub binary signerad av Canonical i Ubuntu huvudarkiv som shim-signerad eller grub-efi-arm64-signerad. Det finns en GRUB bug under utredning som måste lösas innan detta fungerar slut till slut.

testa UEFI Secure Boot

om du är intresserad av att testa Secure Boot på ditt system, se anvisningarna här: UEFI/SecureBoot/Testing.

hur UEFI Secure Boot fungerar på Ubuntu

På Ubuntu är alla förbyggda binärer avsedda att laddas som en del av startprocessen, med undantag för initrd-bilden, signerade av Canonicals UEFI-certifikat, som i sig implicit är betrodd genom att vara inbäddad i shim loader, själv signerad av Microsoft.

på arkitekturer eller system där förinstallerade signeringscertifikat från Microsoft inte är tillgängliga eller laddade i firmware kan användare ersätta de befintliga signaturerna på shim eller grub och ladda dem som de vill, verifiera mot sina egna certifikat som importeras i systemets firmware.

När systemet startar laddar firmware shim binary som anges i firmware Boottentry-variabler. Ubuntu installerar sin egen Boottentry vid installationstiden och kan uppdatera den när som helst GRUB bootloader uppdateras. Eftersom shim binary är signerad av Microsoft; den valideras och accepteras av firmware vid verifiering mot certifikat som redan finns i firmware. Eftersom shim binary bäddar in ett Canonical-certifikat såväl som sin egen förtroendedatabas kan ytterligare delar av startmiljön, förutom att de signeras av ett av de acceptabla certifikaten som är förinstallerade i firmware, undertecknas av Canonicals UEFI-nyckel.

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

om du startar normalt; GRUB binär (grub*.efi) laddas och dess validering försöks mot alla tidigare kända betrodda källor. GRUB-binären för Ubuntu är signerad av den kanoniska UEFI-nyckeln, så den valideras framgångsrikt och startprocessen fortsätter.

om uppstart för att fortsätta med nyckelhanteringsuppgifter, mokmanager binär (mm*.efi) är laddad. Denna binär är uttryckligen betrodd av shim genom att signeras av en efemär nyckel som bara existerar medan shim binär byggs. Detta innebär att endast MokManager binär byggd med en viss shim binär kommer att tillåtas att köra och begränsar möjligheten att kompromissa från användningen av komprometterade verktyg. MokManager tillåter alla användare som finns på systemkonsolen att registrera nycklar, ta bort betrodda nycklar, registrera binära hashar och växla säker Startvalidering på shim-nivå, men de flesta uppgifter kräver att ett tidigare inställt lösenord anges för att bekräfta att användaren på konsolen verkligen är den person som begärde ändringar. Sådana lösenord överlever bara över en enda körning av shim / MokManager; och rensas så snart processen är klar eller avbruten. När nyckelhanteringen är klar startas systemet om och fortsätter inte bara med uppstart, eftersom nyckelhanteringsändringarna kan krävas för att slutföra uppstarten.

När systemet fortsätter att starta till GRUB; GRUB-processen laddar alla nödvändiga konfigurationer (vanligtvis laddar konfiguration från ESP (EFI-systempartitionen) och pekar på en annan konfigurationsfil på rot-eller startpartitionen), vilket kommer att peka på den kärnbild som ska laddas.

EFI-applikationer fram till denna punkt med full åtkomst till systemets firmware, inklusive åtkomst till att ändra betrodda firmwarevariabler, måste kärnan som ska laddas också valideras mot förtroendedatabasen. Officiella Ubuntu-kärnor signeras av den kanoniska UEFI-nyckeln, de valideras framgångsrikt och kontrollen överlämnas till kärnan. Initrd-bilder valideras inte.

När det gäller inofficiella kärnor, eller kärnor byggda av användare, måste ytterligare steg vidtas om användare vill ladda sådana kärnor samtidigt som de behåller alla funktioner i UEFI Secure Boot. Alla kärnor måste vara signerade för att kunna laddas av GRUB när UEFI Secure Boot är aktiverat, så användaren måste fortsätta med sin egen signering. Alternativt kan användare vilja inaktivera validering i shim medan de startas med Secure Boot aktiverad på en officiell kärna genom att använda ’sudo mokutil –disable-validation’, tillhandahålla ett lösenord när du uppmanas och omstart; eller för att inaktivera Secure Boot i firmware helt och hållet.

fram till denna punkt möts eventuella fel med att validera en bild som ska laddas med ett kritiskt fel som stoppar startprocessen. Systemet fortsätter inte att starta och kan automatiskt starta om efter en tidsperiod med tanke på att andra BootEntry-variabler kan innehålla startvägar som är giltiga och betrodda.

när de har laddats kommer validerade kärnor att inaktivera firmwareens starttjänster, vilket släpper privilegier och effektivt byter till användarläge; där åtkomst till betrodda variabler är begränsad till skrivskyddad. Med tanke på de breda behörigheterna som ges till kärnmoduler måste alla moduler som inte är inbyggda i kärnan också valideras vid laddning. Moduler byggda och levererade av Canonical med de officiella kärnorna är signerade av Canonical UEFI-nyckeln och är som sådana betrodda. Specialbyggda moduler kommer att kräva att användaren att vidta nödvändiga åtgärder för att underteckna modulerna innan de laddar dem tillåts av kärnan. Detta kan uppnås genom att använda kommandot ’kmodsign’.

osignerade moduler nekas helt enkelt av kärnan. Varje försök att infoga dem med insmod eller modprobe misslyckas med ett felmeddelande.

Med tanke på att många användare krä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 tredjepartsmoduler kräver att man bygger lokalt på systemet som ska monteras på den löpande kärnan, ger 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 inställda på ett sådant sätt att de fungerar med DKMS. I dessa fall bör människor använda verktygen som ingår i shim-signed-paketet: update-secureboot-policy-skriptet är tillgängligt för att generera en ny MOK (om inga dkms-byggda moduler har utlöst att generera en redan).

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

sudo update-secureboot-policy --enroll-key

om det inte finns någon MOK kommer skriptet att avslutas med ett meddelande om detta. Om nyckeln redan är inskriven kommer skriptet att avsluta, gör ingenting. Om nyckeln finns men det inte visat sig vara inskrivna, kommer användaren att uppmanas att ett lösenord för att använda efter omstart, så att nyckeln kan registreras.

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

sudo update-secureboot-policy --new-key

och registrera sedan den nyligen genererade nyckeln i shim med det tidigare nämnda kommandot för den uppgiften.

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

säkerhetsimplikationer i Maskinägarens nyckelhantering

MOK som genereras vid installationstid eller vid uppgradering är maskinspecifik och tillåts endast av kärnan eller shim att signera kärnmoduler, med hjälp av ett specifikt KeyUsage OID (1.3.6.1.4.1.2312.16.1.2) som anger begränsningarna för MOK.

de senaste shim-versionerna innehåller logik för att följa begränsningarna för modulsigneringsnycklar. Dessa nycklar kommer att tillåtas att registreras i firmware i shim förtroende databas, men kommer att ignoreras när shim eller GRUB validera bilder för att läsa in firmware. Shims verify () – funktion validerar endast bilder som är signerade med nycklar som inte innehåller” Modulsignering endast ” (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. Ubuntu-kärnorna använder global trust-databasen (som inkluderar både shim och firmware) och accepterar någon av de medföljande nycklarna som signeringsnycklar när du laddar kärnmoduler.

Med tanke på de begränsningar som åläggs 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 inskrivning av nycklar redan har hög nivååtkomst till systemet; den genererade MOK-nyckeln hålls på filsystemet som vanliga filer som ägs av root med skrivskyddade behörigheter. Detta anses vara tillräckligt för att begränsa åtkomsten till MOK för signering av skadliga användare eller skript, särskilt med tanke på att ingen MOK finns på systemet om det inte kräver drivrutiner från tredje part. Detta begränsar möjligheten att kompromissa från missbruk av en genererad MOK-nyckel till att signera en skadlig kärnmodul. Detta motsvarar kompromiss av userland-applikationerna som redan skulle vara möjligt med superanvändaråtkomst till systemet, och att säkra detta ligger utanför ramen för UEFI Secure Boot.

tidigare system kan ha haft säker Startvalidering inaktiverad i shim. Som en del av uppgraderingsprocessen kommer dessa system att migreras för att återaktivera säker Startvalidering i shim och registrera en ny MOK-nyckel när det är tillämpligt.

MOK generation och signeringsprocess

nyckelgenerering och signeringsprocess är något annorlunda beroende på om vi har att göra med en helt ny installation eller en uppgradering av systemet som tidigare kör Ubuntu; dessa två fall är tydligt markerade nedan.

i alla fall, om systemet inte startar i UEFI-läge, kommer inga speciella kärnmodulsigneringssteg eller nyckelgenerering att hända.

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

användaren installerar Ubuntu på ett nytt system

användaren går igenom installationsprogrammet. Tidigt, när man förbereder sig för att installera och endast om systemet kräver att tredjepartsmoduler fungerar, uppmanas användaren att ange ett systemlösenord som tydligt markeras som krävs efter installationen är klar, och medan systemet installeras genereras en ny MOK automatiskt utan ytterligare användarinteraktion.

Tredjepartsdrivrutiner eller kärnmoduler som krävs av systemet kommer automatiskt att byggas när paketet är installerat, och byggprocessen innehåller ett signeringssteg. Signeringssteget använder automatiskt MOK som genererats tidigare för att signera modulen, så att den omedelbart kan laddas när systemet startas om och MOK ingår i systemets förtroendedatabas.

När installationen är klar och systemet startas, vid första uppstart användaren presenteras med MokManager programmet (en del av den installerade shim loader), som en uppsättning textläge paneler som alla användare att registrera den genererade MOK. Användaren väljer ”registrera MOK”, visas ett fingeravtryck av certifikatet för att registrera sig och uppmanas att bekräfta registreringen. När den har bekräftats kommer den nya MOK att matas in i firmware och användaren kommer att bli ombedd att starta om systemet.

när systemet startas om, kommer drivrutiner från tredje part som är signerade av MOK just inskrivna att laddas vid behov.

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 postinstallationsuppgifter fortsätter att generera en ny MOK och uppmanar användaren att ange ett lösenord som tydligt nämns som krävs när uppgraderingsprocessen är klar och systemet startas om.

under uppgraderingen uppgraderas kärnpaketen och tredjepartsmodulerna. Tredjepartsmoduler byggs om för de nya kärnorna och deras efterbyggnadsprocess fortsätter att automatiskt signera dem med MOK.

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

vid omstart presenteras användaren med MokManager-programmet (en del av den installerade shim-lastaren), som en uppsättning textlägespaneler som alla användare registrerar den genererade MOK. Användaren väljer ”registrera MOK”, visas ett fingeravtryck av certifikatet för att registrera sig och uppmanas att bekräfta registreringen. Användaren presenteras också med en uppmaning att återaktivera säker startvalidering (om det visade sig vara inaktiverat); och MokManager kräver igen bekräftelse från användaren. När alla steg har bekräftats aktiveras shim-validering igen, den nya MOK kommer att anges i firmware och användaren kommer att bli ombedd att starta om systemet.

när systemet startas om, kommer drivrutiner från tredje part som är signerade av MOK just inskrivna att laddas vid behov.

i alla fall, när systemet körs med UEFI Secure Boot aktiverat och en ny version av shim; installationen av en ny dkms-modul (tredjepartsdrivrutin) fortsätter att underteckna den inbyggda modulen med MOK. Detta kommer att hända utan användarinteraktion om en giltig MOK-nyckel finns på systemet och verkar redan vara inskriven.

om det inte finns någon MOK eller den befintliga MOK inte är inskriven skapas en ny nyckel automatiskt strax före signering och Användaren uppmanas att registrera nyckeln genom att ange ett lösenord som krävs vid omstart.