Mi az UEFI Secure Boot?
Az UEFI Secure Boot egy olyan ellenőrzési mechanizmus, amely biztosítja, hogy a firmware által indított kód megbízható legyen.
Az UEFI Secure Boot megfelelő, biztonságos használata megköveteli, hogy a rendszerindításkor betöltött minden egyes bináris programot a firmware-ben található ismert kulcsokkal ellenőrizzék, amelyek a bináris programok megbízható gyártóit és forrásait vagy a kriptográfiai hasheléssel azonosítható, megbízható specifikus bináris programokat jelölik.
A legtöbb x86-os hardver gyárilag előre feltöltött Microsoft kulcsokkal érkezik. Ez azt jelenti, hogy általában bízhatunk abban, hogy a firmware ezeken a rendszereken megbízik a Microsoft által aláírt binárisokban, és a Linux közösség nagymértékben támaszkodik erre a feltételezésre a Secure Boot működéséhez. Ezt az eljárást használja például a Red Hat és a SUSE is.
Sok ARM és más architektúrák is támogatják az UEFI Secure Bootot, de előfordulhat, hogy nem töltik előre a kulcsokat a firmware-be. Ezeken az architektúrákon szükség lehet a boot-képek újbóli aláírására egy olyan tanúsítvánnyal, amelyet a hardver tulajdonosa tölt be a firmware-be.
Eredeti megvalósítási terv: Implementációs terv.
Támogatott architektúrák
-
amd64: A Microsoft által aláírt shim bináris és a Canonical által aláírt grub bináris megtalálható az Ubuntu főarchívumában shim-signed vagy grub-efi-amd64-signed néven.
-
arm64: A 20.04-től (“focal”) a Microsoft által aláírt shim bináris és a Canonical által aláírt grub bináris az Ubuntu főarchívumában shim-signed vagy grub-efi-arm64-signed néven található. Egy GRUB hibát vizsgálnak, amelyet meg kell oldani, mielőtt ez végig működne.
Az UEFI Secure Boot tesztelése
Ha szeretnéd tesztelni a Secure Bootot a rendszereden, nézd meg a how-to-t itt: UEFI/SecureBoot/Tesztelés.
Hogyan működik az UEFI Secure Boot az Ubuntun
Az Ubuntun az initrd kép kivételével minden előre elkészített, a rendszerindítási folyamat részeként betöltendő bináris állományt a Canonical UEFI tanúsítványa ír alá, amely maga is implicit módon megbízható, mivel be van ágyazva a shim betöltőbe, amelyet maga a Microsoft írt alá.
Azokon az architektúrákon vagy rendszereken, ahol a Microsoft előre betöltött aláíró tanúsítványai nem állnak rendelkezésre vagy nincsenek betöltve a firmware-be, a felhasználók lecserélhetik a shim vagy a grub meglévő aláírásait, és tetszés szerint tölthetik be azokat, ellenőrizve a rendszer firmware-jébe importált saját tanúsítványaikkal.
A rendszer indításakor a firmware betölti a firmware BootEntry változókban megadott shim binárisát. Az Ubuntu telepíti a saját BootEntry-t a telepítéskor, és bármikor frissítheti azt, amikor a GRUB bootloader frissül. Mivel a shim bináris állományt a Microsoft írta alá; a firmware érvényesíti és elfogadja, amikor a firmware-ben már meglévő tanúsítványok ellenében ellenőrzi. Mivel a shim bináris beágyazza a Canonical tanúsítványát, valamint saját bizalmi adatbázisát, a rendszerindítási környezet további elemei a firmware-be előre betöltött, elfogadható tanúsítványok egyikével való aláírás mellett a Canonical UEFI-kulcsával is aláírhatók.
A shim által betöltött következő dolog a második lépcsős image. Ez két dolog közül az egyik lehet: vagy a GRUB, ha a rendszer normálisan bootol; vagy a MokManager, ha a firmware változói által konfigurált (általában a rendszer korábbi futtatásakor módosított) kulcskezelésre van szükség.
Ha normálisan bootol; a GRUB bináris (grub*.efi) betöltődik, és megkísérli annak hitelesítését az összes korábban ismert megbízható forrással szemben. Az Ubuntu GRUB-binárisát a Canonical UEFI-kulcsa írta alá, így sikeresen érvényesítettük, és a bootolási folyamat folytatódik.
Ha a bootolás a kulcskezelési feladatok folytatásához szükséges, a MokManager bináris (mm*.efi) betöltődik. Ezt a bináris állományt a shim kifejezetten megbízhatóvá teszi azáltal, hogy egy efemer kulccsal van aláírva, amely csak a shim bináris felépítésének ideje alatt létezik. Ez azt jelenti, hogy csak az adott shim-binárissal épített MokManager bináris futhat, és korlátozza a kompromittált eszközök használatából eredő veszélyeztetés lehetőségét. A MokManager lehetővé teszi a rendszerkonzolon jelen lévő bármely felhasználó számára a kulcsok beírását, a megbízható kulcsok eltávolítását, a bináris hashek beírását és a Secure Boot érvényesítés bekapcsolását a shim szintjén, de a legtöbb feladathoz egy korábban beállított jelszó megadása szükséges annak megerősítésére, hogy a konzolon lévő felhasználó valóban az a személy, aki a változtatásokat kérte. Az ilyen jelszavak csak a shim / MokManager egyetlen futtatása során maradnak fenn; és törlődnek, amint a folyamat befejeződik vagy megszakad. A kulcskezelés befejezése után a rendszer újraindul, és nem folytatódik egyszerűen a rendszerindítással, mivel a kulcskezelés módosításai szükségesek lehetnek a rendszerindítás sikeres befejezéséhez.
A rendszer folytatja a GRUB rendszerindítást; a GRUB folyamat betölti a szükséges konfigurációt (általában az ESP (EFI System Partition) konfiguráció betöltése, amely egy másik konfigurációs fájlra mutat a root vagy boot partíción), amely rámutat a betöltendő kernelképre.
Az EFI-alkalmazásoknak eddig a pontig teljes hozzáférésük van a rendszer firmware-éhez, beleértve a megbízható firmware-változók megváltoztatásához való hozzáférést, a betöltendő kernelt a bizalmi adatbázis alapján is validálni kell. A hivatalos Ubuntu kernelek a Canonical UEFI-kulccsal aláírva sikeresen validálódnak, és a vezérlés átadásra kerül a kernelnek. Az initrd képek nem kerülnek hitelesítésre.
A nem hivatalos rendszermagok vagy a felhasználók által készített rendszermagok esetében további lépéseket kell tenni, ha a felhasználók az ilyen rendszermagokat az UEFI Secure Boot teljes körű képességeinek megtartása mellett szeretnék betölteni. Minden rendszermagot alá kell írni ahhoz, hogy a GRUB betölthesse, ha az UEFI Secure Boot engedélyezve van, ezért a felhasználónak saját aláírásával kell eljárnia. Alternatív megoldásként a felhasználók letilthatják az érvényesítést a shimben, miközben egy hivatalos rendszermag Secure Boot engedélyezve van, a “sudo mokutil –disable-validation” paranccsal, a jelszó megadásával, amikor a rendszer kéri, és újraindítással; vagy a Secure Boot teljes letiltásával a firmware-ben.
Edig a pontig a betöltendő lemezkép érvényesítésének bármilyen sikertelensége kritikus hibát eredményez, amely leállítja a betöltési folyamatot. A rendszer nem folytatja a rendszerindítást, és egy idő után automatikusan újraindulhat, tekintettel arra, hogy más BootEntry változók tartalmazhatnak érvényes és megbízható boot-útvonalakat.
A betöltés után az érvényesített rendszermagok letiltják a firmware boot-szolgáltatásait, így a jogosultságok megszűnnek, és ténylegesen felhasználói módba váltanak; ahol a megbízható változókhoz való hozzáférés csak olvasásra korlátozódik. Tekintettel a kernelmodulok számára biztosított széleskörű jogosultságokra, a nem a kernelbe épített modulokat betöltéskor szintén hitelesíteni kell. A Canonical által épített és a hivatalos rendszermagokkal együtt szállított modulok a Canonical UEFI-kulccsal vannak aláírva, és mint ilyenek, megbízhatóak. Az egyedi modulok esetében a felhasználónak meg kell tennie a szükséges lépéseket a modulok aláírásához, mielőtt a kernel engedélyezné a betöltésüket. Ezt a ‘kmodsign’ parancs használatával lehet elérni.
A nem aláírt modulokat a rendszermag egyszerűen elutasítja. Bármilyen inmod vagy modprobe segítségével történő behelyezési kísérlet hibaüzenettel fog sikertelenül végződni.
Mivel sok felhasználónak szüksége van harmadik féltől származó modulokra ahhoz, hogy a rendszere megfelelően működjön, vagy hogy bizonyos eszközök működjenek; és mivel ezek a harmadik féltől származó modulok a rendszerben helyben történő építést igényelnek ahhoz, hogy a futó kernelhez illeszkedjenek, az Ubuntu eszközöket biztosít az aláírási folyamat automatizálására és egyszerűsítésére.
Hogyan végezhetem el az illesztőprogramok nem automatizált aláírását?
Egyes projektekhez szükség lehet olyan egyéni kernel-illesztőprogramok használatára, amelyek nincsenek úgy beállítva, hogy működjenek a DKMS-szel. Ezekben az esetekben az embereknek a shim-signed csomagban található eszközöket kell használniuk: az update-secureboot-policy szkript elérhető egy új MOK generálásához (ha a DKMS által épített modulok még nem váltották ki a generálást).
A következő paranccsal egy meglévő kulcsot lehet beírni a shimbe:
sudo update-secureboot-policy --enroll-key
Ha nem létezik MOK, a szkript egy erre vonatkozó üzenettel lép ki. Ha a kulcs már be van írva, a szkript kilép, és nem csinál semmit. Ha a kulcs létezik, de nem látszik, hogy be van írva, a parancs az újraindítás után jelszót kér a felhasználótól, hogy a kulcsot be lehessen írni.
Új MOK-ot a következő paranccsal lehet létrehozni:
sudo update-secureboot-policy --new-key
Az újonnan generált kulcsot pedig a korábban említett, erre a feladatra vonatkozó paranccsal lehet beiratkoztatni a shimbe.
A kernelmodulokat ezután a kmodsign paranccsal (lásd UEFI/SecureBoot/Signing) lehet aláírni az építési folyamatuk részeként.
Biztonsági vonatkozások a gépi kulcskezelésben
A telepítéskor vagy frissítéskor generált MOK gépspecifikus, és csak a kernel vagy a shim engedélyezi a kernelmodulok aláírását, egy speciális KeyUsage OID (1.3.6.1.4.1.2312.16.1.1.2) használatával, amely a MOK korlátozását jelzi.
A legújabb shim verziók tartalmaznak olyan logikát, amely követi a csak modulok aláírására szolgáló kulcsok korlátait. Ezeket a kulcsokat a shim bizalmi adatbázisában engedélyezik a firmware-be való bejegyzést, de figyelmen kívül hagyják, amikor a shim vagy a GRUB validálja a firmware-be betöltendő képeket. A shim verify() függvénye csak olyan kulcsokkal aláírt képeket fog sikeresen érvényesíteni, amelyek nem tartalmazzák a “Module-signing only” (1.3.6.1.4.1.2312.16.1.1.2) KeyUsage OID azonosítót. Az Ubuntu kernelek a globális bizalmi adatbázist használják (amely magában foglalja a shim és a firmware adatbázisát is), és a kernelmodulok betöltésekor a benne lévő kulcsok bármelyikét elfogadja aláíró kulcsként.
Az automatikusan generált MOK-ra vonatkozó korlátozások és az a tény, hogy a rendszerhez superuser hozzáféréssel és a kulcsok beírásához szükséges jelszó megadásához szükséges rendszerkonzolhoz való hozzáféréssel rendelkező felhasználók már magas szintű hozzáféréssel rendelkeznek a rendszerhez; a generált MOK kulcsot a fájlrendszeren tartják a root tulajdonában lévő, csak olvasási jogosultságokkal rendelkező normál fájlokként. Ez elegendőnek tekinthető ahhoz, hogy korlátozza a rosszindulatú felhasználók vagy szkriptek hozzáférését a MOK aláírásához, különös tekintettel arra, hogy a rendszerben nem létezik MOK, kivéve, ha harmadik féltől származó illesztőprogramokra van szükség. Ez korlátozza a veszélyeztetés lehetőségét a generált MOK-kulccsal való visszaélésből adódóan egy rosszindulatú kernelmodul aláírására. Ez egyenértékű a felhasználói alkalmazások kompromittálásával, ami már a rendszerhez való szuperfelhasználói hozzáféréssel is lehetséges lenne, és ennek biztosítása nem tartozik az UEFI Secure Boot hatáskörébe.
A korábbi rendszereknél előfordulhat, hogy a Secure Boot érvényesítés le volt tiltva a shimben. A frissítési folyamat részeként ezeket a rendszereket átállítják a Secure Boot érvényesítés újbóli engedélyezésére a shimben, és adott esetben új MOK-kulcs beírására.
MOK generálási és aláírási folyamat
A kulcsgenerálás és aláírás folyamata némileg eltér attól függően, hogy egy teljesen új telepítéssel vagy egy korábban Ubuntut futtató rendszer frissítésével van-e dolgunk; ez a két eset az alábbiakban egyértelműen jelölve van.
Minden esetben, ha a rendszer nem UEFI módban bootol, nem történnek külön kernelmodul aláírási lépések vagy kulcsgenerálás.
Ha a Secure Boot ki van kapcsolva, a MOK generálás és a beiratkozás továbbra is megtörténik, mivel a felhasználó később is engedélyezheti a Secure Bootot. Ebben az esetben a rendszerüknek megfelelően kell működnie.
A felhasználó új rendszerre telepíti az Ubuntut
A felhasználó végigmegy a telepítőprogramon. Korán, a telepítés előkészítésekor, és csak akkor, ha a rendszer működéséhez harmadik féltől származó modulok szükségesek, a rendszer jelszót kér a felhasználótól, amely egyértelműen jelzi, hogy a telepítés befejezése után szükség van rá, és a rendszer telepítése közben automatikusan, további felhasználói beavatkozás nélkül új MOK generálódik.
A rendszer által igényelt, harmadik féltől származó illesztőprogramok vagy kernelmodulok a csomag telepítésekor automatikusan elkészülnek, és az építési folyamat tartalmaz egy aláírási lépést. Az aláírási lépés automatikusan a korábban generált MOK-ot használja a modul aláírására, így az azonnal betölthető lesz, amint a rendszer újraindul, és a MOK bekerül a rendszer bizalmi adatbázisába.
A telepítés befejezése és a rendszer újraindítása után az első indításkor a felhasználónak megjelenik a MokManager program (a telepített shim-töltő része), mint egy sor szöveges módú panel, amely minden felhasználónak lehetővé teszi a generált MOK beírását. A felhasználó kiválasztja a “MOK beiratkozása” lehetőséget, megjelenik a beiratkozandó tanúsítvány ujjlenyomata, és felszólítást kap a beiratkozás megerősítésére. A megerősítést követően az új MOK bekerül a firmware-be, és a felhasználónak újra kell indítania a rendszert.
A rendszer újraindításakor a rendszer szükség szerint betölti az éppen beírt MOK által aláírt harmadik féltől származó illesztőprogramokat.
A felhasználó egy UEFI-kompatibilis Ubuntu rendszert frissít egy új kiadásra, ahol a rendszernek szüksége van harmadik féltől származó illesztőprogramokra
A frissítéskor a shim és a shim által aláírt csomagok frissítésre kerülnek. A shim aláírt csomag telepítés utáni feladatai folytatják egy új MOK létrehozását, és jelszót kérnek a felhasználótól, amelyről egyértelműen megemlítik, hogy a frissítési folyamat befejezése és a rendszer újraindítása után szükséges.
A frissítés során a kernelcsomagok és a harmadik féltől származó modulok frissítésre kerülnek. A harmadik féltől származó modulok újraépülnek az új kernelekhez, és a készítés utáni folyamatuk automatikusan folytatja a MOK-kal való aláírást.
A frissítés után a felhasználónak ajánlott újraindítani a rendszerét.
Újraindításkor a felhasználónak megjelenik a MokManager program (a telepített shim-töltő része), mint egy sor szöveges módú panel, amely minden felhasználó számára lehetővé teszi a generált MOK beírását. A felhasználó kiválasztja a “MOK beiratkozása” lehetőséget, megjelenik a beiratkozandó tanúsítvány ujjlenyomata, és felszólítást kap a beiratkozás megerősítésére. A felhasználónak megjelenik egy felszólítás is, hogy újra engedélyezze a Secure Boot érvényesítést (abban az esetben, ha azt kikapcsoltnak találta); és a MokManager ismét megerősítést kér a felhasználótól. Ha minden lépés megerősítésre került, a shim-érvényesítés újra engedélyezésre kerül, az új MOK bekerül a firmware-be, és a felhasználó felkérést kap a rendszer újraindítására.
A rendszer újraindításakor az éppen beírt MOK által aláírt harmadik féltől származó illesztőprogramok szükség szerint betöltődnek.
Minden esetben, ha a rendszer UEFI Secure Boot funkcióval és a shim legújabb verziójával működik; bármely új DKMS modul (harmadik féltől származó illesztőprogram) telepítése a beépített modul MOK-kal történő aláírásával folytatódik. Ez felhasználói beavatkozás nélkül történik, ha a rendszerben van érvényes MOK-kulcs, és úgy tűnik, hogy már be van jegyezve.
Ha nincs MOK, vagy a meglévő MOK nincs bejegyezve, akkor közvetlenül az aláírás előtt automatikusan létrehoz egy új kulcsot, és a felhasználót jelszó megadásával felszólítja a kulcs bejegyzésére, amelyet az újraindításkor kérni fog.