HVA ER Uefi Sikker Oppstart?

UEFI Secure boot er en verifikasjonsmekanisme for å sikre at kode lansert av firmware er klarert. Riktig, sikker Bruk AV Uefi Secure Boot krever at hver binær lastet ved oppstart er validert mot kjente nøkler, plassert i fastvare, som angir klarerte leverandører og kilder for binærfilene, eller klarerte spesifikke binærfiler som kan identifiseres via kryptografisk hashing. De fleste x86-maskinvare kommer fra fabrikken forhåndsinstallert Med Microsoft-nøkler. Dette betyr at vi generelt kan stole på fastvaren på disse systemene for å stole på binærfiler som er signert Av Microsoft, og Linux-fellesskapet er sterkt avhengig av denne antakelsen for Sikker Oppstart for å fungere. Dette er den samme prosessen Som Brukes Av Red Hat OG SUSE, for eksempel. Mange ARM og andre arkitekturer støtter OGSÅ Uefi Secure Boot, men kan ikke forhåndsinnlastingsnøkler i fastvare. På disse arkitekturene kan det være nødvendig å signere oppstartsbilder med et sertifikat som er lastet i fastvare av eieren av maskinvaren.

Initial implementeringsplan: Implementeringsplan.

støttede arkitekturer

• amd64: en shim binær signert Av Microsoft og grub binær signert Av Canonical er gitt I Ubuntu hovedarkivet som shim-signert eller grub-efi-amd64-signert. arm64: Fra og med 20.04 (‘focal’), er en shim binær signert Av Microsoft og grub binær signert Av Canonical gitt I Ubuntu hovedarkiv som shim-signert eller grub-efi-arm64-signert. Det er EN GRUB bug under etterforskning som må løses før dette fungerer ende til ende.

Testing UEFI Secure Boot

hvis DU er interessert i å teste Secure Boot på systemet ditt, kan du se hvordan her: UEFI/SecureBoot / Testing.

HVORDAN UEFI Secure Boot fungerer På Ubuntu

På Ubuntu er alle forhåndsbygde binærfiler som er ment å bli lastet som en del av oppstartsprosessen, med unntak av initrd-bildet, signert Av Canonicals UEFI-sertifikat, som i seg selv er implisitt klarert ved å være innebygd i shim loader, selv signert Av Microsoft.

på arkitekturer eller systemer der forhåndsinnlastede signeringssertifikater Fra Microsoft ikke er tilgjengelige eller lastet inn i fastvare, kan brukerne erstatte de eksisterende signaturene på shim eller grub og laste dem som de ønsker, og verifisere mot egne sertifikater importert i systemets fastvare.

som systemet starter, laster firmware shim binær som angitt i firmware BootEntry variabler. Ubuntu installerer sin Egen Oppstart på installasjonstid og kan oppdatere den når GRUB bootloader er oppdatert. Siden shim binary er signert Av Microsoft; den er validert og akseptert av fastvaren når du verifiserer mot sertifikater som allerede finnes i fastvare. Siden shim binary bygger inn Et Kanonisk sertifikat, så vel som sin egen tillitsdatabase, kan ytterligere elementer i oppstartsmiljøet, i tillegg til å være signert av et av de akseptable sertifikatene som er forhåndsinnlastet i fastvare, signeres av Canonicals UEFI-nøkkel.

den neste tingen lastet av shim er det andre trinns bildet. Dette kan være en av to ting: ENTEN GRUB, hvis systemet starter opp normalt; eller MokManager, hvis nøkkelbehandling er nødvendig, som konfigurert av fastvarevariabler (vanligvis endret når systemet tidligere kjørte).

hvis oppstart normalt; GRUB binær (grub*.efi) er lastet og valideringen er forsøkt mot alle tidligere kjente klarerte kilder. GRUB binary For Ubuntu er signert Av Den Kanoniske uefi-nøkkelen, så den er vellykket validert og oppstartsprosessen fortsetter.

hvis oppstart for å fortsette med viktige ledelsesoppgaver, er mokmanager binær (mm*.efi) er lastet. Denne binære er eksplisitt klarert av shim ved å være signert av en flyktig nøkkel som bare eksisterer mens shim binær bygges. Dette betyr at Bare mokmanager binary bygget med en bestemt shim binary vil få lov til å kjøre og begrenser muligheten for kompromiss fra bruk av kompromitterte verktøy. MokManager tillater enhver bruker som er tilstede på systemkonsollen å registrere nøkler, fjerne klarerte nøkler, registrere binære hasher og veksle Sikker Oppstartsvalidering på shim-nivå, men de fleste oppgaver krever et tidligere angitt passord for å bekrefte at brukeren på konsollen faktisk er personen som ba om endringer. Slike passord overlever bare over en enkelt løp av shim / MokManager; og slettes så snart prosessen er fullført eller kansellert. Når nøkkelhåndteringen er fullført, startes systemet på nytt og fortsetter ikke bare med oppstart, siden nøkkelhåndteringsendringene kan være nødvendige for å fullføre oppstarten. NÅR systemet fortsetter å starte OPP TIL GRUB, LASTER GRUB-prosessen alle nødvendige konfigurasjoner (vanligvis laster konfigurasjon FRA ESP (EFI – Systempartisjonen), og peker til en annen konfigurasjonsfil på roten eller oppstartspartisjonen), som vil peke den til kjernebildet som skal lastes. EFI-applikasjoner opp til dette punktet har full tilgang til systemprogramvaren, inkludert tilgang til å endre klarerte fastvarevariabler, og kjernen som skal lastes, må også valideres mot klareringsdatabasen. Offisielle Ubuntu-kjerner blir signert Av Den Kanoniske uefi-nøkkelen, de er vellykket validert, og kontrollen overleveres til kjernen. Initrd-bilder er ikke validert.

når det gjelder uoffisielle kjerner, eller kjerner bygget av brukere, må det tas flere skritt hvis brukerne ønsker å laste inn slike kjerner samtidig som DE har full kapasitet TIL UEFI Secure Boot. Alle kjerner må være signert for å få lov til å laste AV GRUB når UEFI Secure Boot er aktivert, slik at brukeren må fortsette med sin egen signering. Alternativt kan brukere ønske å deaktivere validering i shim mens oppstart Med Secure Boot aktivert på en offisiell kjerne ved å bruke ‘sudo mokutil — disable-validation’, gi et passord når du blir bedt om det, og omstart; eller for å deaktivere Secure Boot i firmware helt.

opp til dette punktet, noen unnlatelse av å validere et bilde for å laste er møtt med en kritisk feil som stopper oppstartsprosessen. Systemet vil ikke fortsette oppstart, og kan automatisk starte på nytt etter en periode gitt at andre BootEntry-variabler kan inneholde oppstartsbaner som er gyldige og pålitelige. når de er lastet, vil validerte kjerner deaktivere fastvarens Oppstartstjenester, og dermed slippe privilegier og effektivt bytte til brukermodus; hvor tilgang til klarerte variabler er begrenset til skrivebeskyttet. Gitt de brede tillatelsene som gis til kjernemoduler, må enhver modul som ikke er innebygd i kjernen også valideres ved lasting. Moduler bygget og sendt Av Canonical med de offisielle kjernene er signert Av Canonical UEFI-nøkkelen, og som sådan er klarert. Spesialbygde moduler vil kreve at brukeren tar de nødvendige skritt for å signere modulene før de laster dem er tillatt av kjernen. Dette kan oppnås ved å bruke kommandoen ‘kmodsign’.

Usignerte moduler blir ganske enkelt nektet av kjernen. Ethvert forsøk på å sette dem inn med insmod eller modprobe vil mislykkes med en feilmelding. Gitt at mange brukere krever tredjepartsmoduler for at systemene skal fungere skikkelig eller for at enkelte enheter skal fungere; Og At disse tredjepartsmodulene krever å bygge lokalt på systemet som skal monteres på den løpende kjernen, Gir Ubuntu verktøy for å automatisere og forenkle signeringsprosessen.

Hvordan kan jeg gjøre ikke-automatisert signering av drivere?

Noen prosjekter kan kreve bruk av egendefinerte kjernedrivere som ikke er satt opp på en slik måte at de fungerer MED DKMS. I disse tilfellene bør folk benytte seg av verktøyene som er inkludert i den shim-signerte pakken: update-secureboot-policy-skriptet er tilgjengelig for å generere en ny MOK (hvis INGEN dkms-bygde moduler har utløst generering av en allerede).

Bruk følgende kommando for å registrere en eksisterende nøkkel i shim:

sudo update-secureboot-policy --enroll-key

hvis INGEN MOK eksisterer, vil skriptet avslutte med en melding til den effekten. Hvis nøkkelen allerede er registrert, vil skriptet gå ut, gjør ingenting. Hvis nøkkelen finnes, men den ikke vises å være registrert, vil brukeren bli bedt om et passord for å bruke etter omstart, slik at nøkkelen kan registreres.

man kan generere en ny MOK ved hjelp av følgende kommando:

sudo update-secureboot-policy --new-key

og registrer deretter den nylig genererte nøkkelen i shim med den tidligere nevnte kommandoen for den oppgaven. Kjernemoduler kan deretter signeres med kmodsign-kommandoen (se UEFI/SecureBoot / Signering) som en del av byggeprosessen.

sikkerhetsimplikasjoner i Maskineiernøkkeladministrasjon

MOK generert ved installasjonstid eller ved oppgradering er maskinspesifikk, og bare tillatt av kjernen eller shim å signere kjernemoduler, ved bruk av en bestemt KeyUsage OID (1.3.6.1.4.1.2312.16.1.2) som angir BEGRENSNINGENE TIL MOK. Siste shim-versjoner inkluderer logikk for å følge begrensningene i modul-signering-bare nøkler. Disse tastene vil få lov til å bli registrert i firmware i shim ‘ s trust database, men vil bli ignorert når shim eller GRUB validerer bilder som skal lastes inn i firmware. Shims verify () – funksjon vil bare validere bilder signert av nøkler som ikke inkluderer» Modul-signering bare » (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. Ubuntu-kjernene bruker global trust database (som inkluderer både shim og firmware) og vil akseptere noen av de medfølgende tastene som signeringsnøkler når du laster inn kjernemoduler. Gitt begrensningene på den automatisk genererte mok og det faktum at brukere med superbruker tilgang til systemet og tilgang til systemkonsollen for å skrive inn passordet som kreves når du registrerer nøkler allerede har høyt nivå tilgang til systemet; den genererte mok-nøkkelen holdes på filsystemet som vanlige filer eid av root med skrivebeskyttede tillatelser. Dette anses tilstrekkelig til å begrense tilgangen TIL MOK for signering av ondsinnede brukere eller skript, spesielt gitt at INGEN MOK eksisterer på systemet med mindre det krever tredjepartsdrivere. Dette begrenser muligheten for kompromiss fra misbruk av en generert MOK-nøkkel til å signere en ondsinnet kjernemodul. Dette tilsvarer kompromiss av userland-applikasjonene som allerede ville være mulig med superbruker tilgang til systemet, og sikring av dette er utenfor omfanget AV UEFI Secure Boot.

Tidligere systemer kan ha Hatt Sikker Oppstartsvalidering deaktivert i shim. Som en del av oppgraderingsprosessen vil disse systemene bli migrert for å aktivere Sikker Oppstartsvalidering i shim og registrere en ny mok-nøkkel når det er aktuelt.

mok-generering og signeringsprosess

nøkkelgenereringen og signeringsprosessen er litt annerledes basert på om vi har å gjøre med en helt ny installasjon eller en oppgradering av systemet som tidligere kjørte Ubuntu; disse to tilfellene er tydelig merket nedenfor.

I alle tilfeller, hvis systemet ikke starter opp I UEFI-modus, vil ingen spesielle kjernemodul signeringstrinn eller nøkkelgenerering skje.

Hvis Sikker Oppstart er deaktivert, SKJER fortsatt mok-generering og registrering, da brukeren senere kan aktivere Sikker Oppstart. De systemet skal fungere skikkelig hvis det er tilfelle.

brukeren installerer Ubuntu på et nytt system

brukeren går gjennom installasjonsprogrammet. Tidlig, når du forbereder deg på å installere og bare hvis systemet krever at tredjepartsmoduler skal fungere, blir brukeren bedt om et systempassord som er tydelig merket som nødvendig etter at installasjonen er fullført, og mens systemet blir installert, genereres en ny MOK automatisk uten ytterligere brukerinteraksjon.

tredjepartsdrivere eller kjernemoduler som kreves av systemet, bygges automatisk når pakken er installert, og byggeprosessen inkluderer et signeringstrinn. Signeringstrinnet bruker automatisk MOK generert tidligere for å signere modulen, slik at den umiddelbart kan lastes inn når systemet startes på nytt og MOK er inkludert i systemets klareringsdatabase. når installasjonen er fullført og systemet startes på nytt, ved første oppstart brukeren presenteres Med MokManager program (en del av den installerte shim loader), som et sett med tekst-modus paneler som alle brukeren å registrere den genererte MOK. Brukeren velger «Registrer MOK», vises et fingeravtrykk av sertifikatet for å registrere, og blir bedt om å bekrefte registreringen. Når bekreftet, vil den nye MOK bli lagt inn i firmware og brukeren vil bli bedt om å starte systemet på nytt.

når systemet starter på nytt, vil tredjepartsdrivere signert av MOK bare registrert bli lastet etter behov.

brukeren oppgraderer ET Uefi-aktivert Ubuntu-system til en ny utgave der systemet krever tredjepartsdrivere

ved oppgradering oppgraderes shim og shim-signerte pakker. Den shim-signerte pakkens etterinstallasjonsoppgaver fortsetter å generere en ny MOK, og ber brukeren om et passord som er tydelig nevnt som nødvendig når oppgraderingsprosessen er fullført og systemet startes på nytt.

under oppgraderingen oppgraderes kjernepakker og tredjepartsmoduler. Tredjepartsmoduler gjenoppbygges for de nye kjernene, og etterbyggingsprosessen fortsetter å signere dem automatisk med MOK.

etter oppgradering anbefales brukeren å starte systemet på nytt. ved omstart presenteres brukeren Med mokmanager-programmet (en del av den installerte shim loader), som et sett med tekstmoduspaneler som hele brukeren registrerer den genererte MOK. Brukeren velger «Registrer MOK», vises et fingeravtrykk av sertifikatet for å registrere, og blir bedt om å bekrefte registreringen. Brukeren er også presentert med en melding om å aktivere Secure Boot validering (i tilfelle det ble funnet å være deaktivert); Og MokManager igjen krever bekreftelse fra brukeren. Når alle trinnene er bekreftet, er shim validering reaktivert, den nye MOK vil bli lagt inn i firmware og brukeren vil bli bedt om å starte systemet på nytt.

når systemet starter på nytt, vil tredjepartsdrivere signert av MOK bare registrert bli lastet etter behov.

i alle tilfeller, når systemet kjører MED UEFI Secure Boot aktivert og en nyere versjon av shim; installasjonen av en ny DKMS-modul (tredjepartsdriver) vil fortsette å signere den innebygde modulen med MOK. Dette vil skje uten brukermedvirkning hvis en gyldig mok-nøkkel finnes på systemet og ser ut til å allerede være registrert.

hvis INGEN MOK eksisterer eller den eksisterende MOK ikke er registrert, opprettes en ny nøkkel automatisk like før signering, og brukeren blir bedt om å registrere nøkkelen ved å gi et passord som kreves ved omstart.