mi az UEFI Secure Boot?

az UEFI Secure boot egy ellenőrző mechanizmus annak biztosítására, hogy a firmware által elindí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 bináris fájlok validálva legyenek a firmware-ben található ismert kulcsokkal szemben, amelyek a binárisok megbízható szállítóit és forrásait jelölik, vagy megbízható specifikus binárisokat, amelyek kriptográfiai kivonatolással azonosíthatók.

a legtöbb x86 hardver a Microsoft kulcsokkal előre betöltött gyárból származik. Ez azt jelenti, hogy általában a Microsoft által aláírt binárisok megbízhatóságára támaszkodhatunk ezeken a rendszereken, és a Linux közösség erősen támaszkodik erre a feltételezésre a biztonságos rendszerindításhoz. Ezt a folyamatot használja például a Red Hat és a SUSE is.

számos ARM és más architektúra is támogatja az UEFI Secure Boot-ot, de előfordulhat, hogy a firmware-ben nincsenek előre betöltő kulcsok. Ezeken az architektúrákon szükség lehet a rendszerindító képek újbóli aláírására egy tanúsítvánnyal, amelyet a hardver tulajdonosa tölt be a firmware-be.

kezdeti megvalósítási terv: megvalósítási terv.

támogatott architektúrák

• amd64: a Microsoft által aláírt shim bináris és a Canonical által aláírt grub bináris az Ubuntu fő archívumában shim-aláírt vagy grub-efi-amd64-aláírt.

• arm64: 20.04-től (‘focal’) a Microsoft által aláírt shim binary és a Canonical által aláírt grub binary az Ubuntu fő archívumában shim-signed vagy grub-efi-arm64-signed néven szerepel. Van egy grub bug vizsgálat alatt, amelyet meg kell oldani, mielőtt ez a munka véget ér.

az UEFI Secure Boot tesztelése

Ha érdekel a Biztonságos rendszerindítás tesztelése a rendszeren, olvassa el a útmutatót itt: UEFI/SecureBoot/Testing.

hogyan működik az UEFI Secure Boot az Ubuntun

az Ubuntun az összes előre elkészített bináris fájlt, amelyet a rendszerindítási folyamat részeként kell betölteni, az initrd kép kivételével, a Canonical UEFI tanúsítványa írja alá, amely magában hallgatólagosan megbízik azáltal, hogy beágyazódik a shim betöltőbe, amelyet maga a Microsoft írt alá.

olyan architektúrákon vagy rendszereken, ahol a Microsoft előre betöltött aláírási tanúsítványai nem érhetők el, vagy nem tölthetők be firmware-be, a felhasználók kicserélhetik a meglévő aláírásokat a shim-en vagy a grub-on, és tetszés szerint betölthetik őket, ellenőrizve a rendszer firmware-jében importált saját tanúsítványaikat.

a rendszer indításakor a firmware betölti a shim binárist a firmware BootEntry változókban leírtak szerint. Az Ubuntu telepítéskor telepíti a saját BootEntry-jét, és bármikor frissítheti, amikor a GRUB bootloader frissül. Mivel a shim binárist a Microsoft írja alá; ezt a firmware érvényesíti és elfogadja, amikor a firmware-ben már meglévő tanúsítványok alapján ellenőrzi. Mivel a shim bináris beágyazza a kanonikus tanúsítványt, valamint a saját bizalmi adatbázisát, a rendszerindító környezet további elemeit a firmware-be előre betöltött elfogadható tanúsítványok egyikén kívül a Canonical UEFI kulcsa is aláírhatja.

a shim által betöltött következő dolog a második fokozatú kép. Ez két dolog egyike lehet: vagy GRUB, ha a rendszer normálisan indul; vagy MokManager, ha kulcskezelésre van szükség, a firmware változók által konfigurálva (általában a rendszer korábbi futtatásakor változott).

Normál indítás esetén; a GRUB bináris (grub*.EFI) betöltődik, és az érvényesítését megkísérli az összes korábban ismert megbízható forrás ellen. Az Ubuntu grub binárisát a Canonical UEFI kulcs írja alá, így sikeresen érvényesíti, és a rendszerindítási folyamat folytatódik.

Ha a rendszerindítás a kulcskezelési feladatok elvégzéséhez szükséges, akkor a mokmanager binary (mm*.EFI) betöltve. Ezt a binárist kifejezetten a shim bízza meg azzal, hogy egy mulandó kulcs írja alá, amely csak a shim bináris felépítése közben létezik. Ez azt jelenti, hogy csak az adott shim binárissal épített mokmanager bináris futtatható, és korlátozza a kompromisszum lehetőségét a kompromittált eszközök használatából. A MokManager lehetővé teszi a rendszerkonzolon jelen lévő bármely felhasználó számára a kulcsok regisztrálását, a megbízható kulcsok eltávolítását, a bináris kivonatok regisztrálását és a Biztonságos rendszerindítás érvényesítését az alátét szintjén, de a legtöbb feladathoz korábban beállított jelszó megadása szükséges annak megerősítéséhez, hogy a konzol felhasználója valóban az a személy, aki változtatásokat kért. Az ilyen jelszavak csak a shim / MokManager egyetlen futtatásakor maradnak fenn; és törlődnek, amint a folyamat befejeződik vagy törlődik. Miután a kulcskezelés befejeződött, a rendszer újraindul, és nem egyszerűen folytatja a rendszerindítást, mivel a kulcskezelés módosítására lehet szükség a rendszerindítás sikeres befejezéséhez.

miután a rendszer folytatja a GRUB indítását; a GRUB folyamat betölti a szükséges konfigurációt (általában a konfiguráció betöltése az ESP-ből (EFI System Partition), rámutatva a gyökér vagy a rendszerindító partíció másik konfigurációs fájljára), amely a betöltendő kernelképre mutat.

EFI Alkalmazások eddig a pontig teljes hozzáféréssel a rendszer firmware-jéhez, beleértve a megbízható firmware-változók megváltoztatását is, a betöltendő kernelt is érvényesíteni kell a bizalmi adatbázissal szemben. A hivatalos Ubuntu kerneleket a kanonikus UEFI kulcs írja alá, sikeresen érvényesítik őket, és az irányítást átadják a kernelnek. Initrd képek nem érvényesített.

a nem hivatalos kernelek vagy a felhasználók által épített kernelek esetében további lépéseket kell tenni, ha a felhasználók ilyen kerneleket akarnak betölteni, miközben megőrzik az UEFI Secure Boot teljes képességeit. Minden kernelt alá kell írni ahhoz, hogy a GRUB betölthesse, amikor az UEFI Secure Boot engedélyezve van, így a felhasználónak saját aláírását kell folytatnia. Alternatív megoldásként a felhasználók letilthatják az érvényesítést a shim – ben, miközben a hivatalos kernelen engedélyezett biztonságos indítással indítják a ‘sudo mokutil –disable-validation’ használatával, jelszó megadásával, amikor a rendszer kéri, és újraindítással; vagy teljesen letilthatja a biztonságos indítást a firmware-ben.

eddig a pontig a betöltendő kép érvényesítésének elmulasztása kritikus hibával jár, amely leállítja a rendszerindítási folyamatot. A rendszer nem folytatja a rendszerindítást, és egy bizonyos idő elteltével automatikusan újraindulhat, mivel más BootEntry változók érvényes és megbízható rendszerindítási útvonalakat tartalmazhatnak.

a betöltés után az ellenőrzött kernelek letiltják a firmware rendszerindító szolgáltatásait, így megszüntetik a jogosultságokat, és hatékonyan átváltanak felhasználói módra; ahol a megbízható változókhoz való hozzáférés csak olvasható. Tekintettel a kernelmodulok számára biztosított széles körű engedélyekre, minden olyan modult, amely nincs beépítve a kernelbe, szintén érvényesíteni kell a betöltéskor. A Canonical által a hivatalos kernelekkel épített és szállított modulokat a Canonical UEFI kulcs írja alá, és mint ilyen, megbízhatóak. Az egyedi modulok megkövetelik, hogy a felhasználó megtegye a szükséges lépéseket a modulok aláírásához, mielőtt a rendszermag engedélyezi a betöltésüket. Ezt a ‘kmodsign’ paranccsal lehet elérni .

az aláíratlan modulokat egyszerűen elutasítja a kernel. Az insmod vagy a modprobe használatával történő beillesztési kísérlet hibaüzenettel sikertelen lesz.

tekintettel arra, hogy sok felhasználónak harmadik féltől származó modulokra van szüksége a rendszerük megfelelő működéséhez vagy egyes eszközök működéséhez; és hogy ezek a harmadik féltől származó modulok helyileg építik a rendszert, hogy a futó kernelhez illeszkedjenek, az Ubuntu eszközöket biztosít az aláírási folyamat automatizálásához és egyszerűsítéséhez.

hogyan végezhetem el a járművezetők nem automatikus aláírását?

egyes projektekhez szükség lehet egyéni kernel-illesztőprogramok használatára, amelyek nincsenek úgy beállítva, hogy működjenek a DKMS-sel. Ezekben az esetekben az embereknek használniuk kell a shim-aláírt csomagban található eszközöket: az update-secureboot-policy szkript elérhető egy új MOK létrehozásához (ha egyetlen DKMS-ben épített modul sem váltotta ki a generálást).

használja a következő parancsot egy meglévő kulcs beírásához a shim-be:

sudo update-secureboot-policy --enroll-key

Ha nincs MOK, akkor a szkript egy erre vonatkozó üzenettel lép ki. Ha a kulcs már be van jegyezve, a szkript kilép, nem csinál semmit. Ha a kulcs létezik, de nem jelenik meg, hogy beiratkozott, a felhasználó kéri a jelszót használni újraindítás után, hogy a kulcs lehet beiratkozott.

új MOK-ot lehet létrehozni a következő paranccsal:

sudo update-secureboot-policy --new-key

majd az újonnan létrehozott kulcsot beírhatja a shim-be a feladathoz korábban említett paranccsal.

a kernelmodulok ezután aláírhatók a kmodsign paranccsal (lásd UEFI/SecureBoot/Signing) a build folyamat részeként.

biztonsági vonatkozások a Géptulajdonos Kulcskezelésében

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 adott KeyUsage OID (1.3.6.1.4.1.2312.16.1.2) használatával, amely a MOK korlátait jelöli.

a legújabb shim verziók tartalmazzák a logikát, hogy kövessék a csak modul-aláíró kulcsok korlátait. Ezeket a kulcsokat be lehet jegyezni a firmware-be a shim bizalmi adatbázisában, de figyelmen kívül hagyják, amikor a shim vagy a GRUB érvényesíti a képeket a firmware-be való betöltéshez. A Shim verify () függvénye csak olyan kulcsok által aláírt képeket validál sikeresen, amelyek nem tartalmazzák a “Module-signing only” (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID-t. Az Ubuntu kernelek a global trust adatbázist használják (amely magában foglalja mind a shim-et, mind a firmware-t), és a kernel modulok betöltésekor elfogadják a mellékelt kulcsok bármelyikét aláíró kulcsként.

tekintettel az automatikusan generált MOK-ra vonatkozó korlátozásokra, valamint arra a tényre, hogy a rendszerhez superuser hozzáféréssel rendelkező felhasználók és a rendszerkonzolhoz való hozzáférés a kulcsok regisztrálásához szükséges jelszó megadásához már magas szintű hozzáféréssel rendelkeznek a rendszerhez; a generált MOK kulcs a fájlrendszeren marad, mint a root szokásos fájljai, csak olvasható engedélyekkel. Ez elegendőnek tekinthető ahhoz, hogy korlátozza a MOK-hoz való hozzáférést a rosszindulatú felhasználók vagy szkriptek aláírásához, különös tekintettel arra, hogy a rendszeren nincs mok, kivéve, ha harmadik féltől származó illesztőprogramokra van szükség. Ez korlátozza a kompromisszum lehetőségét a generált mok-kulcs visszaélésétől a rosszindulatú kernelmodul aláírásáig. Ez egyenértékű a userland alkalmazások kompromisszumával, amely már lehetséges lenne a rendszerhez való superuser hozzáféréssel, és ennek biztosítása kívül esik az UEFI Secure Boot hatókörén.

előfordulhat, hogy a korábbi rendszereknél a Biztonságos rendszerindítás ellenőrzése le volt tiltva a shim-ben. A frissítési folyamat részeként ezeket a rendszereket áttelepítik a Biztonságos rendszerindítás érvényesítésének újbóli engedélyezésére a shim-ben, és adott esetben új MOK-kulcs regisztrálására.

MOK generálás és aláírási folyamat

a kulcs generálása és aláírási folyamata kissé eltér attól függően, hogy egy vadonatúj telepítésről vagy egy korábban Ubuntut futtató rendszer frissítéséről van-e szó; ez a két eset egyértelműen meg van jelölve alább.

minden esetben, ha a rendszer nem indul UEFI módban, nem történik speciális kernelmodul-aláírási lépés vagy kulcsgenerálás.

Ha a Biztonságos rendszerindítás le van tiltva, a MOK generálása és regisztrálása továbbra is megtörténik, mivel a felhasználó később engedélyezheti a biztonságos rendszerindítást. A rendszernek megfelelően kell működnie, ha ez a helyzet.

A felhasználó telepíti az Ubuntut egy új rendszerre

a felhasználó lép a telepítőn. Korán, a telepítés előkészítésekor, és csak akkor, ha a rendszer harmadik féltől származó modulokat igényel, a felhasználó kéri a rendszer jelszavát, amely egyértelműen meg van jelölve, hogy szükséges a telepítés befejezése után, és amíg a rendszer telepítve van, egy új MOK automatikusan generálódik további felhasználói beavatkozás nélkül.

a rendszer által igényelt külső illesztőprogramok vagy kernelmodulok a csomag telepítésekor automatikusan felépülnek, és a build folyamat aláírási lépést tartalmaz. Az aláírási lépés automatikusan a korábban létrehozott MOK-ot használja a modul aláírására, így a rendszer újraindítása után azonnal betölthető, és a MOK bekerül a rendszer bizalmi adatbázisába.

miután a telepítés befejeződött, és a rendszer újraindul, az első boot a felhasználó megjelenik a MokManager program (része a telepített alátét betöltő), mint egy sor szöveges módban panelek, hogy az összes felhasználó, hogy beiratkozik a generált MOK. A felhasználó kiválasztja a “Mok regisztrálása” lehetőséget, megjelenik a beiratkozáshoz szükséges tanúsítvány ujjlenyomata, majd a rendszer kéri a beiratkozás megerősítését. A megerősítés után az új mok be lesz írva a firmware-be, és a felhasználót felkérik a rendszer újraindítására.

amikor a rendszer újraindul, az éppen beiratkozott MOK által aláírt harmadik féltől származó illesztőprogramok szükség szerint betöltődnek.

A felhasználó frissíti az UEFI-kompatibilis Ubuntu rendszert egy új kiadásra, ahol a rendszer harmadik féltől származó illesztőprogramokat igényel

frissítéskor a shim és shim aláírt csomagok frissítésre kerülnek. A shim-aláírással ellátott csomag telepítés utáni feladatai egy új MOK létrehozását eredményezik, és felszólítja a felhasználót egy jelszóra, amely egyértelműen megemlíti, hogy szükséges a frissítési folyamat befejezése és a rendszer újraindítása után.

a frissítés során a rendszermag csomagok és a harmadik féltől származó modulok frissítésre kerülnek. A harmadik féltől származó modulokat újraépítik az új kernelekhez, és a post-build folyamatuk automatikusan aláírja őket a MOK-val.

frissítés után a felhasználónak ajánlott újraindítani a rendszert.

az újraindítás, a felhasználó bemutatja a MokManager program (része a telepített alátét betöltő), mint egy sor szöveges módú panelek, hogy az összes felhasználó, hogy beiratkozik a generált MOK. A felhasználó kiválasztja a “Mok regisztrálása” lehetőséget, megjelenik a beiratkozáshoz szükséges tanúsítvány ujjlenyomata, majd a rendszer kéri a beiratkozás megerősítését. A felhasználó is megjelenik egy prompt, hogy újra engedélyezze a Secure Boot validation (abban az esetben kiderült, hogy le van tiltva); és MokManager ismét megerősítést kér a felhasználótól. Miután az összes lépést megerősítették, a shim érvényesítése újra engedélyezve van, az új MOK be lesz írva a firmware-be, és a felhasználót felkérik a rendszer újraindítására.

amikor a rendszer újraindul, az éppen beiratkozott MOK által aláírt harmadik féltől származó illesztőprogramok szükség szerint betöltődnek.

minden esetben, ha a rendszer fut UEFI Secure Boot engedélyezve van, és egy újabb változata shim; a telepítés minden új DKMS modul (harmadik fél driver) folytatja, hogy aláírja a beépített modul a MOK. Ez felhasználói beavatkozás nélkül történik, ha érvényes mok-kulcs létezik a rendszeren, és úgy tűnik, hogy már regisztrálva van.

Ha nem létezik MOK, vagy a meglévő MOK nincs regisztrálva, akkor egy új kulcs automatikusan létrejön közvetlenül az aláírás előtt, és a felhasználót arra kéri, hogy regisztrálja a kulcsot egy jelszó megadásával, amelyre az újraindításkor szükség lesz.