Ubuntu Wiki

Co je UEFI Secure Boot?

UEFI Secure boot je ověřovací mechanismus pro zajištění důvěryhodnosti kódu spouštěného firmwarem.

Správné a bezpečné použití UEFI Secure Boot vyžaduje, aby každá binární paměť zaváděná při startu systému byla ověřena podle známých klíčů umístěných ve firmwaru, které označují důvěryhodné dodavatele a zdroje binárních souborů nebo důvěryhodné konkrétní binární soubory, které lze identifikovat pomocí kryptografického hashování.

Většina hardwaru x86 je z výroby dodávána s předinstalovanými klíči Microsoft. To znamená, že se obecně můžeme spolehnout na to, že firmware těchto systémů bude důvěřovat binárním souborům podepsaným společností Microsoft, a linuxová komunita na tento předpoklad velmi spoléhá, aby Secure Boot fungoval. Stejný postup používají například Red Hat a SUSE.

Mnoho architektur ARM a dalších architektur také podporuje UEFI Secure Boot, ale nemusí ve firmwaru přednačítat klíče. Na těchto architekturách může být nutné znovu podepsat zaváděcí obrazy certifikátem, který je ve firmwaru nahrán vlastníkem hardwaru.

Počáteční plán implementace: Plán implementace.

Podporované architektury

• amd64: Binární soubor shim podepsaný společností Microsoft a binární soubor grub podepsaný společností Canonical jsou k dispozici v hlavním archivu Ubuntu jako shim-signed nebo grub-efi-amd64-signed.

• arm64: Od verze 20.04 (‚focal‘) jsou binárka shim podepsaná společností Microsoft a binárka grub podepsaná společností Canonical poskytovány v hlavním archivu Ubuntu jako shim-signed nebo grub-efi-arm64-signed. V GRUBu se zkoumá chyba, kterou je třeba vyřešit, aby to fungovalo od konce do konce.

Testování UEFI Secure Boot

Pokud máte zájem otestovat Secure Boot na svém systému, podívejte se do návodu zde: UEFI/SecureBoot/Testování.

Jak funguje UEFI Secure Boot v Ubuntu

V Ubuntu jsou všechny předpřipravené binární soubory určené k načtení v rámci zaváděcího procesu, s výjimkou obrazu initrd, podepsány certifikátem UEFI společnosti Canonical, který je sám o sobě implicitně důvěryhodný, protože je vložen do zavaděče shim, který je sám podepsán společností Microsoft.

Na architekturách nebo systémech, kde nejsou k dispozici předinstalované podpisové certifikáty od společnosti Microsoft nebo nejsou načteny ve firmwaru, mohou uživatelé nahradit stávající podpisy v shimu nebo grubu a načíst je podle svého uvážení a ověřit je podle vlastních certifikátů importovaných ve firmwaru systému.

Při zavádění systému firmware načte binární soubor shim, jak je uvedeno v proměnných BootEntry firmwaru. Ubuntu si při instalaci nainstaluje vlastní BootEntry a může ji aktualizovat při jakékoli aktualizaci zavaděče GRUB. Vzhledem k tomu, že binární soubor shim je podepsán společností Microsoft; je ověřen a přijat firmwarem při ověřování proti certifikátům již přítomným ve firmwaru. Protože binární soubor shim obsahuje certifikát společnosti Canonical a také vlastní databázi důvěryhodnosti, mohou být další prvky zaváděcího prostředí kromě toho, že jsou podepsány jedním z přijatelných certifikátů předem nahraných ve firmwaru, podepsány klíčem UEFI společnosti Canonical.

Další věcí načtenou pomocí shimu je obraz druhého stupně. Může to být jedna ze dvou věcí: buď GRUB, pokud se systém zavádí normálně, nebo MokManager, pokud je vyžadována správa klíčů nakonfigurovaná v proměnných firmwaru (obvykle změněných při předchozím spuštění systému).

Pokud se systém zavádí normálně; načte se binární soubor GRUB (grub*.efi) a provede se pokus o jeho ověření proti všem dříve známým důvěryhodným zdrojům. Binární soubor GRUB pro Ubuntu je podepsán klíčem Canonical UEFI, takže je úspěšně ověřen a proces zavádění pokračuje.

Pokud má zavádění pokračovat úlohami správy klíčů, načte se binární soubor MokManager (mm*.efi). Tato binárka je explicitně důvěryhodná pro shim tím, že je podepsána efemérním klíčem, který existuje pouze po dobu sestavování binárky shim. To znamená, že pouze binárka MokManager sestavená s konkrétní binárkou shim bude moci být spuštěna, a omezuje se tak možnost kompromitace v důsledku použití kompromitovaných nástrojů. MokManager umožňuje libovolnému uživateli přítomnému v systémové konzoli zapisovat klíče, odebírat důvěryhodné klíče, zapisovat hashe binárních souborů a přepínat ověřování Secure Boot na úrovni shimu, ale většina úloh vyžaduje zadání předem nastaveného hesla, které potvrdí, že uživatel v konzoli je skutečně ten, kdo požadoval změny. Taková hesla přežívají pouze v rámci jednoho spuštění programu shim / MokManager a jsou vymazána, jakmile je proces dokončen nebo zrušen. Jakmile je správa klíčů dokončena, systém je restartován a nepokračuje jednoduše v zavádění systému, protože k úspěšnému dokončení zavádění systému mohou být vyžadovány změny ve správě klíčů.

Jakmile systém pokračuje v zavádění systému GRUB; proces GRUB načte veškerou požadovanou konfiguraci (obvykle načte konfiguraci z oddílu ESP (EFI System Partition), která ukazuje na jiný konfigurační soubor v kořenovém nebo zaváděcím oddílu), který jej nasměruje na obraz jádra, který se má načíst.

Aplikace EFI mají až do tohoto okamžiku plný přístup k systémovému firmwaru, včetně přístupu ke změně důvěryhodných proměnných firmwaru, jádro, které se má načíst, musí být také ověřeno proti databázi důvěryhodnosti. Oficiální jádra Ubuntu jsou podepsána klíčem Canonical UEFI, jsou úspěšně ověřena a řízení je předáno jádru. Obrazy Initrd se neověřují.

V případě neoficiálních jader nebo jader vytvořených uživateli je třeba provést další kroky, pokud si uživatelé přejí taková jádra načíst a zároveň zachovat všechny možnosti UEFI Secure Boot. Všechna jádra musí být podepsána, aby je GRUB mohl načíst, když je povoleno UEFI Secure Boot, takže uživatel bude muset provést vlastní podepsání. Alternativně mohou uživatelé zakázat ověřování v shimu při zavádění s povoleným Secure Boot na oficiálním jádře pomocí příkazu ‚sudo mokutil –disable-validation‘, zadáním hesla na výzvu a restartováním; nebo zakázat Secure Boot ve firmwaru úplně.

Do této chvíle se každé selhání při ověřování bitové kopie pro načtení setká s kritickou chybou, která zastaví proces zavádění. Systém nebude pokračovat v zavádění a může se po určité době automaticky restartovat vzhledem k tomu, že ostatní proměnné BootEntry mohou obsahovat platné a důvěryhodné zaváděcí cesty.

Po načtení validovaná jádra zakážou zaváděcí služby firmwaru, čímž dojde ke zrušení oprávnění a faktickému přepnutí do uživatelského režimu; kde je přístup k důvěryhodným proměnným omezen pouze na čtení. Vzhledem k širokým oprávněním poskytovaným modulům jádra bude třeba při načtení ověřit i jakýkoli modul, který není zabudován do jádra. Moduly vytvořené a dodávané společností Canonical s oficiálními jádry jsou podepsány klíčem Canonical UEFI a jako takové jsou důvěryhodné. Moduly vytvořené na zakázku budou vyžadovat, aby uživatel provedl nezbytné kroky k podepsání modulů před tím, než bude jejich načtení jádrem povoleno. Toho lze dosáhnout pomocí příkazu ‚kmodsign‘ .

Nepodepsané moduly jádro jednoduše odmítne. Jakýkoli pokus o jejich vložení pomocí insmod nebo modprobe selže s chybovým hlášením.

Vzhledem k tomu, že mnoho uživatelů potřebuje pro správnou funkci svých systémů nebo některých zařízení moduly třetích stran; a že tyto moduly třetích stran vyžadují lokální sestavení v systému, aby mohly být namontovány do běžícího jádra, poskytuje Ubuntu nástroje pro automatizaci a zjednodušení procesu podepisování.

Jak mohu provést neautomatizované podepisování ovladačů?

Některé projekty mohou vyžadovat použití vlastních ovladačů jádra, které nejsou nastaveny tak, aby pracovaly s DKMS. V těchto případech by lidé měli využít nástroje obsažené v balíčku shim-signed: k dispozici je skript update-secureboot-policy, který vygeneruje nový MOK (pokud již žádné moduly vytvořené pomocí DKMS nevyvolaly jeho generování).

Pomocí následujícího příkazu můžete zapsat existující klíč do shimu:

sudo update-secureboot-policy --enroll-key

Pokud žádný MOK neexistuje, skript se ukončí s příslušnou zprávou. Pokud je klíč již zapsán, skript se ukončí a nic neudělá. Pokud klíč existuje, ale nezobrazí se, že je zapsán, bude uživatel vyzván k zadání hesla, které má po restartu použít, aby mohl být klíč zapsán.

Nový MOK lze vygenerovat pomocí následujícího příkazu:

sudo update-secureboot-policy --new-key

A poté nově vygenerovaný klíč zapsat do programu shim pomocí dříve uvedeného příkazu pro tuto úlohu.

Moduly jádra pak lze podepsat příkazem kmodsign (viz UEFI/SecureBoot/Podepisování) v rámci procesu jejich sestavování.

Důsledky zabezpečení při správě klíčů vlastníka stroje

MOK vygenerovaný při instalaci nebo při aktualizaci je specifický pro daný stroj a k podepisování modulů jádra je povolen pouze jádrem nebo shimem, a to pomocí specifického OID KeyUsage (1.3.6.1.4.1.2312.16.1.2) označujícího omezení MOK.

Nejnovější verze shimů obsahují logiku pro sledování omezení klíčů určených pouze pro podepisování modulů. Tyto klíče bude povoleno zapsat do firmwaru v databázi důvěryhodnosti shimu, ale budou ignorovány při ověřování obrazů shimem nebo GRUBem pro načtení do firmwaru. Funkce shim verify() bude úspěšně ověřovat pouze obrazy podepsané klíči, které neobsahují OID KeyUsage „Module-signing only“ (1.3.6.1.4.1.2312.16.1.2). Jádra Ubuntu používají globální databázi důvěryhodnosti (která zahrnuje jak shim, tak firmware) a při načítání modulů jádra přijmou jako podpisový klíč kterýkoli z obsažených klíčů.

Vzhledem k omezením kladeným na automaticky generovaný MOK a skutečnosti, že uživatelé s přístupem superuživatele k systému a přístupem k systémové konzoli pro zadání hesla požadovaného při zápisu klíčů již mají přístup k systému na vysoké úrovni; vygenerovaný klíč MOK je uchováván na souborovém systému jako běžné soubory vlastněné rootem s právy pouze pro čtení. To je považováno za dostatečné k omezení přístupu k MOK pro podepisování ze strany škodlivých uživatelů nebo skriptů, zejména vzhledem k tomu, že v systému neexistuje žádný MOK, pokud nevyžaduje ovladače třetích stran. Tím se omezuje možnost kompromitace v důsledku zneužití vygenerovaného klíče MOK k podepsání škodlivého modulu jádra. To je ekvivalentní kompromitaci aplikací v uživatelském prostoru, která by byla možná již s přístupem superuživatele k systému, a její zabezpečení nespadá do oblasti působnosti UEFI Secure Boot.

Předchozí systémy mohly mít v shimu zakázáno ověřování Secure Boot. V rámci procesu aktualizace budou tyto systémy převedeny na opětovné povolení ověřování Secure Boot v shim a případné zapsání nového klíče MOK.

Proces generování a podepisování MOK

Proces generování a podepisování klíčů se mírně liší podle toho, zda se jedná o zcela novou instalaci, nebo o upgrade systému, na kterém dříve běželo Ubuntu; tyto dva případy jsou níže jasně označeny.

Ve všech případech, kdy systém není zaváděn v režimu UEFI, neprobíhají žádné zvláštní kroky podepisování jaderných modulů ani generování klíčů.

Je-li Secure Boot zakázán, k vygenerování a zápisu MOK přesto dojde, protože uživatel může Secure Boot později povolit. V takovém případě by měl systém pracovat správně.

Uživatel instaluje Ubuntu na nový systém

Uživatel prochází instalačním programem. Na začátku, při přípravě instalace a pouze v případě, že systém vyžaduje pro svou činnost moduly třetích stran, je uživatel vyzván k zadání systémového hesla, které je jasně označeno jako vyžadované po dokončení instalace, a během instalace systému je automaticky generován nový MOK bez další interakce uživatele.

Ovladače nebo moduly jádra třetích stran, které systém vyžaduje, se při instalaci balíčku automaticky sestaví a proces sestavení zahrnuje krok podepisování. Krok podepisování automaticky použije dříve vygenerovaný MOK k podepsání modulu, takže jej lze okamžitě načíst po restartu systému a MOK je zahrnut do databáze důvěryhodnosti systému.

Po dokončení instalace a restartu systému se uživateli při prvním spuštění zobrazí program MokManager (součást nainstalovaného zavaděče shimů) jako sada panelů v textovém režimu, které všechny uživateli umožní zapsat vygenerovaný MOK. Uživatel zvolí „Enroll MOK“ (Zapsat MOK), zobrazí se mu otisk certifikátu, který má zapsat, a je vyzván k potvrzení zápisu. Po potvrzení se nový MOK zapíše do firmwaru a uživatel bude vyzván k restartování systému.

Po restartu systému se podle potřeby načtou ovladače třetích stran podepsané právě zapsaným MOK.

Uživatel upgraduje systém Ubuntu s podporou UEFI na nové vydání, kde systém vyžaduje ovladače třetích stran

Při upgradu se aktualizují balíčky podepsané shim a shim. Poinstalační úlohy balíčku shim-signed pokračují ve vytváření nového MOK a vyzvou uživatele k zadání hesla, které je jasně zmíněno jako vyžadované po dokončení procesu upgradu a restartu systému.

Během upgradu jsou aktualizovány balíčky jádra a moduly třetích stran. Moduly třetích stran jsou přestavěny pro nová jádra a jejich proces po sestavení pokračuje automatickým podepsáním pomocí MOK.

Po upgradu se uživateli doporučuje restartovat systém.

Po restartu se uživateli zobrazí program MokManager (součást nainstalovaného zavaděče shim) jako sada panelů v textovém režimu, které všechny uživatele zaregistrují do vygenerovaného MOK. Uživatel zvolí „Enroll MOK“ (Zapsat MOK), zobrazí se mu otisk certifikátu, který má zapsat, a je vyzván k potvrzení zápisu. Uživateli se rovněž zobrazí výzva k opětovnému zapnutí ověřování Secure Boot (v případě, že bylo zjištěno, že je zakázáno); a MokManager opět vyžaduje potvrzení od uživatele. Po potvrzení všech kroků je opětovně povolena validace shimu, nový MOK bude zadán do firmwaru a uživatel bude vyzván k restartování systému.

Po restartu systému se podle potřeby načtou ovladače třetích stran podepsané právě zapsaným MOK.

Ve všech případech, jakmile je systém spuštěn se zapnutým systémem UEFI Secure Boot a poslední verzí shimu; instalace jakéhokoli nového modulu DKMS (ovladače třetí strany) bude pokračovat podepsáním sestaveného modulu pomocí MOK. K tomu dojde bez zásahu uživatele, pokud v systému existuje platný klíč MOK a zdá se, že je již zapsán.

Pokud žádný MOK neexistuje nebo existující MOK není zapsán, vytvoří se nový klíč automaticky těsně před podpisem a uživatel bude vyzván k zápisu klíče zadáním hesla, které bude vyžadováno při restartu.