Door Anoniem: FOSS heeft geen oplossing....
Debian begon met het controleren van digitaal ondertekende checksums van geïnstalleerde bestanden (binaries, scripts en configuratie) 20 jaar voor secure boot werd geïntroduceerd. Wat dan wel weer jammer is dat ze voor die checksums nog steeds MD5 gebruiken, wat prima is om lees- en schrijffouten op te vangen maar niet meer voor gerichte aanvallen. Wet van de remmende voorsprong, maar ze liepen wel 20 jaar voor op Microsoft.
Microsoft wel, met TPM en keys in UEFI ben je gegarandeerd malware free in je bootsequence (anders boot ie niet)
Nee, er wordt niet op malware maar op digitale handtekeningen gecontroleerd. Als een leverancier zelf gecompromitteerd raakt en er malware in ondertekende bootsequence-binaries belandt dan worden die vrolijk uitgevoerd.
Ook is de bootsequence lang niet alles. Het is niet voor niets dat je nog steeds antivirussoftware op Windows nodig hebt, terwijl dat op een goede Linux-distro praktisch gesproken typisch geen donder toevoegt. De belangrijkste beveiligingsmaatregel is dat het een distributie is: een
gecontroleerde verzameling op elkaar afgestemde software die je uit maar een of enkele bronnen haalt.
Dat verkleint de kans op ellende substantieel. Al geeft het net als secure boot geen 100% garantie, het werkt in de praktijk heel goed.
De enige alternatieven met secure boot zijn Google producten (telefoons , tablets)
Of je moet gaan klooien met Coreboot, Dasharo en plugins zoals HEADS, wat maar op een paar moederborden werkt... Als je wil klooien met eeprom programmers that is...
Welke andere oplossing is er?
Er is iets grappigs met die boot sequence. Wist je dat de term BIOS (Basic Input/Output System) van CP/M afkomstig is, en daar niet iets in een geheugenchip op het moederbord was maar gewoon een onderdeel van het besturingssysteem dat (toen typisch) van een floppy werd geladen? Het is de IBM-pc geweest waar de BIOS naar een geheugenchip op het moederbord verhuisde, eerst ROM (die je uit de socket kon wippen om hem te vervangen), toen EPROM, later flash.
Het kan dus anders, en het gebeurt ook nog steeds. Bij de Raspberry Pi zit er geen BIOS op het moederbord, daar moet de eerste partitie op het micro-sd-kaartje (even uit mijn hoofd) FAT32 zijn, en daarop staat een generiek bestand met bootcode dat wordt geladen, en een hele reeks modelspecifieke bestanden waarvan de juiste daarna wordt geladen.
De eerste floppy disks zijn door IBM ontwikkeld, voor mainframes. Die dienden om tijdens het booten de microcode van de processoren te laden, de
instructieset van de processoren werd dus van floppy geladen tijdens het opstarten. Dat zegt iets over hoe weinig er in de hardware zelf moet zitten om toch te kunnen starten. In een latere ontwikkeling kreeg je mainframes waar een laptop in zat die het bootproces aanstuurde. En voor de duidelijkheid: dat zijn uitermate betrouwbare systemen. Iets te, misschien, malware
is (met zeer grote moeite) mogelijk, en de kans erop wordt vergroot omdat veel gebruikers ervan denken dat dat toch niet lukt.
De grap is dat je prima computers kan hebben zonder BIOS/UEFI-code op het moederbord, maar niet meer dan het minimum om iets te kunnen laden om verder mee op te starten. Dat minimum hoeft maar heel basaal en niet overschrijfbaar te zijn, zodat het moederbord zelf niet aangetast kan worden door malware. De rest van de code staat op een extern opslagmedium, en dat laat zich altijd controleren met code die weer van een ander opslagmedium komt.
Op basis daarvan zijn wel degelijk ook robuuste oplossingen te maken.
Microsoft en Google bieden verified boot, en FOSS loopt jaren achter (sinds 2017 ongeveer)
Jaren
voor juist, tientallen zelfs, met bij Debian wel weer de wet van de remmende voorsprong. In hoe dat bij RedHat en SuSe zit heb ik me nooit verdiept.
Maar hoe dan ook, besef dat secure boot vooral nodig is omdat het OS kennelijk toestaat dat het bootproces wordt aangepast. Kennelijk wordt niet die zwakte zelf maar een consequentie ervan aangepakt. Je kan je dan afvragen of secure boot niet een pleister op de verkeerde plaats is.
Er zijn vast wel weer aanmerkingen te maken op hoe ik het nu neerzet, maar het punt is dat er niet maar één manier is waarop je robuuste systemen kan maken, er zijn ook andere benaderingen mogelijk. Een fundamenteel bezwaar dat ik heb tegen secure boot is dat het een leverancier in een machtspositie plaatst ten opzichte van andere leveranciers. Microsoft heeft die machtspositie nooit misbruikt, maar de hele situatie zou niet moeten bestaan, en er zijn wel degelijk alternatieven voor mogelijk. Denk niet alleen aan wat nu de dominante opzet is, denk ook aan wat er
kan.