Developer geeft Linux-bootloader voor secure boot vrij
Een voormalige softwaredeveloper van Red Hat heeft de Shim-bootloader vrijgegeven. Door deze bootloader in een Linux-distributie op te nemen, wordt het mogelijk om deze te installeren en te booten op systemen die secure boot gebruiken, bijvoorbeeld pc's met Windows 8.
De Shim-bootloader is ontwikkeld door developer Matthew Garrett. Shim maakt gebruik van een tweetraps-systeem: eerst wordt de Shim-bootloader gestart om vervolgens de second stage Grub2-bootloader in te laden. Daarbij is Shim voorzien van een handtekening die wordt geaccepteerd door een uefi met een ingeschakelde secure boot-functie waardoor Grub2 is te activeren.
Shim is volgens Garrett met name bedoeld voor Linux-distributies die niet het traject bij Microsoft willen doorlopen om een bootloader van de benodigde handtekening te voorzien. Ontwikkelaars kunnen de Shim-bootloader in een map op het installatiemedium plaatsen en deze van een eigen sleutel voorzien. Nadat de gebruiker deze sleutel bij het installatieproces heeft geaccepteerd, kan op een computer waarop secure boot is ingeschakeld de betreffende Linux-distributie geïnstalleerd worden.
Secure boot is een beveiligingsmechanisme voor het bootproces dat onder andere door Windows 8 wordt ondersteund. Linux-ontwikkelaars hebben zich in allerlei bochten moeten wringen om hun distributies zo aan te passen dat de bootloaders van de juiste handtekeningen zijn voorzien of om het secure boot-proces te omzeilen. Desondanks is het op pc's en laptops die secure boot ondersteunen mogelijk om deze feature in de uefi uit te schakelen.
Reacties (53)
Ben ik de enige die het hardcoden van sleutels in secure boot inherent onveilig vind? Die sleutel van Microsoft hoeft maar eenmaak gekraakt danwel gestolen te worden, en omdat al die zut in de BIOS zit, zal heel UEFI gelijk onderuit gaan...
Cool,
Maar persoonlijk heb ik denk ik toch een gewone tablet os op mijn tablets.
Tablets zijn voor mij persoonlijk een Consumer device en geen producer devices.
Dus producer ossen zoals een linux distro en win7 of win8 86x hebben voor mij niks te zoeken op devices.
Maar denk dat dit wel handig voor de surface tablets van microsoft met die keyboard sleeve.
Daar zie ik mensen nog wel wat op kunnen producen maar anders no thnx 7~10" is echt te klein om op te werken.
Maar persoonlijk heb ik denk ik toch een gewone tablet os op mijn tablets.
Tablets zijn voor mij persoonlijk een Consumer device en geen producer devices.
Dus producer ossen zoals een linux distro en win7 of win8 86x hebben voor mij niks te zoeken op devices.
Maar denk dat dit wel handig voor de surface tablets van microsoft met die keyboard sleeve.
Daar zie ik mensen nog wel wat op kunnen producen maar anders no thnx 7~10" is echt te klein om op te werken.
Zucht,
Heb even wat reacties gelezen en het staat (zoals gebruikelijk) bij dit onderwerp weer vol met FUD. En de Tweakers.net redactie zelf doet daar gezellig aan mee met opmerkingen als "Linux-ontwikkelaars hebben zich in allerlei bochten moeten wringen om hun distributies zo aan te passen dat de bootloaders van de juiste handtekeningen zijn voorzien of om het secure boot-proces te omzeilen"
Laat ik maar eens wat feiten noemen.
Niemand dwingt Linux distributies om Secure boot te gebruiken. Het is een keuze. En aangezien Secure boot gewoon een goede stap vooruit is een keuze die veel Linux distributies graag willen maken
Want wat is secure boot. Secure boot is een methode om af te dwingen dat een OS tijdens het boot proces enkel goede code uitvoert. Dit betekent dat Malware zich niet in het bootproces kan nestelen. Dit is goed voor elk OS (aangezien elk OS malware kan hebben) en betekent dat het verwijderen van die malware een stuk makkelijker wordt. Ik kan me goed voorstellen dat bedrijven gaan afdwingen dat al de door hun gebruikte computers secure boot gebruiken omdat het simpelweg een beveiligings risico wegneemt.
Dus Linux distributies willen Secure boot ook graag gebruiken. Dat levert problemen op. Want waar UEFI makers niet om Microsoft heen kunnen, is het landschap qua Linux distributies veel meer verdeeld. Met een sleutel voor Red Hat kan je nog geen Ubuntu of Slackware installeren. Ook is het zo dat iedere hercompilatie van de kernel met andere drivers weer een andere key gaat opleveren.
Dat probleem is echter inherent aan de linux gemeenschap en is natuurlijk niet direct een probleem voor Microsoft. Toch is er vanuit Microsoft meegedacht. Allereerst heeft men voor voor Intel systemen de eis toegevoegd dat Secure boot ook uitgeschakeld kan worden. Aangezien juist die intel systemen gebruikt worden voor alternatieve OSen en dit bij andere hardware platformen nauwelijks gebeurd (zie de iPad of je TV, beide bieden geen ondersteuning voor alternatieve OSen) is dit gewoon een goede stap. Oude OSen en custom kernels blijven dus bruikbaar.
Maar zoals gezegd ook Linux distributies willen graag gebruik maken van Secure boot. Echter is het voor Linux distributies veel lastiger om alle UEFI makers zo gek te krijgen kun key in het UEFI op te nemen. Men zou kunnen samenwerken via de linux stichting, of grote partijen als Red Hat zouden een poging kunnen wagen maar dat kost tijd, veel geld en inspanning. Ook hier is Microsoft behulpzaam. Voor een redelijk bedrag en onder bepaalde voorwaarden (vergelijkbaar met een SSL certificaat) kan je een key krijgen die getekend is met de Microsoft key die in alle UEFI's aanwezig is. Hiermee kunnen alle Linux distributies, maar ook BSD, Beos of je eigen OS gebruik maken van UEFI zonder bij alle UEFI fabrikanten langs te hoeven.
Dus kort gezegd.
1. Secure boot is goed.
2. Linux ontwikkelaars moeten helemaal niet gebruik maken van secure boot. Ze willen het echter wel graag.
3. Microsoft maakt het voor iedere OS bouwer mogelijk een OS te bouwen wat aan de regels voor secure boot voldoet
4. De kosten van een key via Microsoft zijn niet extreem hoog.
Mogelijk zal tweakers ooit een keer zelf een artikel schrijven over het hoe en waarom van secure boot. Tot die tijd kan ik alleen maar mijn hoofd schudden over al de paniekerige reacties en FUD die hier verspreid wordt.
Heb even wat reacties gelezen en het staat (zoals gebruikelijk) bij dit onderwerp weer vol met FUD. En de Tweakers.net redactie zelf doet daar gezellig aan mee met opmerkingen als "Linux-ontwikkelaars hebben zich in allerlei bochten moeten wringen om hun distributies zo aan te passen dat de bootloaders van de juiste handtekeningen zijn voorzien of om het secure boot-proces te omzeilen"
Laat ik maar eens wat feiten noemen.
Niemand dwingt Linux distributies om Secure boot te gebruiken. Het is een keuze. En aangezien Secure boot gewoon een goede stap vooruit is een keuze die veel Linux distributies graag willen maken
Want wat is secure boot. Secure boot is een methode om af te dwingen dat een OS tijdens het boot proces enkel goede code uitvoert. Dit betekent dat Malware zich niet in het bootproces kan nestelen. Dit is goed voor elk OS (aangezien elk OS malware kan hebben) en betekent dat het verwijderen van die malware een stuk makkelijker wordt. Ik kan me goed voorstellen dat bedrijven gaan afdwingen dat al de door hun gebruikte computers secure boot gebruiken omdat het simpelweg een beveiligings risico wegneemt.
Dus Linux distributies willen Secure boot ook graag gebruiken. Dat levert problemen op. Want waar UEFI makers niet om Microsoft heen kunnen, is het landschap qua Linux distributies veel meer verdeeld. Met een sleutel voor Red Hat kan je nog geen Ubuntu of Slackware installeren. Ook is het zo dat iedere hercompilatie van de kernel met andere drivers weer een andere key gaat opleveren.
Dat probleem is echter inherent aan de linux gemeenschap en is natuurlijk niet direct een probleem voor Microsoft. Toch is er vanuit Microsoft meegedacht. Allereerst heeft men voor voor Intel systemen de eis toegevoegd dat Secure boot ook uitgeschakeld kan worden. Aangezien juist die intel systemen gebruikt worden voor alternatieve OSen en dit bij andere hardware platformen nauwelijks gebeurd (zie de iPad of je TV, beide bieden geen ondersteuning voor alternatieve OSen) is dit gewoon een goede stap. Oude OSen en custom kernels blijven dus bruikbaar.
Maar zoals gezegd ook Linux distributies willen graag gebruik maken van Secure boot. Echter is het voor Linux distributies veel lastiger om alle UEFI makers zo gek te krijgen kun key in het UEFI op te nemen. Men zou kunnen samenwerken via de linux stichting, of grote partijen als Red Hat zouden een poging kunnen wagen maar dat kost tijd, veel geld en inspanning. Ook hier is Microsoft behulpzaam. Voor een redelijk bedrag en onder bepaalde voorwaarden (vergelijkbaar met een SSL certificaat) kan je een key krijgen die getekend is met de Microsoft key die in alle UEFI's aanwezig is. Hiermee kunnen alle Linux distributies, maar ook BSD, Beos of je eigen OS gebruik maken van UEFI zonder bij alle UEFI fabrikanten langs te hoeven.
Dus kort gezegd.
1. Secure boot is goed.
2. Linux ontwikkelaars moeten helemaal niet gebruik maken van secure boot. Ze willen het echter wel graag.
3. Microsoft maakt het voor iedere OS bouwer mogelijk een OS te bouwen wat aan de regels voor secure boot voldoet
4. De kosten van een key via Microsoft zijn niet extreem hoog.
Mogelijk zal tweakers ooit een keer zelf een artikel schrijven over het hoe en waarom van secure boot. Tot die tijd kan ik alleen maar mijn hoofd schudden over al de paniekerige reacties en FUD die hier verspreid wordt.
Ik vind je nogal erg positief.
Niemand dwingt de linux community af om secure boot te gebruiken. Echter het is wel MS die het product lanceert. Echter elke tekst verwerker wordt wel gedwongen om .doc te ondersteunen. Iets lanceren en tegelijk marktleider (monopoly positie hebben) zijn staat niet gelijk aan keuze vrijheid.
Het bedrag wat MS vraag zullen wel heel erg hoog zijn echter, worden linux distributies zeer regelmatig geüpgraded en zal er elke keer weer een nieuwe key aangevraagd moeten worden. Dit levert gewoon onnodige kosten en tijdsverlies op.
Het is een mooie oplossing om zo malware buiten te deur te houden, echter de implementatie van UEFI is verre van optimaal voor os-en zonder grote hoeveelheid geld en macht. Omdat MS het implementeert zal het wel weer een standaard worden...
Niemand dwingt de linux community af om secure boot te gebruiken. Echter het is wel MS die het product lanceert. Echter elke tekst verwerker wordt wel gedwongen om .doc te ondersteunen. Iets lanceren en tegelijk marktleider (monopoly positie hebben) zijn staat niet gelijk aan keuze vrijheid.
Het bedrag wat MS vraag zullen wel heel erg hoog zijn echter, worden linux distributies zeer regelmatig geüpgraded en zal er elke keer weer een nieuwe key aangevraagd moeten worden. Dit levert gewoon onnodige kosten en tijdsverlies op.
Het is een mooie oplossing om zo malware buiten te deur te houden, echter de implementatie van UEFI is verre van optimaal voor os-en zonder grote hoeveelheid geld en macht. Omdat MS het implementeert zal het wel weer een standaard worden...
waarom bestaat secureboot uberhaupt? (ik weet het echte antwoord wel, natuurlijk)
laten we hopen dat deze travestie toch alsjeblieft snel wordt afgeschaft...
laten we hopen dat deze travestie toch alsjeblieft snel wordt afgeschaft...
Nu snap ik helemaal niet meer wat secure boot inhoud, ik vond secureboot al klinken als een duistere toekomst maar blijkbaar kan je dus in princiepe nog alles draaien. Nogal vaag vind in dit
Als ik echter naar je icoontje kijk, werk je er al een tijdje mee! EFI (niet UEFI, immers, we wijken af van wat standaarden waardoor de U van Universal) zoals gebruikt op Mac's, beperkt ook een hoop. Een goed voorbeeld is hoe bootcamp als laag nodig is om andere OS-en te installeren omdat de EFI dicht zit. En bootcamp heeft beperkingen: je zit vast aan een BIOS-emulatie laag in plaats van dat je de EFI in mag. In feite valt bootcamp te zien als een virtuele bootloader die gecertificeerd is.
Wat heeft zo'n secure boot functie dan voor zin? Blijkbaar kan je dus een stukje software als eerste starten welke de secure boot accepteerd en daarna kan je alles starten wat het eigenlijk niet ondersteund? Lekker vage en nutteloze functie dan.
Tsja, dat is dus de kern van beveiligingscertificaten. Microsoft vertrekt die certificaten (en er zijn meer bedrijven), op een zelfde manier als Verisign certificaten kan verstrekken. Constateert de certificate authority (link: http://en.wikipedia.org/wiki/Certificate_authority) een abuse case in z'n certificaten, kan het certificaat ingetrokken. En zo kunnen er subcontractors ontstaan. Shim is dus zo'n subcontractor en die heeft z'n eigen voorwaarden. Dat gaat dus werken, TOTDAT er een keer misbruik is gezien. En op zo'n moment kan Microsoft het certificaat intrekken (Diginotar was op den duur ook nergens meer geldig), waardoor het niet meer werkt. Puur voor de veiligheid. Om dat te voorkomen hebben die subcontractors vaak een soort van kwaliteit/veiligheidssysteem, immers, je kredietwaardigheid verliezen is erg. Shim zou zowaar ooit een van die projecten kunnen zijn die commercieel gaat om voor alle OSS-OS-en van deze wereld de certificaten te verstrekken. Alleen reuzen als canonical kunnen dat misschien zelf maar de Mint's, Scientific Linuxes, en Fedora's van deze wereld moeten via Shim gaan.
Ik vind dit een erg goede ontwikkeling. Het idee van MS was om dit vanuit beveiligingsstandpunt te doen (toch?). Echter is het nu niet zo dat het hele idee van non authorised boots meteen overreden wordt?
Je kan secure boot toch gewoon in uefi uitzetten?
Op x86 is dat een verplichting van Microsoft om de hardware met Windows 8 te laten leveren. Op ARM hardware is het juist een verplichting om het aan te hebben en niet uit te laten zetten, iets wat op zichzelf net zo gangbaar is als andere ARM-based devices (de meeste ARM Linux devices die verkocht worden hebben ook een diep vergrendelde bootloader, zo'n beetje 60 á 70% van de smartphones is dat), en dus niet zo'n vreemde eis (men valt er toch over puur omdat het Microsoft is).
En dat maakt een gedeelte van de kritiek wel oprecht, immers, je ziet in de hele industrie dat er een soort van convergente evolutie is in use-cases van X86 en ARM hardware, zeker in userland, en in mindere mate in serverland (waar deze vraagstukken over secure boot een stuk minder). Echter waar MS als één van de certificatie autoriteiten nu onder vuur licht van de OSS community, zou de OSS community ook wel een duit in eigen zak mogen gooien: hoewel de Samsungs en HTC's van de wereld beter zijn geworden, zijn ze nog zeker zo slecht.
En dat maakt een gedeelte van de kritiek wel oprecht, immers, je ziet in de hele industrie dat er een soort van convergente evolutie is in use-cases van X86 en ARM hardware, zeker in userland, en in mindere mate in serverland (waar deze vraagstukken over secure boot een stuk minder). Echter waar MS als één van de certificatie autoriteiten nu onder vuur licht van de OSS community, zou de OSS community ook wel een duit in eigen zak mogen gooien: hoewel de Samsungs en HTC's van de wereld beter zijn geworden, zijn ze nog zeker zo slecht.
Het idee om überhaupt een traject bij Microsoft te moeten doorlopen om een OS werkend te kunnen krijgen is van de zotte. Denkt Microsoft nu het hele concept "PC" of het concept "laptop" te bezitten? Lijkt bijna Apple wel, die denken ook de uitvinder te zijn van smartphones en tablets. Dat soort dingen mogen netjes buiten Microsoft om.
Neen, maar de sleutel van MS is op dit moment één van de weinige die per default word meegeleverd binnen UEFI. MS is dus 1 van de weinige die de code kan ondertekenen en waarbij je zeker bent dat deze op alle secure boot apparaten zal werken.
Als het voor eigen gebruik is dan kan je, in principe, nog altijd je eigen sleutel aan je eigen UEFI install toevoegen, maar ik geloof dat moederbordmakers zelfs de mogelijkheid hebben om die optie uit te schakellen.
Als het voor eigen gebruik is dan kan je, in principe, nog altijd je eigen sleutel aan je eigen UEFI install toevoegen, maar ik geloof dat moederbordmakers zelfs de mogelijkheid hebben om die optie uit te schakellen.
Ook Ubuntu zal, waar systemen met Ubuntu verkocht worden, hun eigen key distribueren.
Je kan natuurlijk in het menu ook gewoon Secure Boot uitschakelen als je een Linux distro wilt gaan draaien, heb ik ook gedaan.
Dat zal op PC's prima werken, maar op embedded devices (bv. ARM tablets) die met Windows 8 voorgeïnstalleerd worden, laat Microsoft dat dus expliciet niet toe.Je kan natuurlijk in het menu ook gewoon Secure Boot uitschakelen als je een Linux distro wilt gaan draaien, heb ik ook gedaan.
Leuk, nu kunnen malware schrijvers die bootloader gebruiken om secure boot te omzeilen en toch bootkits te infecteren?
Malware-schrijvers, hobbyisten of Linux-kernel-bakkers. In weze dus iedereen die weer zelf de controle wil houden over welke code er in zijn boot-proces wordt uitgevoerd.Leuk, nu kunnen malware schrijvers die bootloader gebruiken om secure boot te omzeilen en toch bootkits te infecteren?
Infecteren van een ander boot-proces (zoals bijvoorbeeld dat van Windows) zal alleen niet gaan: Als een stuk malware daar de bootloader van verandert, zal de sleutel niet meer overeenkomen met wat het hoort te zijn. En het proces wat er verder achter zit tot aan de kernel van Windows is via dat hele Secure Boot-proces versleuteld.
Een vergelijkbaar proces zie je bijvoorbeeld bij de bootloader van de Nintendo Wii: Die draait versleuteld vanuit ROM, maar via een custom app kunnen we toch eigen code op de console uitvoeren. Infecteren van de originele boot-code in ROM is alleen niet mogelijk, want dan start de console gewoon niet meer op.
Nee. Deze bootloader boot alsnog alleen maar software die is ondertekend met een key van de Linux distro die de bootloader op je systeem heeft geinstalleerd, of als de gebruiker daar handmatig toestemming voor heeft gegeven in het boot menu.
Wat het artikel bedoeld is de mogelijkheid voor andere distributies om de versie van Fedora te gebruiken en te installeren, en dan hun eigen key aan die versie toe te voegen. Daarvoor is het echter noodzakelijk dat de gebruiker handmatig reboot, de key toevoegt en verder gaat met de installatie. Geen mogelijkheid om zonder dat het opgemerkt wordt malware te installeren dus.
Wat het artikel bedoeld is de mogelijkheid voor andere distributies om de versie van Fedora te gebruiken en te installeren, en dan hun eigen key aan die versie toe te voegen. Daarvoor is het echter noodzakelijk dat de gebruiker handmatig reboot, de key toevoegt en verder gaat met de installatie. Geen mogelijkheid om zonder dat het opgemerkt wordt malware te installeren dus.
[Reactie gewijzigd door hostname op 2 december 2012 14:07]
Deze bootloader maakt het dus juist mogelijk om self-signed keys uit te voeren via de UEFI secure-boot functie, niet alleen keys die uitgegeven zijn door Microsoft. De eindgebruiker zal ze wel expliciet toe moeten staan.En hoe makkelijk is het om een key van een Linux distro te bemachtigen? Juist ja.
Als je dus je eigen kernel of GRUB compileert zal de compiler er ook een key-file bij geven, die je bij de installatie van de nieuwe kernel/bootloader weer in deze Shim-bootloader kan stoppen.
Je moet dus wel in de gaten houden dat je niet blindelings keys toevoegt die je niet herkent, net zoals je dat bijvoorbeeld doet met je SSH-client.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
