Lennart Poettering heeft een voorstel gepubliceerd voor de modernisering van het opstartproces van Linux-distributies, gericht op het oplossen van bestaande problemen en het vereenvoudigen van de organisatie van volledige geverifieerde opstartprocessen die de authenticiteit van de kernel en de basis systeemomgeving bevestigen. De noodzakelijke wijzigingen voor de implementatie van de nieuwe architectuur zijn al opgenomen in de codebasis van systemd en raken componenten zoals systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase en systemd-creds.
De voorgestelde wijzigingen komen neer op het creĆ«ren van een enkele universele UKI (Unified Kernel Image), die de Linux-kernel, een loader voor de kernel vanuit UEFI (UEFI boot stub) en de in het geheugen geladen systeemeisen initrd combineert die wordt gebruikt voor de initiĆ«le initialisatie vĆ³Ć³r het monteren van het root-bestandssysteem. In plaats van het RAM-schijfbeeld initrd kan de UKI ook het hele systeem bevatten, wat het mogelijk maakt om volledig geverifieerde systeemeisen te creĆ«ren die in het RAM kunnen worden geladen. Het UKI-beeld wordt gepresenteerd als een uitvoerbaar bestand in PE-formaat, dat niet alleen door middel van traditionele bootloaders kan worden geladen, maar ook rechtstreeks vanuit de UEFI-firmware kan worden aangeroepen.
De mogelijkheid om vanuit UEFI aan te roepen, maakt het mogelijk om integriteits- en authenticiteitscontroles door middel van digitale handtekeningen toe te passen, die niet alleen de kernel, maar ook de inhoud van initrd bestrijken. Tegelijkertijd stelt de ondersteuning voor oproepen vanuit traditionele bootloaders in staat om functionaliteiten zoals het aanbieden van meerdere versies van de kernel en automatische terugval naar de werkende kernel in geval van problemen met de nieuwe kernel na een update te behouden.
Op dit moment wordt in de meeste Linux-distributies in het initialisatieproces een keten gebruikt van 'firmware ā door Microsoft ondertekende shim-laag ā door de distributie ondertekende bootloader GRUB ā door de distributie ondertekende Linux-kernel ā niet-ondertekende initrd omgeving ā root-bestandssysteem'. Het ontbreken van verificatie van initrd in traditionele distributies creĆ«ert beveiligingsproblemen, aangezien er onder andere in deze omgeving sleutels voor het ontcijferen van het root-bestandssysteem worden geĆ«xtraheerd.
De verificatie van het initrd-beeld wordt niet ondersteund, omdat dit bestand op het lokale systeem van de gebruiker wordt gemaakt en niet kan worden ondertekend met een digitale handtekening van de distributie, wat de organisatie van de controle bij gebruik van de SecureBoot-modus aanzienlijk bemoeilijkt (om initrd te ondertekenen, moet de gebruiker zijn eigen sleutels genereren en deze in de UEFI-firmware uploaden). Bovendien staat de huidige opzet van het opstarten niet toe om informatie uit de TPM PCR-registers (Platform Configuration Register) te gebruiken voor de controle van de integriteit van de componenten in de gebruikersruimte, afgezien van shim, grub en de kernel. Tot de bestaande problemen behoort ook de complicatie van het bijwerken van de bootloader en het gebrek aan mogelijkheden om de toegang tot sleutels in TPM voor oudere versies van het besturingssysteem te beperken, die na de installatie van de update verouderd zijn geworden.
De belangrijkste doelen van de implementatie van de nieuwe opstartarchitectuur:
- Het bieden van een volledig geverifieerd opstartproces, dat alle stadia omvat van de firmware tot de gebruikersruimte, en de betrouwbaarheid en integriteit bevestigt van de te laden componenten.
- Het koppelen van gecontroleerde bronnen aan de TPM PCR-registers met splitsing op eigenaren.
- De mogelijkheid om vooraf de PCR-waarden te berekenen op basis van de gebruikte elementen bij het opstarten, zoals de kernel, initrd, configuratie en lokale systeemidentifier.
- Beveiliging tegen rollback-aanvallen die verband houden met het terugdraaien naar een eerdere kwetsbare versie van het systeem.
- Vereenvoudigen en verhogen van de betrouwbaarheid van updates.
- Ondersteuning voor besturingssysteemupdates die geen herhaling of lokale voorbereiding van resources, beveiligd door TPM, vereisen.
- Klaarheid van het systeem voor het uitvoeren van externe attestatie ter bevestiging van de correctheid van het opstartende besturingssysteem en instellingen.
- De mogelijkheid om vertrouwelijke gegevens aan specifieke fasen van de opstart te koppelen, zoals het extraheren van versleutels uit de TPM voor het rootbesturingssysteem.
- Het bieden van een veilig, automatisch en gebruiksvriendelijk ontgrendelingsproces van sleutels voor de decryptie van de schijf met de rootpartitie.
- Gebruik van chips die de TPM 2.0-specificatie ondersteunen, met de mogelijkheid om terug te vallen op systemen zonder TPM.
Bron: opennet.ru
