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 boot să fie validat împotriva cheilor 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-urilor x86 provin din fabrică preîncărcate cu chei Microsoft. Aceasta înseamnă că, în general, ne putem baza pe firmware-ul acestor sisteme pentru a avea încredere în binare semnate de Microsoft, iar comunitatea Linux se bazează foarte mult pe această presupunere pentru ca boot-ul securizat să funcționeze. Acesta este același proces folosit de Red Hat și SUSE, de exemplu.

multe arhitecturi ARM și alte arhitecturi acceptă, de asemenea, UEFI Secure Boot, dar este posibil să nu fie chei de preîncărcare în firmware. Pe aceste arhitecturi, poate fi necesar să semnați din nou imaginile de pornire cu un certificat care este încărcat în firmware de către proprietarul hardware-ului.

planul inițial de implementare: planul de implementare.

arhitecturi acceptate

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

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

testarea UEFI Secure Boot

Dacă sunteți interesat să testați Secure Boot pe sistemul dvs., consultați instrucțiunile de aici: UEFI/SecureBoot / Testing.

cum UEFI Secure Boot funcționează pe Ubuntu

pe Ubuntu, toate binarele pre-construite destinate a fi încărcate ca parte a procesului de boot, cu excepția imaginii initrd, sunt semnate de certificatul UEFI Canonical, care în sine este implicit de încredere prin încorporarea în încărcătorul shim, semnat 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.

pe măsură ce sistemul pornește, firmware-ul încarcă binarul shim așa cum este specificat în variabilele bootentry firmware. Ubuntu instalează propriul BootEntry la momentul instalării și îl poate actualiza oricând este actualizat bootloader-ul GRUB. Deoarece binarul shim este semnat de Microsoft; este validat și acceptat de firmware la verificarea certificatelor deja prezente în firmware. Deoarece binarul shim încorporează un certificat canonic, precum și propria bază de date de încredere, alte elemente ale mediului de pornire pot fi semnate, pe lângă faptul că sunt semnate de unul dintre certificatele acceptabile preîncărcate în firmware, să fie semnate de cheia UEFI a Canonical.

următorul lucru încărcat de shim este imaginea din a doua etapă. Acesta poate fi unul dintre cele două lucruri: fie GRUB, dacă sistemul pornește normal; sau MokManager, dacă este necesară gestionarea cheilor, așa cum este configurat de variabilele firmware (de obicei modificate atunci când sistemul rula anterior).

dacă porniți în mod normal; binar GRUB (grub*.efi) este încărcat și validarea sa este încercată împotriva tuturor surselor de încredere cunoscute anterior. Binarul GRUB pentru Ubuntu este semnat de cheia UEFI canonică, deci este validat cu succes și procesul de boot continuă.

dacă boot-ul pentru a continua cu sarcini de gestionare cheie, binarul MokManager (mm*.efi) este încărcat. Acest binar este în mod explicit de încredere de către shim, fiind semnat de o cheie efemeră care există numai în timp ce binarul shim este construit. Aceasta înseamnă că numai binarul MokManager construit cu un anumit binar shim va fi permis să ruleze și limitează posibilitatea compromisului din utilizarea instrumentelor compromise. MokManager permite oricărui utilizator prezent la consola de sistem să înscrie chei, să elimine chei de încredere, să înscrie hash-uri binare și să comute validarea Secure Boot la nivelul shim, dar majoritatea sarcinilor necesită introducerea unei parole setate anterior pentru a confirma că utilizatorul de la consolă este într-adevăr persoana care a solicitat modificări. Astfel de parole supraviețuiesc doar pe o singură rulare de 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 bootarea, deoarece modificările de gestionare a cheilor pot fi necesare pentru a finaliza cu succes boot-ul.

odată ce sistemul continuă să pornească la GRUB; procesul GRUB încarcă orice configurație necesară (de obicei încărcarea configurației din ESP (partiția de sistem EFI), indicând un alt fișier de configurare de pe partiția rădăcină sau boot), care îl va indica spre imaginea kernel-ului de încărcat.

aplicații EFI până în acest moment având acces complet la firmware-ul sistemului, inclusiv accesul la schimbarea variabilelor firmware de încredere, nucleul de încărcat trebuie, de asemenea, să fie validat în baza de date de încredere. Kernelurile oficiale Ubuntu fiind semnate de cheia UEFI canonică, acestea sunt validate cu succes, iar controlul este predat kernel-ului. Imaginile Initrd nu sunt validate.

în cazul nucleelor neoficiale sau nucleelor construite de utilizatori, trebuie luate măsuri suplimentare dacă utilizatorii doresc să încarce astfel de nuclee, păstrând în același timp capacitățile complete ale 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ă continue cu propria semnare. În mod alternativ, utilizatorii ar putea dori să dezactiveze validarea în shim în timp ce sunt porniți cu Secure Boot activat pe un kernel Oficial utilizând ‘sudo mokutil –disable-validation’, oferind o parolă atunci când vi se solicită și repornirea; sau pentru a dezactiva 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 valide și de încredere.

odată încărcate, nucleele validate vor dezactiva serviciile de pornire ale firmware-ului, renunțând astfel la privilegii și trecând efectiv la modul utilizator; unde accesul la variabile de încredere este limitat doar la citire. Având în vedere permisiunile largi acordate modulelor kernel, orice modul care nu este încorporat în kernel va trebui, de asemenea, să fie validat la Încărcare. Modulele construite și livrate de Canonical cu nucleele oficiale sunt semnate de cheia UEFI canonică și, ca atare, sunt de încredere. Modulele personalizate vor cere utilizatorului să ia măsurile necesare pentru a semna modulele înainte de a le încărca este permisă de kernel. Acest lucru poate fi realizat folosind comanda ‘kmodsign’.

modulele nesemnate sunt pur și simplu refuzate de kernel. Orice încercare de a le insera cu insmod sau modprobe va eșua cu un mesaj de eroare.

având în vedere că mulți utilizatori necesită module terțe pentru ca sistemele lor să funcționeze corect sau pentru ca unele dispozitive să funcționeze; și că aceste module terțe necesită construirea locală a sistemului pentru a fi montate pe nucleul care rulează, Ubuntu oferă instrumente pentru automatizarea și simplificarea procesului de semnare.

Cum pot face semnarea neautomată a șoferilor?

unele proiecte pot necesita utilizarea driverelor de kernel personalizate care nu sunt configurate astfel încât să funcționeze cu DKMS. În aceste cazuri, oamenii ar trebui să utilizeze instrumentele incluse în pachetul semnat de shim: scriptul update-secureboot-policy este disponibil pentru a genera un nou MOK (dacă Niciun modul construit de 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ă 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. Dacă cheia există, dar nu se arată că este înscrisă, utilizatorul va fi solicitat să utilizeze o parolă după repornire, astfel încât cheia să poată fi înscrisă.

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

sudo update-secureboot-policy --new-key

și apoi se înscrie cheia nou generată în shim cu comanda menționată anterior pentru acea sarcină.

modulele Kernel pot fi apoi semnate cu comanda kmodsign (vezi UEFI/SecureBoot / Signing) ca parte a procesului lor de construire.

implicații de securitate în gestionarea cheilor proprietarului mașinii

MOK generat la momentul instalării sau la actualizare este specific mașinii și este permis doar de kernel sau shim să semneze module de kernel, prin utilizarea unui specific KeyUsage OID (1.3.6.1.4.1.2312.16.1.2) care denotă limitările MOK.

versiunile recente shim includ logica pentru a urma limitările tastelor numai pentru semnarea modulului. Aceste chei vor fi permise să fie înscrise în firmware-ul din Baza de date trust shim, dar vor fi ignorate atunci când shim sau GRUB validează imaginile pentru a se încărca în firmware. Funcția Verificare() a lui Shim va valida cu succes numai imaginile semnate de chei care nu includ „Module-signing only” (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. Nucleele Ubuntu folosesc baza de date Global trust (care include atât shim-urile, cât și firmware-ul) și vor accepta oricare dintre cheile incluse ca chei de semnare la încărcarea modulelor de kernel.

având în vedere limitările impuse MOK-ului generat automat și faptul că utilizatorii cu acces superuser la sistem și acces la consola de sistem pentru a introduce parola necesară la înscrierea cheilor au deja acces la nivel înalt la sistem; cheia MOK generată este păstrată pe sistemul de fișiere ca fișiere obișnuite deținute de root cu permisiuni numai pentru citire. Acest lucru este considerat suficient pentru a limita accesul la MOK pentru semnarea de către utilizatori sau scripturi rău intenționate, mai ales având în vedere că nu există MOK în sistem decât dacă necesită drivere terțe. Acest lucru limitează posibilitatea compromisului de la utilizarea abuzivă a unei chei MOK generate la semnarea unui modul kernel rău intenționat. Acest lucru este echivalent cu compromisul aplicațiilor userland, care ar fi deja posibil cu accesul superuser la sistem, iar asigurarea acestui lucru este în afara domeniului de aplicare al 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 înscrierea unei noi chei MOK atunci când este cazul.

procesul de generare și semnare MOK

procesul de generare și semnare a cheilor este ușor diferit în funcție de faptul dacă avem de-a face cu o instalare nouă sau cu o actualizare a sistemului care rulează anterior Ubuntu; aceste două cazuri sunt clar marcate mai jos.

în toate cazurile, dacă sistemul nu pornește în modul UEFI, nu se vor întâmpla pași speciali de semnare a modulului kernel sau generarea cheilor.

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

utilizatorul instalează Ubuntu pe un nou sistem

utilizatorul trece prin Programul de instalare. La început, când se pregătește instalarea și numai dacă sistemul necesită module terțe pentru a funcționa, utilizatorului i se solicită o parolă de sistem care este clar marcată ca fiind necesară după finalizarea instalării și, în timp ce sistemul este instalat, un nou MOK este generat automat fără alte interacțiuni cu utilizatorul.

driverele terțe sau modulele kernel cerute de sistem vor fi construite automat atunci când pachetul este instalat, iar procesul de construire include un pas de semnare. Pasul de semnare utilizează automat MOK-ul generat anterior pentru a semna modulul, astfel încât să poată fi încărcat imediat după repornirea sistemului și MOK-ul este inclus în baza de date de încredere a sistemului.

odată ce instalarea este completă și sistemul este repornit, la prima pornire utilizatorul este prezentat cu programul MokManager (parte a instalat Shim loader), ca un set de panouri text-mode că toate utilizatorul să se înscrie Mok generat. Utilizatorul selectează „Enroll MOK”, i se afișează o amprentă a certificatului pentru înscriere și i se solicită să confirme înscrierea. Odată confirmat, noul MOK va fi introdus în firmware și utilizatorul va fi rugat să repornească sistemul.

când sistemul repornește, driverele terțe semnate de MOK tocmai înscrise vor fi încărcate după cum este necesar.

utilizatorul actualizează un sistem Ubuntu compatibil UEFI la o nouă versiune în care sistemul necesită drivere terțe

la actualizare, pachetele semnate shim și shim sunt actualizate. Sarcinile post-instalare ale pachetului semnat de shim continuă să genereze un nou MOK și solicită utilizatorului o parolă care este menționată în mod clar ca fiind necesară odată ce procesul de actualizare este finalizat și sistemul repornit.

în timpul actualizării, pachetele de kernel și modulele terță parte sunt actualizate. Modulele terță parte sunt reconstruite pentru noile kernel-uri și procesul lor post-build continuă să le semneze automat cu MOK.

după actualizare, utilizatorul este recomandat pentru a reporni sistemul lor.

la repornire, utilizatorul este prezentat cu programul MokManager (parte a instalat Shim loader), ca un set de panouri în modul text care tot utilizatorul să se înscrie Mok generat. Utilizatorul selectează „Enroll MOK”, i se afișează o amprentă a certificatului pentru înscriere și i se solicită să confirme înscrierea. Utilizatorului i se prezintă, de asemenea, un prompt pentru a reactiva validarea Secure Boot (în cazul în care s-a constatat că este dezactivată); iar MokManager necesită din nou confirmare de la utilizator. Odată ce toți pașii sunt confirmați, validarea shim este reactivată, noul MOK va fi introdus în firmware și utilizatorul va fi rugat să repornească sistemul.

când sistemul repornește, driverele terțe semnate de MOK tocmai înscrise vor fi încărcate după cum este necesar.

în toate cazurile, odată ce sistemul rulează cu UEFI Secure Boot activat și o versiune recentă a shim; instalarea oricărui nou modul DKMS (driver terță parte) va continua să semneze modulul 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ă MOK sau MOK-ul existent nu este înscris, o nouă cheie va fi creată automat chiar înainte de semnare și utilizatorului i se va solicita să înscrie cheia furnizând o parolă care va fi necesară la repornire.