Ubuntu Wiki

Ce este UEFI Secure Boot?

UEFI Secure boot este un mecanism de verificare pentru a se asigura că codul lansat de firmware este de încredere.

Utilizarea corectă și sigură a UEFI Secure Boot necesită ca fiecare binar încărcat la pornire să fie validat în raport cu chei cunoscute, localizate în firmware, care denotă furnizori și surse de încredere pentru binare sau binare specifice de încredere care pot fi identificate prin hashing criptografic.

Majoritatea hardware-ului x86 vine din fabrică preîncărcat cu chei Microsoft. Acest lucru înseamnă că, în general, ne putem baza pe firmware-ul de pe aceste sisteme pentru a avea încredere în binarele care sunt semnate de Microsoft, iar comunitatea Linux se bazează foarte mult pe această presupunere pentru ca Secure Boot să funcționeze. Acesta este același proces utilizat de Red Hat și SUSE, de exemplu.

Multe arhitecturi ARM și alte arhitecturi acceptă, de asemenea, UEFI Secure Boot, dar este posibil să nu preîncarce cheile în firmware. Pe aceste arhitecturi, poate fi necesar să resemnați imaginile de pornire cu un certificat care este încărcat în firmware de către proprietarul hardware-ului.

Plan inițial de implementare: Plan de implementare.

Arhitecturi acceptate

• amd64: Un binar shim semnat de Microsoft și un binar grub semnat de Canonical sunt furnizate în arhiva principală Ubuntu ca shim-signed sau grub-efi-amd64-signed.

• arm64: Începând cu 20.04 (‘focal’), un binar shim semnat de Microsoft și un binar grub semnat de Canonical sunt furnizate în arhiva principală Ubuntu ca shim-signed sau grub-efi-arm64-signed. Există un bug GRUB în curs de investigare care trebuie rezolvat înainte ca acest lucru să funcționeze de la un capăt la altul.

Testând UEFI Secure Boot

Dacă sunteți interesat să testați Secure Boot pe sistemul dumneavoastră, consultați how-to aici: UEFI/SecureBoot/Testing.

Cum funcționează UEFI Secure Boot pe Ubuntu

Pe Ubuntu, toate binarele pre-construite destinate a fi încărcate ca parte a procesului de pornire, cu excepția imaginii initrd, sunt semnate de certificatul UEFI al Canonical, care la rândul său este implicit de încredere prin faptul că este încorporat în încărcătorul shim, semnat la rândul său de Microsoft.

Pe arhitecturi sau sisteme în care certificatele de semnare preîncărcate de la Microsoft nu sunt disponibile sau încărcate în firmware, utilizatorii pot înlocui semnăturile existente pe shim sau grub și le pot încărca după cum doresc, verificând cu propriile certificate importate în firmware-ul sistemului.

În timp ce sistemul pornește, firmware-ul încarcă binarul shim așa cum este specificat în variabilele BootEntry ale firmware-ului. Ubuntu își instalează propriul BootEntry în momentul instalării și îl poate actualiza de fiecare dată când încărcătorul de boot GRUB este actualizat. Deoarece binarul shim este semnat de Microsoft; acesta este validat și acceptat de firmware atunci când este verificat în raport cu certificatele deja prezente în firmware. Deoarece binarul shim încorporează un certificat Canonical, precum și propria bază de date de încredere, alte elemente ale mediului de pornire pot, pe lângă faptul că sunt semnate de unul dintre certificatele acceptabile preîncărcate în firmware, să fie semnate de cheia Canonical UEFI.

Următorul lucru încărcat de shim este imaginea din a doua etapă. Aceasta poate fi unul dintre două lucruri: fie GRUB, dacă sistemul pornește în mod normal; fie MokManager, dacă este necesară gestionarea cheilor, așa cum este configurată de variabilele firmware-ului (de obicei schimbate atunci când sistemul a fost rulat anterior).

Dacă pornește în mod normal; se încarcă binarul GRUB (grub*.efi) și se încearcă validarea acestuia în raport cu toate sursele de încredere cunoscute anterior. Binarul GRUB pentru Ubuntu este semnat de cheia Canonical UEFI, deci este validat cu succes și procesul de pornire continuă.

Dacă se pornește pentru a continua cu sarcinile de gestionare a cheilor, se încarcă binarul MokManager (mm*.efi). Acest binar este în mod explicit de încredere de către shim, fiind semnat de o cheie efemeră care există doar în timp ce se construiește binarul shim. Acest lucru înseamnă că numai binariul MokManager construit cu un anumit binar shim va putea fi rulat și limitează posibilitatea de compromitere prin utilizarea unor instrumente compromise. MokManager permite oricărui utilizator prezent la consola sistemului să înroleze chei, să elimine chei de încredere, să înroleze hash-uri binare și să comute validarea Secure Boot la nivel de shim, dar majoritatea sarcinilor necesită introducerea unei parole stabilite anterior pentru a confirma că utilizatorul de la consolă este într-adevăr persoana care a solicitat modificările. Astfel de parole supraviețuiesc doar pe parcursul unei singure rulări a shim / MokManager; și sunt șterse imediat ce procesul este finalizat sau anulat. Odată ce gestionarea cheilor este finalizată, sistemul este repornit și nu continuă pur și simplu cu pornirea, deoarece modificările de gestionare a cheilor pot fi necesare pentru a finaliza cu succes pornirea.

După ce sistemul continuă să pornească la GRUB; procesul GRUB încarcă orice configurație necesară (de obicei, încarcă configurația din ESP (EFI System Partition), care indică un alt fișier de configurare pe partiția rădăcină sau de pornire), care îi va indica imaginea kernelului de încărcat.

Aplicațiile EFFI de până în acest moment având acces complet la firmware-ul sistemului, inclusiv acces la modificarea variabilelor firmware de încredere, nucleul de încărcat trebuie, de asemenea, validat față de baza de date de încredere. Kernel-urile oficiale Ubuntu fiind semnate de cheia Canonical UEFI, acestea sunt validate cu succes, iar controlul este predat kernel-ului. Imaginile Initrd nu sunt validate.

În cazul nucleelor neoficiale sau al nucleelor construite de utilizatori, trebuie să se parcurgă pași suplimentari dacă utilizatorii doresc să încarce astfel de nuclee păstrând în același timp toate capacitățile UEFI Secure Boot. Toate nucleele trebuie să fie semnate pentru a putea fi încărcate de GRUB atunci când UEFI Secure Boot este activat, astfel încât utilizatorul va trebui să procedeze la propria semnare. Alternativ, utilizatorii pot dori să dezactiveze validarea în shim în timp ce pornesc cu Secure Boot activat pe un nucleu oficial, utilizând „sudo mokutil –disable-validation”, furnizând o parolă atunci când li se solicită și repornind; sau să dezactiveze complet Secure Boot în firmware.

Până în acest moment, orice eșec de validare a unei imagini de încărcat este întâmpinat cu o eroare critică care oprește procesul de pornire. Sistemul nu va continua să pornească și poate reporni automat după o perioadă de timp, având în vedere că alte variabile BootEntry pot conține căi de pornire care sunt valide și de încredere.

După ce au fost încărcate, nucleele validate vor dezactiva serviciile de pornire ale firmware-ului, renunțând astfel la privilegii și trecând efectiv în modul utilizator; unde accesul la variabilele de încredere este limitat la doar citire. Având în vedere permisiunile largi acordate modulelor kernelului, orice modul care nu este integrat în kernel va trebui, de asemenea, să fie validat la încărcare. Modulele construite și livrate de Canonical împreună cu kernelurile oficiale sunt semnate de cheia Canonical UEFI și, ca atare, sunt de încredere. Modulele construite la comandă vor necesita ca utilizatorul să facă pașii necesari pentru a semna modulele înainte ca încărcarea lor să fie permisă de kernel. Acest lucru poate fi realizat prin utilizarea comenzii „kmodsign” .

Modulurile nesemnate sunt pur și simplu refuzate de către kernel. Orice încercare de a le introduce cu insmod sau modprobe va eșua cu un mesaj de eroare.

Datorită faptului că mulți utilizatori au nevoie de module de la terți pentru ca sistemele lor să funcționeze corect sau pentru ca unele dispozitive să funcționeze; și că aceste module de la terți necesită compilare la nivel local pe sistem pentru a fi montate în kernelul care rulează, Ubuntu oferă unelte pentru a automatiza și simplifica procesul de semnare.

Cum pot face semnarea neautomatizată a driverelor?

Certe proiecte pot necesita utilizarea unor drivere de kernel personalizate care nu sunt configurate în așa fel încât să funcționeze cu DKMS. În aceste cazuri, oamenii ar trebui să se folosească de instrumentele incluse în pachetul shim-signed: scriptul update-secureboot-policy este disponibil pentru a genera un nou MOK (dacă niciun modul construit prin DKMS nu a declanșat deja generarea unuia).

Utilizați următoarea comandă pentru a înscrie o cheie existentă în shim:

sudo update-secureboot-policy --enroll-key

Dacă nu există un MOK, scriptul va ieși cu un mesaj în acest sens. Dacă cheia este deja înscrisă, scriptul va ieși, fără a face nimic. În cazul în care cheia există, dar nu se arată că este înrolată, utilizatorului i se va cere o parolă pe care să o folosească după repornire, astfel încât cheia să poată fi înrolată.

Se poate genera un nou MOK folosind următoarea comandă:

sudo update-secureboot-policy --new-key

Și apoi să înroleze cheia nou generată în shim cu comanda menționată anterior pentru această sarcină.

Modulele de kernel pot fi apoi semnate cu comanda kmodsign (a se vedea UEFI/SecureBoot/Signing) ca parte a procesului de construire a acestora.

Implicații de securitate în gestionarea cheilor de proprietar de mașină

MOK-ul generat în momentul instalării sau al actualizării este specific mașinii și este permis doar de către kernel sau shim pentru a semna modulele kernel, prin utilizarea unui OID KeyUsage specific (1.3.6.1.4.1.2312.16.1.2) care denotă limitările MOK-ului.

Versiunile recente ale shim-urilor includ o logică pentru a urmări limitările cheilor de semnare numai a modulelor. Aceste chei vor putea fi înscrise în firmware în baza de date de încredere a lui shim, dar vor fi ignorate atunci când shim sau GRUB validează imaginile pentru a le încărca în firmware. Funcția verify() a lui shim va valida cu succes numai imaginile semnate de chei care nu includ OID-ul „Module-signing only” (1.3.6.1.4.1.2312.16.1.2) KeyUsage. Kernel-urile Ubuntu utilizează baza de date globală de încredere (care include atât cea a shim-urilor, cât și cea a firmware-ului) și va accepta oricare dintre cheile incluse ca chei de semnare la încărcarea modulelor kernel-ului.

Datorită limitărilor impuse asupra MOK generate automat și faptului că utilizatorii cu acces de superutilizator la sistem și acces la consola de sistem pentru a introduce parola necesară la înscrierea cheilor au deja acces de nivel înalt la sistem; cheia MOK generată este păstrată în sistemul de fișiere ca fișiere obișnuite deținute de root cu permisiuni de numai citire. Acest lucru este considerat suficient pentru a limita accesul la MOK în vederea semnării de către utilizatori sau scripturi rău intenționate, mai ales având în vedere că nu există MOK pe sistem decât dacă este nevoie de drivere de la terți. Acest lucru limitează posibilitatea de compromitere în urma utilizării abuzive a unei chei MOK generate pentru semnarea unui modul de kernel rău intenționat. Acest lucru este echivalent cu compromiterea aplicațiilor userland, care ar fi deja posibilă în cazul accesului superutilizatorului la sistem, iar securizarea acestui aspect nu intră în sfera de aplicare a UEFI Secure Boot.

Este posibil ca sistemele anterioare să fi avut validarea Secure Boot dezactivată în shim. Ca parte a procesului de actualizare, aceste sisteme vor fi migrate pentru a reactiva validarea Secure Boot în shim și pentru a înrola o nouă cheie MOK, dacă este cazul.

Procesul de generare și semnare a cheii MOK

Procesul de generare și semnare a cheii este ușor diferit în funcție de faptul că avem de-a face cu o instalare nouă sau cu o actualizare a unui sistem care a rulat anterior Ubuntu; aceste două cazuri sunt clar marcate mai jos.

În toate cazurile, dacă sistemul nu pornește în modul UEFI, nu vor avea loc etape speciale de semnare a modulelor de kernel sau de generare a cheilor.

Dacă Secure Boot este dezactivat, generarea și înscrierea MOK se întâmplă în continuare, deoarece utilizatorul poate activa ulterior Secure Boot. Sistemul ar trebui să funcționeze corect dacă acesta este cazul.

Utilizatorul instalează Ubuntu pe un sistem nou

Utilizatorul parcurge pașii prin programul de instalare. La început, atunci când se pregătește instalarea și numai dacă sistemul necesită module de la terți pentru a funcționa, utilizatorului i se solicită o parolă de sistem care este marcată în mod clar ca fiind necesară după finalizarea instalării, iar în timp ce sistemul este instalat, un nou MOK este generat automat fără altă interacțiune din partea utilizatorului.

Driverele terților sau modulele de kernel necesare sistemului vor fi construite automat atunci când pachetul este instalat, iar procesul de construire include o etapă de semnare. Etapa de semnare utilizează automat MOK-ul generat anterior pentru a semna modulul, astfel încât acesta să poată fi încărcat imediat după ce sistemul este repornit și MOK-ul este inclus în baza de date de încredere a sistemului.

După ce instalarea este finalizată și sistemul este repornit, la prima pornire, utilizatorului i se prezintă programul MokManager (parte a încărcătorului de shim instalat), sub forma unui set de panouri în mod text, care îl invită pe utilizator să înscrie MOK-ul generat. Utilizatorul selectează „Enroll MOK” (Înrolați MOK), i se afișează o amprentă digitală a certificatului care urmează să fie înrolat și i se cere să confirme înrolarea. După confirmare, noul MOK va fi introdus în firmware, iar utilizatorului i se va cere să repornească sistemul.

Când sistemul se repornește, driverele terților semnate de MOK-ul care tocmai a fost înrolat vor fi încărcate, după caz.

Utilizatorul actualizează un sistem Ubuntu compatibil UEFI la o nouă versiune în care sistemul necesită drivere de la terți

La actualizare, pachetele shim și cele semnate de shim sunt actualizate. Sarcinile post-instalare ale pachetului shim-signed procedează la generarea unui nou MOK și solicită utilizatorului o parolă care este clar menționată ca fiind necesară odată ce procesul de actualizare este finalizat și sistemul repornit.

În timpul actualizării, pachetele de kernel și modulele terților sunt actualizate. Modulele terților sunt reconstruite pentru noile nuclee, iar procesul post-construcție al acestora procedează la semnarea automată cu MOK.

După actualizare, utilizatorului i se recomandă să își repornească sistemul.

La repornire, utilizatorului i se prezintă programul MokManager (parte a încărcătorului de șaibe instalat), sub forma unui set de panouri în mod text, care îl ajută pe utilizator să înscrie MOK-ul generat. Utilizatorul selectează „Enroll MOK” (Înrolați MOK), i se afișează o amprentă digitală a certificatului care urmează să fie înrolat și i se cere să confirme înrolarea. Utilizatorului i se prezintă, de asemenea, o solicitare de reactivare a validării Secure Boot (în cazul în care s-a constatat că a fost dezactivată); iar MokManager solicită din nou confirmarea din partea utilizatorului. Odată ce toți pașii sunt confirmați, validarea șamd este reactivată, noul MOK va fi introdus în firmware, iar utilizatorului i se va cere să repornească sistemul.

Când sistemul se repornește, driverele terților semnate de MOK-ul care tocmai a fost înscris vor fi încărcate după cum este necesar.

În toate cazurile, odată ce sistemul funcționează cu UEFI Secure Boot activat și cu o versiune recentă de shim; instalarea oricărui nou modul DKMS (driver terț) va proceda la semnarea modulului construit cu MOK. Acest lucru se va întâmpla fără interacțiunea utilizatorului dacă există o cheie MOK validă pe sistem și pare să fie deja înscrisă.

Dacă nu există nicio MOK sau MOK existentă nu este înrolată, o nouă cheie va fi creată automat chiar înainte de semnare, iar utilizatorului i se va cere să înroleze cheia prin furnizarea unei parole care va fi necesară la repornire.