mikä on UEFI Secure Boot?

UEFI Secure boot on varmistusmekanismi, jolla varmistetaan, että firmwaren käynnistämä koodi on luotettava.

UEFI Secure Boot-toiminnon asianmukainen, turvallinen käyttö edellyttää, että jokainen käynnistyksessä ladattu binääri validoidaan laiteohjelmistossa sijaitsevia tunnettuja avaimia vastaan, jotka ilmaisevat binäärien luotettuja toimittajia ja lähteitä, tai luotettuja erityisiä binäärejä, jotka voidaan tunnistaa kryptografisella hajautuksella.

suurin osa x86-laitteistosta tulee tehtaalta valmiiksi ladattuna Microsoftin näppäimillä. Tämä tarkoittaa, että voimme yleensä luottaa näiden järjestelmien firmwareen luottamaan binääreihin, jotka Microsoft on allekirjoittanut,ja Linux-yhteisö luottaa vahvasti tähän olettamukseen turvallisesta käynnistyksestä. 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ä ole esilatausnäppäimiä firmwaressa. Näissä arkkitehtuureissa voi olla tarpeen allekirjoittaa käynnistyskuvia uudelleen varmenteella, jonka laitteiston omistaja on ladannut laiteohjelmistoon.

Alkuperäinen toteutussuunnitelma: toteutussuunnitelma.

tuetut arkkitehtuurit

• amd64: Ubuntun pääarkistossa on Microsoftin signeeraama shim-binary ja Canonicalin signeeraama grub-binary Shim-signeerattuna tai grub-efi-amd64-signeerattuna.

arm64: 20.04 (”focal”) alkaen Ubuntun pääarkistossa on Microsoftin allekirjoittama shim-binary ja Canonicalin allekirjoittama grub-binary Shim-signed tai grub-efi-arm64-signed. Tutkinnassa on RAIVAUSVIRHE, joka on ratkaistava ennen kuin tämä toimii päästä päähän.

Testing UEFI Secure Boot

Jos olet kiinnostunut testaamaan Secure bootia järjestelmässäsi, katso ohjeet tästä: UEFI/SecureBoot / Testing.

miten UEFI Secure Boot toimii Ubuntussa

Ubuntussa, kaikki valmiiksi rakennetut binäärit, jotka on tarkoitus ladata osana käynnistysprosessia, initrd-kuvaa lukuun ottamatta, on allekirjoitettu Canonicalin UEFI-sertifikaatilla, joka itsessään on implisiittisesti luotettu olemalla upotettuna Shim loaderiin, joka on itse Microsoftin allekirjoittama.

sellaisissa arkkitehtuureissa tai järjestelmissä, joissa Microsoftin valmiiksi ladattuja allekirjoitusvarmenteita ei ole saatavilla tai jotka on ladattu laiteohjelmistossa, käyttäjät voivat korvata olemassa olevat allekirjoitukset shim-tai grub-järjestelmässä ja ladata ne haluamallaan tavalla tarkistaen ne järjestelmän laiteohjelmistossa tuotuja omia varmenteitaan vastaan.

järjestelmän käynnistyessä firmware lataa Shim-binäärin firmware BootEntry-muuttujien mukaisesti. Ubuntu asentaa oman BootEntry asennuksen aikana ja voi päivittää sitä milloin tahansa GRUB bootloader päivitetään. Koska shim binary on allekirjoittanut Microsoft; laiteohjelmisto vahvistaa ja hyväksyy sen, kun laiteohjelmistossa jo olevia varmenteita tarkistetaan. Koska Shim binary upottaa kanonisen varmenteen sekä Oman luottamustietokantansa, sen lisäksi, että se on allekirjoitettu jollakin hyväksyttävistä varmenteista, jotka on ladattu valmiiksi firmwareen, se voidaan allekirjoittaa Canonicalin UEFI-avaimella.

seuraava Shimin lataama juttu on toisen vaiheen kuva. Tämä voi olla jompikumpi kahdesta asiasta: joko raivaus, jos järjestelmä käynnistyy normaalisti; tai MokManager, jos avaimen hallinta on tarpeen, kuten konfiguroitu firmware muuttujia (yleensä muutettu, kun järjestelmä oli aiemmin käynnissä).

jos käynnistetään normaalisti; GRUB binary (grub*.efi) Ladataan ja sen validointia yritetään tehdä kaikkia aiemmin tunnettuja luotettuja lähteitä vastaan. Ubuntun GRUB-binary on allekirjoitettu Kanonisella UEFI-avaimella, joten se on onnistuneesti validoitu ja käynnistysprosessi jatkuu.

jos käynnistetään etenemään avainhallintatehtävissä, MokManager-binääri (mm*.efi) on ladattu. Shim luottaa tähän binääriin nimenomaan siten, että se on allekirjoitettu lyhytaikaisella avaimella, joka on olemassa vain Shimin binääriä rakennettaessa. Tämä tarkoittaa, että vain MokManager binary rakennettu tietyllä shim binary saa ajaa ja rajoittaa mahdollisuutta kompromissi käytöstä vaarantunut työkaluja. MokManager sallii kenen tahansa järjestelmäkonsolissa läsnä olevan käyttäjän rekisteröidä avaimia, poistaa luotettuja avaimia, rekisteröidä binääriviivoja ja vaihtaa suojatun käynnistyksen vahvistuksen shim-tasolla, mutta useimmat tehtävät edellyttävät aiemmin asetettua salasanaa vahvistaakseen, että käyttäjä konsolilla on todellakin henkilö, joka pyysi muutoksia. Tällaiset salasanat säilyvät vain yhdellä Shim / MokManager-komennolla, ja ne tyhjennetään heti, kun prosessi on saatu päätökseen tai peruutettu. Kun avainten hallinta on valmis, järjestelmä käynnistetään uudelleen, eikä se vain jatka käynnistämistä, koska avainten hallinnan muutokset saattavat olla tarpeen käynnistämisen onnistumiseksi.

kun järjestelmä jatkaa käynnistystä grubiin, GRUB-prosessi lataa kaikki vaaditut asetukset (yleensä ladataan asetukset ESP: stä (EFI-järjestelmäosio), osoittaen toista konfiguraatiotiedostoa root-tai boot-osion päällä), joka osoittaa sen ladattavaan ydinkuvaan.

tähän asti EFI-sovellukset, joilla on täysi pääsy järjestelmän laiteohjelmistoon, mukaan lukien mahdollisuus muuttaa luotettuja laiteohjelmistomuuttujia, ladattavan ytimen on myös oltava validoitu luottamustietokantaa vastaan. Viralliset Ubuntu-ytimet on allekirjoitettu Kanonisella UEFI-avaimella, ne validoidaan onnistuneesti ja ohjaus luovutetaan ytimelle. Initrd-kuvia ei ole vahvistettu.

Jos kyseessä ovat epäviralliset ytimet tai käyttäjien rakentamat ytimet, on toteutettava lisätoimenpiteitä, jos käyttäjät haluavat ladata tällaisia ytimiä säilyttäen samalla UEFI Secure Boot-ohjelman täydet ominaisuudet. Kaikki ytimet on allekirjoitettava, jotta GRUB voi ladata ne, kun UEFI Secure Boot on käytössä, joten käyttäjä vaatii jatkamaan omaa allekirjoitustaan. Vaihtoehtoisesti, käyttäjät voivat haluta poistaa validointi shim kun käynnistetään Secure Boot käytössä virallisessa ytimen käyttämällä ’sudo mokutil — disable-validation’, tarjoamalla salasanan pyydettäessä, ja uudelleenkäynnistys; tai poistaa Secure Boot firmware kokonaan.

tähän mennessä, jos lataavan kuvan validointi ei onnistu, tulee vastaan kriittinen virhe, joka pysäyttää käynnistysprosessin. Järjestelmä ei jatka käynnistämistä, ja se voi automaattisesti käynnistyä uudelleen tietyn ajan kuluttua, koska muut Käynnistysmuuttujat voivat sisältää käynnistyspolkuja, jotka ovat kelvollisia ja luotettavia.

kun Validoidut ytimet on ladattu, ne poistavat laiteohjelmiston Käynnistyspalvelut käytöstä, jolloin käyttöoikeudet poistuvat ja siirrytään tehokkaasti käyttäjätilaan, jossa luotettujen muuttujien käyttö on rajoitettu vain lukemiseen. Koska ytimen moduuleille on annettu laajat oikeudet, myös kaikki moduulit, joita ei ole rakennettu ytimeen, on validoitava ladattaessa. Canonicalin virallisten ytimien kanssa rakentamat ja toimittamat moduulit on allekirjoitettu Kanonisella UEFI-avaimella ja sellaisina niihin luotetaan. Räätälöidyt moduulit vaativat käyttäjän tekemään tarvittavat toimenpiteet moduulien allekirjoittamiseksi ennen kuin ydin sallii niiden lataamisen. Tämä voidaan saavuttaa käyttämällä komentoa ”kmodsign”.

allekirjoittamattomat moduulit yksinkertaisesti hylätään ytimen toimesta. Kaikki yritykset lisätä ne insmod tai modprobe epäonnistuu virheilmoituksen.

ottaen huomioon, että monet käyttäjät tarvitsevat kolmannen osapuolen moduuleja järjestelmiensä toimivuuteen tai joidenkin laitteiden toimivuuteen; ja että nämä kolmannen osapuolen moduulit vaativat paikallisen rakentamisen järjestelmään, joka asennetaan käynnissä olevaan ytimeen, Ubuntu tarjoaa työkalut allekirjoitusprosessin automatisoimiseksi ja yksinkertaistamiseksi.

Miten voin tehdä ajurien ei-automaattisen allekirjoituksen?

jotkut projektit saattavat vaatia sellaisten mukautettujen ytimen ajurien käyttöä, joita ei ole määritetty siten, että ne toimisivat DKMS: n kanssa. Näissä tapauksissa ihmisten tulisi käyttää Shim-signed-pakettiin sisältyviä työkaluja: update-secureboot-policy script on käytettävissä uuden MOK: n luomiseen (jos yksikään dkms-moduuleista ei ole jo käynnistänyt sellaisen luomista).

käytä seuraavaa komentoa kirjataksesi olemassa olevan avaimen shimiin:

sudo update-secureboot-policy --enroll-key

Jos mokia ei ole, skripti poistuu viestillä. Jos avain on jo kirjoilla, skripti poistuu tekemättä mitään. Jos avain on olemassa, mutta sitä ei ole merkitty, käyttäjältä kysytään salasanaa uudelleenkäynnistyksen jälkeen, jotta avain voidaan rekisteröidä.

voidaan luoda uusi MOK käyttämällä seuraavaa komentoa:

sudo update-secureboot-policy --new-key

ja sitten kirjata uudelleen luotu avain shimiin aiemmin mainitulla komennolla kyseistä tehtävää varten.

ytimen moduulit voidaan allekirjoittaa kmodsign-komennolla (Katso UEFI/SecureBoot / Signing) osana niiden rakentamisprosessia.

turvallisuusvaikutukset koneen omistajan avaimen hallinnassa

asennuksen tai päivityksen yhteydessä luotu MOK on konekohtainen, ja vain ydin tai shim sallii ydinmoduulien allekirjoittamisen käyttämällä erityistä Avainmoduulia OID (1.3.6.1.4.1.2312.16.1.2), joka ilmaisee MOK: n rajoitukset.

viimeaikaisissa shim-versioissa on logiikkaa, jolla voi seurata vain moduulien allekirjoitusavainten rajoituksia. Nämä avaimet saavat olla kirjoilla firmwaressa Shimin luottamustietokannassa, mutta ne jätetään huomiotta, kun shim tai GRUB vahvistaa kuvien lataamisen firmwareen. Shimin verify ()-toiminto vahvistaa onnistuneesti vain sellaisten avainten allekirjoittamat kuvat, jotka eivät sisällä ”Module-signing only” (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. Ubuntu-ytimet käyttävät global trust-tietokantaa (joka sisältää sekä Shimin että laiteohjelmiston) ja hyväksyvät minkä tahansa mukana olevista avaimista allekirjoitusavaimiksi ladattaessa ydinmoduuleja.

kun otetaan huomioon automaattisesti luodulle MOK: lle asetetut rajoitukset ja se, että käyttäjillä, joilla on pääkäyttäjän pääsy järjestelmään ja pääsy järjestelmäkonsoliin syöttämään avainten rekisteröintiin vaadittava salasana, on jo korkean tason pääsy järjestelmään; luotu MOK-avain pidetään tiedostojärjestelmässä tavallisina root: n omistamina tiedostoina, joilla on vain luku-oikeudet. Tätä pidetään riittävänä rajoittamaan Mok: n käyttöä haitallisten käyttäjien tai skriptien allekirjoittamista varten, erityisesti kun otetaan huomioon, että järjestelmässä ei ole MOK: ia, ellei se edellytä kolmannen osapuolen ajureita. Tämä rajoittaa mahdollisuutta kompromissiin syntyneen MOK-avaimen väärinkäytöstä haitallisen ytimen moduulin allekirjoittamiseen. Tämä vastaa UserLand-sovellusten kompromissia, joka olisi jo mahdollista pääkäyttäjän pääsyn avulla järjestelmään, ja tämän varmistaminen ei kuulu UEFI Secure Boot-järjestelmän piiriin.

aiemmissa järjestelmissä on saattanut Shim-järjestelmässä olla Secure Boot-validointi pois käytöstä. Osana päivitysprosessia nämä järjestelmät siirretään mahdollistamaan suojatun käynnistyksen uudelleen validointi shim-järjestelmässä ja rekisteröimään Uusi MOK-avain soveltuvin osin.

MOK generation and signing process

key generation and signing process on hieman erilainen sen perusteella, onko kyseessä upouusi asennus vai Ubuntussa aiemmin toimineen järjestelmän päivitys; nämä kaksi tapausta on selvästi merkitty alla.

kaikissa tapauksissa, jos järjestelmä ei käynnisty UEFI-tilassa, erityisiä ydinmoduulin allekirjoitusvaiheita tai avaimen luomista ei tapahdu.

Jos Secure Boot on poistettu käytöstä, MOK generation ja rekisteröinti tapahtuu edelleen, koska käyttäjä voi myöhemmin ottaa Secure Boot. Niiden järjestelmän pitäisi toimia asianmukaisesti, jos näin on.

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

käyttäjä astuu asentajan läpi. Varhaisessa vaiheessa, kun valmistaudutaan asentamaan ja vain jos järjestelmä vaatii kolmannen osapuolen moduuleja toimimaan, käyttäjältä pyydetään järjestelmän salasanaa, joka on selvästi merkitty vaadittavaksi asennuksen päätyttyä, ja kun järjestelmää asennetaan, uusi MOK luodaan automaattisesti ilman käyttäjän vuorovaikutusta.

järjestelmän vaatimat kolmannen osapuolen ajurit tai ytimen moduulit rakennetaan automaattisesti, kun paketti on asennettu, ja rakentamisprosessi sisältää allekirjoitusvaiheen. Allekirjoitusvaihe käyttää moduulin allekirjoittamiseen automaattisesti aiemmin luotua MOK: ia siten, että se voidaan ladata välittömästi, kun järjestelmä on käynnistetty uudelleen ja MOK on sisällytetty järjestelmän luottamustietokantaan.

kun asennus on valmis ja järjestelmä käynnistetään uudelleen, ensimmäisessä käynnistyksessä käyttäjälle esitetään MokManager-ohjelma (osa asennettua shim-lataajaa), joukko tekstitilapaneeleita, jotka kaikki käyttäjä rekisteröi luotu MOK. Käyttäjä valitsee ”ilmoittautua MOK”, näytetään sormenjälki varmenteen ilmoittautua, ja pyydetään vahvistamaan ilmoittautuminen. Vahvistuksen jälkeen uusi MOK syötetään firmwareen ja käyttäjää pyydetään käynnistämään järjestelmä uudelleen.

kun järjestelmä käynnistyy uudelleen, juuri ilmoittautuneen MOK: n allekirjoittamat kolmannen osapuolen ajurit ladataan tarpeen mukaan.

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

päivitettäessä shim-ja shim-allekirjoitetut paketit päivitetään. Shim-allekirjoitetun paketin Asennuksen jälkeiset tehtävät etenevät luomaan uuden Mokin ja pyytävät käyttäjältä salasanaa, joka on selvästi mainittu vaadittavaksi, kun päivitysprosessi on päättynyt ja järjestelmä käynnistetty uudelleen.

päivityksen aikana ytimen paketit ja kolmannen osapuolen moduulit päivittyvät. Kolmannen osapuolen moduulit rakennetaan uudelleen uusille ytimille, ja niiden Rakentamisen jälkeinen prosessi etenee automaattisesti allekirjoittamaan ne MOK: lla.

päivityksen jälkeen käyttäjän suositellaan käynnistävän järjestelmänsä uudelleen.

uudelleenkäynnistyksessä käyttäjälle esitetään MokManager-ohjelma (osa asennetusta shim-lataajasta), joukko tekstitilapaneeleita, jotka kaikki käyttäjä rekisteröivät luodun MOK: n. Käyttäjä valitsee ”ilmoittautua MOK”, näytetään sormenjälki varmenteen ilmoittautua, ja pyydetään vahvistamaan ilmoittautuminen. Käyttäjälle esitetään myös kehote, jolla Turvallinen käynnistys validointi otetaan uudelleen käyttöön (siinä tapauksessa, että se todettiin poistetuksi käytöstä); ja MokManager vaatii jälleen vahvistuksen käyttäjältä. Kun kaikki vaiheet on vahvistettu, shim-validointi otetaan uudelleen käyttöön, uusi MOK syötetään firmwareen ja käyttäjää pyydetään käynnistämään järjestelmä uudelleen.

kun järjestelmä käynnistyy uudelleen, juuri ilmoittautuneen MOK: n allekirjoittamat kolmannen osapuolen ajurit ladataan tarpeen mukaan.

kaikissa tapauksissa, kun järjestelmä on käynnissä UEFI Secure Boot käytössä ja Shim: n tuore versio; minkä tahansa uuden dkms-moduulin (kolmannen osapuolen ajuri) asennus siirtyy allekirjoittamaan rakennettu moduuli MOK: lla. Tämä tapahtuu ilman käyttäjän vuorovaikutusta, jos järjestelmässä on voimassa oleva Mok-avain, joka näyttää jo olevan kirjoilla.

Jos mokia ei ole tai olemassa olevaa mokia 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ä.