Ubuntu Wiki

Mikä on UEFI Secure Boot?

UEFI Secure Boot on tarkistusmekanismi, jolla varmistetaan, että laiteohjelmiston käynnistämään koodiin luotetaan.

UEFI Secure Bootin asianmukainen ja turvallinen käyttö edellyttää, että jokainen käynnistyksen yhteydessä ladattava binääriohjelma varmennetaan laiteohjelmistossa sijaitsevia tunnettuja avaimia vastaan, jotka ilmaisevat binääritiedostojen luotettavat toimittajat ja lähteet tai luotettavat erityiset binääritiedostot, jotka voidaan tunnistaa kryptografisen hashingin avulla.

Useimmat x86-laitteistot tulevat tehtaalta valmiiksi ladattuina Microsoftin avaimilla. Tämä tarkoittaa, että voimme yleensä luottaa siihen, että näiden järjestelmien laiteohjelmisto luottaa Microsoftin allekirjoittamiin binääreihin, ja Linux-yhteisö luottaa vahvasti tähän olettamukseen, jotta Secure Boot toimisi. Tätä samaa prosessia käyttävät esimerkiksi Red Hat ja SUSE.

Monet ARM- ja muut arkkitehtuurit tukevat myös UEFI Secure Bootia, mutta eivät välttämättä esitä avaimia firmwareen. Näillä arkkitehtuureilla saattaa olla tarpeen allekirjoittaa käynnistyskuvat uudelleen varmenteella, jonka laitteiston omistaja on ladannut laiteohjelmistoon.

Alustava toteutussuunnitelma: Toteutussuunnitelma.

Tuetut arkkitehtuurit

• amd64: Microsoftin allekirjoittama shim-binääri ja Canonicalin allekirjoittama grub-binääri toimitetaan Ubuntun pääarkistossa nimellä shim-signed tai grub-efi-amd64-signed.

• arm64: 20.04:stä (”focal”) alkaen Microsoftin allekirjoittama shim-binääri ja Canonicalin allekirjoittama grub-binääri toimitetaan Ubuntun pääarkistossa shim-signoituna tai grub-efi-arm64-signoituna. Tutkittavana on GRUB-virhe, joka on ratkaistava, ennen kuin tämä toimii päästä päähän.

Testaus UEFI Secure Bootista

Jos olet kiinnostunut testaamaan Secure Bootia järjestelmässäsi, tutustu ohjeeseen täällä: UEFI/SecureBoot/Testaus.

Miten UEFI Secure Boot toimii Ubuntussa

Ubuntussa kaikki valmiit binääritiedostot, jotka on tarkoitus ladata osana käynnistysprosessia, lukuun ottamatta initrd-kuvaa, on allekirjoitettu Canonicalin UEFI-varmenteella, joka itsessään on implisiittisesti luotettu, koska se on upotettu shim-lataajaan, joka on puolestaan Microsoftin allekirjoittama.

Arkkitehtuureissa tai järjestelmissä, joissa Microsoftin valmiiksi ladattuja allekirjoitusvarmenteita ei ole saatavilla tai ladattu laiteohjelmistoon, käyttäjät voivat korvata shim- tai grub-ohjelmiston olemassa olevat allekirjoitukset ja ladata ne haluamallaan tavalla todentaen järjestelmän laiteohjelmistoon tuotuja omia varmenteita vastaan.

Järjestelmän käynnistyessä firmware lataa shim-binäärin firmwaren BootEntry-muuttujissa määritellyllä tavalla. Ubuntu asentaa oman BootEntrynsä asennuksen yhteydessä ja voi päivittää sen milloin tahansa, kun GRUB-käynnistyslatausohjelma päivitetään. Koska shim-binääri on Microsoftin allekirjoittama, laiteohjelmisto validoi ja hyväksyy sen, kun se verifioi sen laiteohjelmistossa jo olevia varmenteita vastaan. Koska shim-binääri sisältää Canonicalin varmenteen sekä oman luottamustietokantansa, käynnistysympäristön muut osat voidaan allekirjoittaa jollakin laiteohjelmistoon valmiiksi ladatulla hyväksyttävällä varmenteella tai Canonicalin UEFI-avaimella sen lisäksi, että ne allekirjoitetaan jollakin laiteohjelmistoon valmiiksi ladatulla hyväksyttävällä varmenteella.

Seuraava shimillä ladattava asia on toisen vaiheen image. Tämä voi olla jompikumpi kahdesta asiasta: joko GRUB, jos järjestelmä käynnistyy normaalisti, tai MokManager, jos tarvitaan firmware-muuttujien määrittelemää avaintenhallintaa (yleensä muutettu, kun järjestelmä oli aiemmin käynnissä).

Jos järjestelmä käynnistyy normaalisti; GRUB-binääri (grub*.efi) ladataan ja sen validointi yritetään suorittaa kaikkien aiemmin tunnettujen luotettavien lähteiden perusteella. Ubuntun GRUB-binääri on allekirjoitettu Canonicalin UEFI-avaimella, joten sen validointi onnistuu ja käynnistysprosessi jatkuu.

Jos käynnistyksen tarkoituksena on jatkaa avaintenhallintatehtäviä, ladataan MokManagerin binääri (mm*.efi). Shim luottaa nimenomaisesti tähän binääriin, koska se on allekirjoitettu ephemeral-avaimella, joka on olemassa vain shim-binäärin rakentamisen ajan. Tämä tarkoittaa, että vain tietyn shim-binäärin kanssa rakennetun MokManager-binäärin sallitaan toimia, ja rajoittaa kompromissityökalujen käytön aiheuttamaa vaarantumisen mahdollisuutta. MokManagerin avulla kuka tahansa järjestelmän konsolissa oleva käyttäjä voi rekisteröidä avaimia, poistaa luotettuja avaimia, rekisteröidä binäärihasheja ja vaihtaa Secure Boot -validoinnin shim-tasolla, mutta useimmat tehtävät edellyttävät aiemmin asetetun salasanan syöttämistä, jotta voidaan varmistaa, että konsolissa oleva käyttäjä on todellakin muutoksia pyytänyt henkilö. Tällaiset salasanat säilyvät vain yhden shim/MokManager-ajon ajan, ja ne poistetaan heti, kun prosessi on suoritettu loppuun tai peruutettu. Kun avaintenhallinta on saatu päätökseen, järjestelmä käynnistetään uudelleen, eikä käynnistystä yksinkertaisesti jatketa, koska avaintenhallinnan muutokset saattavat olla tarpeen käynnistyksen onnistumiseksi.

Kun järjestelmä jatkaa GRUB-käynnistystä; GRUB-prosessi lataa tarvittavan konfiguraation (yleensä lataamalla konfiguraation ESP:stä (EFI-järjestelmäosio), joka osoittaa toiseen konfiguraatiotiedostoon juuri- tai käynnistysosiossa), joka osoittaa sille ladattavan ytimen kuvan.

EFI-sovelluksilla on tähän asti täysi pääsy järjestelmän laiteohjelmistoon, mukaan lukien pääsy luotettujen laiteohjelmistomuuttujien muuttamiseen, ladattava ydin on myös validoitava luottamustietokannan perusteella. Viralliset Ubuntu-ytimet on allekirjoitettu Canonicalin UEFI-avaimella, ne on onnistuneesti validoitu ja hallinta luovutetaan ytimelle. Initrd-kuvia ei validoida.

Epävirallisten ytimien tai käyttäjien rakentamien ytimien tapauksessa on ryhdyttävä lisätoimiin, jos käyttäjät haluavat ladata tällaisia ytimiä säilyttäen UEFI Secure Bootin kaikki ominaisuudet. Kaikki ytimet on allekirjoitettava, jotta GRUB voi ladata ne, kun UEFI Secure Boot on käytössä, joten käyttäjän on itse allekirjoitettava ne. Vaihtoehtoisesti käyttäjät voivat halutessaan poistaa validoinnin käytöstä shimissä, kun virallisen ytimen Secure Boot on käytössä, käyttämällä komentoa ’sudo mokutil –disable-validation’, antamalla pyydettäessä salasanan ja käynnistämällä järjestelmän uudelleen; tai poistamalla Secure Bootin käytöstä laiteohjelmistossa kokonaan.

Tähän asti kaikki epäonnistumiset ladattavan kuvan validoinnissa johtavat kriittiseen virheeseen, joka pysäyttää käynnistysprosessin. Järjestelmä ei jatka käynnistystä, ja se saattaa käynnistyä automaattisesti uudelleen jonkin ajan kuluttua, kun otetaan huomioon, että muut BootEntry-muuttujat saattavat sisältää käynnistyspolkuja, jotka ovat kelvollisia ja luotettavia.

Kun ydin on ladattu, validoidut ytimet poistavat laiteohjelmiston Boot Services -palvelut käytöstä, jolloin ne menettävät käyttöoikeudet ja siirtyvät tehokkaasti käyttäjätilaan, jossa pääsy luotettuihin muuttujiin on rajoitettu vain lukuoikeuteen. Koska ytimen moduuleille annetaan laajat oikeudet, kaikki moduulit, joita ei ole rakennettu ytimeen, on myös validoitava ladattaessa. Canonicalin rakentamat ja virallisten ytimien mukana toimitetut moduulit on allekirjoitettu Canonicalin UEFI-avaimella, joten niihin luotetaan. Mukautetut moduulit edellyttävät, että käyttäjä toteuttaa tarvittavat toimenpiteet moduulien allekirjoittamiseksi, ennen kuin ytimen on sallittua ladata ne. Tämä voidaan tehdä käyttämällä komentoa ’kmodsign’.

Ydin yksinkertaisesti hylkää allekirjoittamattomat moduulit. Kaikki yritykset lisätä niitä insmod- tai modprobe-ohjelmalla epäonnistuvat virheilmoituksella.

Kun otetaan huomioon, että monet käyttäjät tarvitsevat kolmannen osapuolen moduuleja, jotta heidän järjestelmänsä toimisi kunnolla tai jotkin laitteet toimisivat; ja että nämä kolmannen osapuolen moduulit vaativat rakentamista paikallisesti järjestelmässä, jotta ne voidaan sovittaa käynnissä olevaan ytimeen, Ubuntu tarjoaa työkaluja allekirjoittamisprosessin automatisoimiseksi ja yksinkertaistamiseksi.

Miten voin tehdä ajureiden ei-automaattisen allekirjoittamisen?

Jotkut projektit saattavat vaatia mukautettujen ytimen ajureiden käyttöä, joita ei ole asetettu siten, että ne toimisivat DKMS:n kanssa. Näissä tapauksissa ihmisten tulisi käyttää shim-signed-pakettiin sisältyviä työkaluja: update-secureboot-policy-skripti on käytettävissä uuden MOK:n luomiseen (jos yksikään DKMS:llä rakennettu moduuli ei ole jo käynnistänyt sellaisen luomista).

Käytä seuraavaa komentoa rekisteröidäksesi olemassa olevan avaimen shimiin:

sudo update-secureboot-policy --enroll-key

Jos MOK:ia ei ole olemassa, komentosarja poistuu siitä kertovan viestin kanssa. Jos avain on jo kirjattu, skripti poistuu tekemättä mitään. Jos avain on olemassa, mutta sitä ei ole kirjattu, käyttäjää pyydetään antamaan salasana uudelleenkäynnistyksen jälkeen, jotta avain voidaan kirjata.

Voidaan luoda uusi MOK seuraavalla komennolla:

sudo update-secureboot-policy --new-key

Ja sitten rekisteröidä juuri luotu avain shimiin aiemmin mainitulla komennolla kyseistä tehtävää varten.

Ydinmoduulit voidaan sitten allekirjoittaa kmodsign-komennolla (katso UEFI/SecureBoot/Signing) osana niiden rakentamisprosessia.

Turvallisuusvaikutukset koneen omistajan avaimen hallinnassa

Asennuksen yhteydessä tai päivityksen yhteydessä luotu MOK on konekohtainen, ja se on sallittu vain ytimen tai shim-moduulin ytimen moduulien allekirjoittamiseen käyttämällä tiettyä KeyUsage OID:tä (1.3.6.1.4.1.2312.16.1.1.2), joka ilmaisee MOK:n rajoitukset.

Uudemmat shim-versiot sisältävät logiikan, joka noudattaa vain moduulin allekirjoittavien avainten rajoituksia. Nämä avaimet sallitaan kirjata laiteohjelmistoon shimin luottamustietokannassa, mutta ne jätetään huomiotta, kun shim tai GRUB validoi kuvia ladattavaksi laiteohjelmistoon. Shimin verify()-funktio validoi onnistuneesti vain kuvat, jotka on allekirjoitettu avaimilla, jotka eivät sisällä ”Module-signing only” (1.3.6.1.4.1.2312.16.1.1.2) KeyUsage OID:tä. Ubuntun ytimet käyttävät globaalia luottamustietokantaa (joka sisältää sekä shim- että firmware-tietokannan) ja hyväksyvät minkä tahansa sisältämänsä avaimen allekirjoitusavaimeksi ladattaessa ytimen moduuleja.

Automaattisesti luodulle MOK-avaimelle asetetut rajoitukset ja se, että käyttäjillä, joilla on superuser-oikeudet järjestelmään ja pääsy järjestelmäkonsoliin avainten rekisteröinnissä vaadittavan salasanan syöttämiseksi, on jo korkean tason oikeudet järjestelmään; luotu MOK-avain säilytetään tiedostojärjestelmässä tavallisina tiedostoina, jotka ovat rootin omistuksessa ja joilla on vain lukuoikeudet. Tätä pidetään riittävänä rajoittamaan pahantahtoisten käyttäjien tai skriptien pääsyä MOK-avaimeen allekirjoitusta varten, varsinkin kun otetaan huomioon, että järjestelmässä ei ole MOK-avainta, ellei se edellytä kolmannen osapuolen ajureita. Tämä rajoittaa mahdollisuutta vaarantaa luodun MOK-avaimen väärinkäyttöä haitallisen ytimen moduulin allekirjoittamiseen. Tämä vastaa käyttäjäsovellusten vaarantamista, joka olisi jo mahdollista, jos järjestelmään olisi pääkäyttäjän pääsy, ja tämän turvaaminen ei kuulu UEFI Secure Bootin piiriin.

Aiemmissa järjestelmissä Secure Boot -validointi on saatettu poistaa käytöstä shimissä. Osana päivitysprosessia nämä järjestelmät siirretään ottamaan Secure Boot -valvonta uudelleen käyttöön shimissä ja rekisteröimään tarvittaessa uusi MOK-avain.

MOK:n luonti- ja allekirjoitusprosessi

Avaimen luonti- ja allekirjoitusprosessi on hieman erilainen riippuen siitä, onko kyseessä upouusi asennus vai päivitys järjestelmään, jossa on aiemmin ollut Ubuntu; nämä kaksi tapausta on merkitty selvästi alla.

Jos järjestelmä ei käynnisty UEFI-tilassa, mitään erityisiä ytimen moduulin allekirjoitusvaiheita tai avaimen tuottamista ei tapahdu kaikissa tapauksissa.

Jos Secure Boot on poistettu käytöstä, MOK:n generointi ja rekisteröinti tapahtuvat silti, koska käyttäjä voi myöhemmin ottaa Secure Bootin käyttöön. Niiden järjestelmän pitäisi toimia oikein, jos näin on.

Käyttäjä asentaa Ubuntun uuteen järjestelmään

Käyttäjä käy läpi asennusohjelman. Asennuksen alkuvaiheessa, asennusta valmisteltaessa ja vain jos järjestelmä vaatii kolmannen osapuolen moduuleja toimiakseen, käyttäjää pyydetään antamaan järjestelmän salasana, joka on selvästi merkitty vaadittavaksi asennuksen päätyttyä, ja järjestelmän asennuksen aikana uusi MOK luodaan automaattisesti ilman käyttäjän muuta vuorovaikutusta.

Järjestelmän tarvitsemat kolmannen osapuolen ajurit tai ytimen moduulit rakennetaan automaattisesti, kun paketti asennetaan, ja rakennusprosessi sisältää allekirjoitusvaiheen. Allekirjoitusvaihe käyttää automaattisesti aiemmin luotua MOK:ia moduulin allekirjoittamiseen, jolloin se voidaan ladata välittömästi, kun järjestelmä käynnistetään uudelleen ja MOK on sisällytetty järjestelmän luottamustietokantaan.

Kun asennus on valmis ja järjestelmä käynnistetään uudelleen, ensimmäisellä käynnistyskerralla käyttäjälle esitetään MokManager-ohjelma (osa asennettua shim-latausohjelmaa), joka on joukko tekstitilassa olevia paneeleita, joiden avulla käyttäjä voi rekisteröidä luodun MOK:n. Käyttäjä valitsee ”Enroll MOK” (Rekisteröi MOK), hänelle näytetään rekisteröitävän varmenteen sormenjälki ja häntä pyydetään vahvistamaan rekisteröinti. Vahvistuksen jälkeen uusi MOK syötetään laiteohjelmistoon ja käyttäjää pyydetään käynnistämään järjestelmä uudelleen.

Järjestelmän uudelleenkäynnistyksen yhteydessä äsken rekisteröidyn MOK:n allekirjoittamat kolmannen osapuolen ajurit ladataan tarpeen mukaan.

Käyttäjä päivittää UEFI-yhteensopivan Ubuntu-järjestelmän uuteen versioon, jossa järjestelmä vaatii kolmannen osapuolen ajureita

Päivityksessä shim ja shimin allekirjoittamat paketit päivitetään. Shim-signoidun paketin asennuksen jälkeiset tehtävät jatkavat uuden MOK:n luomista ja pyytävät käyttäjältä salasanaa, joka mainitaan selvästi vaadittavaksi, kun päivitysprosessi on suoritettu ja järjestelmä käynnistetty uudelleen.

Päivityksen aikana ytimen paketit ja kolmannen osapuolen moduulit päivitetään. Kolmannen osapuolen moduulit rakennetaan uudelleen uusia ytimiä varten ja niiden rakentamisen jälkeinen prosessi etenee niin, että ne allekirjoitetaan automaattisesti MOK:lla.

Päivityksen jälkeen käyttäjää suositellaan käynnistämään järjestelmä uudelleen.

Uudelleenkäynnistyksen yhteydessä käyttäjälle esitetään MokManager-ohjelma (osa asennettua shim-latausohjelmaa), joka on joukko tekstitilassa olevia paneeleja, joiden avulla käyttäjä voi rekisteröidä luodun MOK:n. Käyttäjä valitsee ”Enroll MOK” (Rekisteröi MOK), hänelle näytetään rekisteröitävän varmenteen sormenjälki ja häntä pyydetään vahvistamaan rekisteröinti. Käyttäjä saa myös kehotuksen ottaa Secure Boot -validointi uudelleen käyttöön (jos se on poistettu käytöstä), ja MokManager vaatii jälleen käyttäjältä vahvistuksen. Kun kaikki vaiheet on vahvistettu, shim-validointi otetaan uudelleen käyttöön, uusi MOK syötetään laiteohjelmistoon ja käyttäjää pyydetään käynnistämään järjestelmä uudelleen.

Järjestelmän uudelleenkäynnistyksen yhteydessä äsken kirjatun MOK:n allekirjoittamat kolmannen osapuolen ajurit ladataan tarpeen mukaan.

Kun järjestelmä on kaikissa tapauksissa käynnissä UEFI Secure Boot -toiminnon ollessa käytössä ja shimin viimeisimmän version ollessa käytössä; minkä tahansa uuden DKMS-moduulin (kolmannen osapuolen ohjaimen) asennus jatkuu rakennetun moduulin allekirjoittamiseksi MOK:lla. Tämä tapahtuu ilman käyttäjän väliintuloa, jos järjestelmässä on voimassa oleva MOK-avain, joka näyttää olevan jo rekisteröity.

Jos MOK:ia ei ole olemassa tai olemassa olevaa MOK:ia ei ole rekisteröity, uusi avain luodaan automaattisesti juuri ennen allekirjoittamista ja käyttäjää pyydetään rekisteröimään avain antamalla salasana, joka vaaditaan uudelleenkäynnistyksen yhteydessä.