Canonical komt met eigen sleutel en bootloader voor secure boot

Canonical heeft aangekondigd dat het in toekomstige Ubuntu-versies het uefi secure boot-mechanisme zal ondersteunen. Daarvoor zal het een eigen Ubuntu-handtekening introduceren samen met een bootloader die Grub2 zal vervangen.

In een update op een eerdere posting op het Canonical-blog beschrijft de Ubuntu-ontwikkelaar zijn plannen ten aanzien van de secure boot-functie, een onderdeel van de uefi-specificatie en tevens een omstreden beveiligingsfeature van Windows 8. Het bedrijf, dat onderdeel uitmaakt van het UEFI Forum, stelt dat het er naar streeft om het Ubuntu-besturingssysteem zo 'soepel mogelijk' te laten samenwerken met pc's en laptops die secure boot ingeschakeld hebben. Ook laat Canonical weten dat het hiervoor een eigen Ubuntu-handtekening wil introduceren en dat er een speciale bootloader zal worden uitgebracht.

Op de Ubuntu developer-mailinglist gaat Canonical dieper in op de gekozen implementatie. Zo zal Grub2, de traditionele bootloader van de laatste Ubuntu-releases, voor secure boot-systemen worden vervangen door de Efilinux-loader van Intel. Canonical zegt deze keuze gemaakt te hebben omdat Grub2 onder de GPLv3-licentie valt en dat hierdoor de kans bestaat dat zijn secure boot-sleutel gepubliceerd zal worden. Mocht dit gebeuren, dan zal deze handtekening ongeldig worden verklaard. Verder werd de code van Grub als te gedateerd bestempeld.

Canonical meldt verder dat alleen de binaries van de bootloader van een Ubuntu-handtekening voorzien hoeven worden. Hierdoor blijft het voor gebruikers mogelijk om zelf kernels te compileren en om de propriëtaire drivers van Nvidia en AMD te gebruiken. Met deze methode is Canonical minder strikt dan de secure boot-implementatie die Red Hat met Fedora voor ogen heeft.

Tenslotte zal Canonical het verplicht stellen voor fabrikanten die hardware met Ubuntu leveren om de benodigde sleutel in de uefi op te nemen. Ook hoopt het bedrijf dat er op termijn een alternatief komt voor Microsofts signing-dienst, maar over deze kwestie heerst nog veel onduidelijkheid.

Reacties (84)

[Fuzzillogic]

Canonical meldt verder dat alleen de binaries van de bootloader van een Ubuntu-handtekening voorzien hoeven worden

Feit blijft dus nog steeds dat je als eigenaar van een apparaat niet de controle hebt over de keys die jouw eigen apparaat accepteert als veilig.

Secure boot, TPM etc zijn mooi technieken mits je je eigen keys kunt toevoegen en bestaande keys kunt verwijderen. Zolang dat niet kan: DO NOT WANT.

[jiriw]

Dat is inderdaad een probleem. Prima dat Redhat, Ubuntu e.d. eigen keys maken en aanbieden aan moederbordfabrikanten zodat deze ze in de UEFI kunnen opnemen maar voor de 'from scratch' en 'andere/kleinere distro' gebruikers hebben daar dus niets aan. Ook vraag ik me af wat de effectiviteit is van een security chain die maar tot de kernel gaat. Goed... je hebt een bootloader waarbij je zeker weet dat 'ie niet gecompromitteerd is door een rootkit o.i.d. Maar als je eigen kerneldrivers kan laden/kernel kan compileren, is dat evengoed een aanvalsvector voor malware/rootkits tenzij je je werk aan de sleutel kan koppelen; wat dus weer niet kan omdat je nooit de private kant van die keys zal krijgen. Als dat wel zo zou zijn kunnen malwaremakers hun eigen code signeren wat het hele concept teniet doet.

De enige manier om echt iets nuttigs met een versleutelde code chain en UEFI te doen is als individuele gebruikers hun eigen sleutels kunnen maken en hun zelf gekozen / eigen gecompileerde code kunnen signeren en zo de secure software chain zo lang kunnen maken als ze mogelijk kunnen. Iedere andere vorm in non-proprietary OS software is een slecht compromis. (In proprietary software kan de leverancier van het OS het hele versleutelingsproces beheren natuurlijk. Dan hoef je er als gebruiker niet bij te kunnen... zolang je, je OS leverancier maar vertrouwt.)

Een mogelijke oplossing kan zijn als Ubuntu/Redhet een tool beschikbaar stellen die sleutels van een gebruiker valideert in de bootloader. De bootloader wordt veilig gehouden met een sleutel in het UEFI, de bootloader of een applicatie die door de bootloader wordt gestart en onderdeel is van de eerste security chain neemt de security chain over en valideert alles daarboven met eigen sleutels die aanpasbaar zijn door gebruikers. Dan kan je alsnog een secure chain opbouwen van UEFI helemaal naar user apps als je zou willen. Maar ik weet niet of daar in de standaarden rekening mee is gehouden....

[Reactie gewijzigd door jiriw op 25 juli 2024 07:19]

[Dreamvoid]

Kan wel, maar dan leg je de security verantwoordelijkheid weer bij de miljoenen gebruikers, die i.h.a. niet precies weten wat ze doen. Als iedereen zijn eigen lokale source gaat compileren, hoe ga je dan voorkomen dat kwaadwillenden de sources gaan infecteren met rootkits, die de gebruiker dan nietsvermoedend meecompileert en signed met zijn eigen sleuteltje?

Je gaat langzaamaan naar een situatie waar het grote publiek een verified Linux distro draait, en developers die zonder beveiligingschecks op low-level aan de kernel willen sleutelen actief secure boot moeten uitzetten. Voor de belangrijkste Linux distributeurs (Google, IBM, Oracle, Red Hat, Canonical, Novell), die ook de grootste contributeurs aan code zijn, is dit een best zinnige setup.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 07:19]

[jiriw]

En dat is dus een situatie die ik niet zou willen, en ik denk met mij veel systeembeheerders ook niet. Stel, je draait als bedrijf zeer aangepastte eigen OS software (voorbeeld: Google datacenters). Als je een secure chain wil opbouwend dan wil je je eigen secure chain opbouwen. Niet een opgelegd door iemand die toevallig een plekje heeft weten te bemachtigen in de key table van de UEFI van jouw favoriete moederbordfabrikant.

Nu zal Google er wel een weg omheen weten; ik zie ze zeer wel in staat hun eigen key door hun hardwareleveranciers opgenomen te krijgen in de hardware die hen geleverd wordt, als ze sowieso secure boot willen. Maar het idee is natuurlijk dat er miljoenen andere bedrijven/bedrijfjes/systeembeheerders/hobbyisten/personen zijn die om wat voor een reden dan ook een eigen secure chain willen bouwen.

[Reactie gewijzigd door jiriw op 25 juli 2024 07:19]

[Dreamvoid]

Als miljoenen mensen voor zichzelf hun eigen security validatie doen, wat is die validatie dan nog waard?

[jiriw]

Heel veel... voor de mensen die de security validatie in eigen hand willen houden. Ieder ander heeft er geen last van en kan vrolijk de sleutels van een door hun vertrouwde software leverancier gebruiken. De sleutels van Pietje's PC komen niet automagisch op Jantje's PC terecht hoor. Het is heel goed mogelijk de UEFI software zo uit te breiden dat er alleen sleutels in komen die de gebruiker er in wil hebben. De UEFI software kan zichzelf namelijk valideren aan de hand van z'n eigen sleutels en zo ook de invoer van nieuwe sleutels vertrouwd laten verlopen.

We hebben het hier over het vertrouwen van hard/software in eigen beheer. Daarvoor volstaan self-signed keys uitstekend. Het is niet zo dat iemand anders jouw sleutels moet vertrouwen. Alleen jijzelf (of de mensen die afhankelijk zijn van jou, zoals in een bedrijfssituatie).

Tenzij je natuurlijk over DRM praat en het niet spelen van audiovisuele media en software op niet-gecertificeerde systemen. Dan moet opeens de entertainmentindustrie / gelicenseerde softwareindustrie alle sleutels in het UEFI kunnen vertrouwen (kunnen ze nog alles uitsluiten wat niet expliciet overeenkomt met hun eigen lijstje van vertrouwde OS-sen, hoor).... Maar tot nu toe kwam dat bij mij niet eens in mijn gedachte op.... Het ging mij alleen om het kunnen starten van OS en applicaties op een manier die rootkits/virussen/malware uitsluit.

[MadEgg]

Dat je wel gewaarschuwd wordt als een stuk malware aan je zelfgebouwde kernel heeft zitten prutsen waardoor de ondertekening niet meer klopt.

Het principe kan ik wel waarderen, maar je moet inderdaad zelf de mogelijkheid krijgen om te zeggen welke sleutels je wel en niet vertrouwd. Krijg ik die keuze niet dan zal ik het niet gebruiken, en dat is toch jammer omdat me dit best een zinnige beveiliging tegen malware lijkt.

Ik kan in mijn browser toch ook zelf een certificaat authority toevoegen, waarom zou dat in het UEFI dan niet kunnen?

[Blokker_1999]

ik denk niet dat het hen om de effectiviteit te doen is, maar wel de mogelijkheid om linux te booten in een omgeving waar secure boot aanstaat. Dat is de eerste horde die genomen moet worden. Ik dacht dat een andere distro met een getekende grub variant ging komen, en dan zijn we vertrokken om virtueel elk OS te kunnen starten.

[Ramon]

Dan zet je Secure Boot toch uit

[Egocentrix]

Volgens mij was dat nou juist het probleem. Om een 'designed for windows 8'-sticker te verdienen voor je apparaat, moet je het als fabrikant onmogelijk maken om het uit te zetten. (correct me if i'm wrong)

edit: nieuws: 'Secure boot van Windows 8 maakt booten Linux onmogelijk'

[Reactie gewijzigd door Egocentrix op 25 juli 2024 07:19]

[Ramon]

Juist compleet het tegenovergestelde. Die sticker betekent juist dat je als fabrikant de gebruiker de optie moet geven of ze Secure boot aan of uit willen.

[Blokker_1999]

Het hele probleem is net dat niets MS tegenhoud om in de toekomst deze regel om te draaien en net zoals bij Windows RT (de ARM versie) secure boot verplicht niet uitschakelbaar te maken.

[feuniks]

De personen die MS tegenhouden om dit ook op PC's de regel om te draaien zijn mededingingsautoriteiten, de EU, etc. Met de ARM mogen ze het, omdat ze daar geen monopilie / duopolie positie hebben, maar op de PC hebben ze die wel. Daarom wordt dit competitievervalsing genoemd.

Een aantal van de bovengenoemde spelers hebben al aangegeven kritisch naar secure boot te gaan kijken.

[bkor]

Fout. Het moet juist wel uitgezet kunnen worden op een pc.

Regels die je bedoelt gelden voor ARM.

[Egocentrix]

Mij excuses, dat is inderdaad waar.

Maar als het uitgezet moet kunnen worden, wat is dan eigenlijk het hele probleem van secure boot en linux? Dan kan het toch gewoon allemaal?

[shadylog]

Precies, dat is ook waarom Linus Torvalds ook geen problemen op de horizon ziet voor Linux.

[Dreamvoid]

En ook als het op veel apparaten niet uit te zetten is, werkt Linux gewoon. Zie ook Android, wat ondanks locked bootloaders razend populair is geworden. Er is ook geen fundamentele reden waarom Linux niet met een signed kernel zou kunnen werken. Zolang de source maar openbaar is.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 07:19]

[Jasper Janssen]

Jawel, dat is dus een fundamentele reden. GPLv3 zegt expliciet dat als iets gesigned is dat dan de private key wordt gezien als een onderdeel van de source en dus ook geopenbaard moet worden. En daarmee is ie waardeloos.

[Dreamvoid]

Linux is GPLv2, waar dat wel mag

Je kan proberen om alle copyright houders van de Linux code te overtuigen om over te stappen naar GPLv3, maar aangezien dat tegenwoordig voornamelijk de grote bedrijven (IBM/Google/Oracle/etc) zijn waarvoor code signing interessante toepassingen biedt (secure servers, etc) zie ik dat niet snel gebeuren. Dat zou ook rap het einde betekenen voor allerlei embedded toepassingen van Linux (TV's, routers, mediaspelers, etc) die met signed distro's werken.

Als je een kernel wilt die nooit gesigned mag worden dan zal je nieuwe code moeten schrijven onder GPLv3.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 07:19]

[army]

Sorry, maar kan je aanwijzen waar dat staat? Het enige wat GPLv3 verplicht is dat de procedure om de signing te doen beschreven moet zijn. Iemand moet dus zelf een nieuwe release kunnen maken. Er is nergens de verplichting dat je de keys mee moet leveren net zoals bij GPLv2, maar het probleem bij GPLv2 was het ontbreken van de verplichting om de methode openbaar te maken en dat is waar TiVo gebruik van maakte.

[King4589]

tsja het is een extra handeling. als iemand nieuw is met linux wil die het gewoon makkelijk kunnen installeren en gebruiken en die willen niet eerst iets proberen te installeren en er dan achter komen dat ze iets in de bios/efi/uefi moeten aanpassen.

Als iets niet installeert probeer je het niet snel een tweede keer

[Blokker_1999]

nog niet, wat als Windows 9 bijvoorbeeld niet meer wenst te starten zonder secure boot aan? Of wat als je een ARM device wilt hacken en er Linux op wenst te zetten? Zelfs als secure boot uitschakebaar is kan het zijn dat je in de toekomst telkens je wenst te wisselen tussen Windows en een alternatief OS je eerst een instelling moet gaan wijzigen in je eufi

[Niemand_Anders]

Je kunt gewoon SecureBoot uitschakelen als je dat wilt. Dat is vooralsnog alleen niet toegestaan voor ARM gebaseerde systemen. Alleen als EFI SecureBoot ondersteund en uitstaan, zal Windows zelf niet starten.

Alleen zit natuurlijk niemand te wachten om als je wilt schakelen tussen OS je SecureBoot danwel in-of uit moet schakelen.

[Fuzzillogic]

Ik wil wél secure boot, want ik wil ook veilig kunnen booten. Maar ik wil wel zelf in controle zijn wat ik veilig acht. Dat betekent dat ik zelf de keys moet kunnen beheren. "dan zet je het toch uit" is dus onvoldoende.

[Verwijderd]

Vanuit die hoek had ik het nog niet bekeken.. Goed argument!

[Verwijderd]

dacht het niet?:

but in the event that a manufacturer makes a mistake and delivers a locked-down system with a GRUB 2 image signed by the Ubuntu key, we have not been able to find legal guidance that we wouldn’t then be required by the terms of the GPLv3 to disclose our private key in order that users can install a modified boot loader. At that point our certificates would of course be revoked and everyone would be worse off.

Embedded into the UEFI firmware is a security key, and the OS must know the key in order to boot.

bron: Canonical explains decision to ditch GRUB 2 on UEFI systems
De loader is getekend met de private sleutel van Ubuntu, alleen die loader start op, laat je via die loader andere zaken opstarten is dat mede onder de verantwoordelijkheid van Canonical. En dat is niet de bedoeling van secure boot.

[Dreamvoid]

Dit was ook al langer bekend. Grub is GPLv3, en zal dus nooit gesigned kunnen worden - je kan allerlei bootloaders gebruiken voor secure boot, maar niet Grub.

[Blokker_1999]

en Red Hat doet het dan weer wel. Een signed stage-1 loader die een getekende stage 2 inlaad die dan weer enkel getekende kernels zal kunnen inladen. Blijkbaar zien zij het dus anders.

[hackerhater]

Het kan wel, maar dan moet je de key vrijgeven

[Verwijderd]

Zou het hierdoor mogelijk worden om bvb. Ubuntu na Windows in dual-boot configuratie te installeren zonder problemen tegen te komen?
Ik moest steeds windows als 2de OS installeren omdat Grub de Windows versie niet automatisch herkende...
Dit was vrij onhandig omdat ik graag wat meer Linux versies uitgetest had op deze familie-pc

[jiriw]

Zou het hierdoor mogelijk worden om bvb. Ubuntu na Windows in dual-boot configuratie te installeren zonder problemen tegen te komen?

Met UEFI heb je in principe zelfs geen bootloaders meer nodig. Je kan parallel meerdere OS-sen starten direct vanuit de UEFI.
De oude BIOS had alleen een execution naar sector 0/MBR (of de eerste sector van de als actief aangemerkte partitie) van een van de direct aangesloten en herkende mass-storage devices. Daar pastte maar een bootloader in... dus ieder OS wat op zo'n disk geinstalleerd stond wedijverde om die ene positie. Bij UEFI kan je direct iedere partitie starten die jij leuk vindt. Als daar een executable kernel image staat gaat hij die vrolijk laden en start je zo je OS op.

In de laatste C'T Magazine (2012 7/8 pag. 128) stond er een leuk artikeltje over. De Duitse versie van C'T Magazine heeft er ook op het internet informatie over (pas op: is in het Duits:) http://www.heise.de/ct/ho...m-UEFI-Modus-1361956.html

<edit> even quotje toegevoegd</edit>

[Reactie gewijzigd door jiriw op 25 juli 2024 07:19]

[BRAINLESS01]

Vreemd, ik doe het juist altijd andersom. Als ik eerst Linux installeer en daarna Windows, dan moet ik daarna moeite doen om de Linux bootloader weer terug te krijgen. Windows wordt bij mij altijd wel direct herkend en in de lijst met OSen gezet.

[wootah]

Gelijk heb je BRAINLESS01, eerst windows dan linux
Hoef je niet al dat gezeur te doorgaan met die bootloaders

Aan de ene kant mooi dat canonical dit doet, aan de andere kant is het ook vervelend... waarom zou je secure boot willen hebben
Voor dat je het weet heb je een dicht getimmerde pc, dan hoeft het voor mij ook geen meer pc te heten.

[Reactie gewijzigd door wootah op 25 juli 2024 07:19]

[brompot758]

waarom zou je secure boot willen hebben

Omdat er PC's gaan komen die allen maar secure boot ondersteunen. Of MS haalt een stunt uit en laat Windows alleen booten als secure boot aan staat in je firmware, steeds aan en uitzetten is ook niks.

Op zich is secure boot een maatregel tegen ongewild wijzigen van je OS/bootloader, maar het gaat vast ook gebruikt worden om de openheid van het platform in te perken.

Probleem is dat de public key van jouw signing key in de firmware moet staan. En dat je niet zelf een key kan toevoegen. Als je nou een key via Verisign of zo kon krijgen....

[SunnieNL]

Een key via verisign krijgen kan ook gewoon. Dat is geen enkel probleem. Daar kun je vervolgens je eigen kernel mee signen. Kost alleen geld. Vandaar dat Ubuntu een andere optie biedt straks

[xxxneoxxx]

Enige idee wat dat kost? Doe je niet even zomaar hoor..

[Terracotta]

99euro is wat red hat betaalt voor hun fedora key

[Verwijderd]

Het was een van m'n eerste ervaringen met Linux (en bootloaders) toen ik die problemen kreeg.. Misschien deed ik het fout?
Met een gezin van trouwe Windows-gebruikers was er daarbij weinig ruimte voor fouten..
Nu heb ik een eigen laptop waar ik zelf alles op uitprobeer. Windows is daar het alternatieve OS (games), terwijl ik op Linux wat leer programmeren..

[Reactie gewijzigd door Verwijderd op 25 juli 2024 07:19]

[Dreamvoid]

waarom zou je secure boot willen hebben

Secure boot betekent dat de handover tussen EFI/BIOS en bootloader (en daarna het OS, of zelfs direct het OS) versleuteld gebeurd, waardoor rootkits geen kans krijgen om zich onzichtbaar tussenin het boot proces te injecteren.

Het helpt ook tegen piraterij, aangezien de bekendste Windows 7 crack precies dit doet Voor Microsoft dus 2 vliegen in 1 klap. Voor Linux is alleen het security aspect ervan interessant, daarom zijn dus vooral de enterprise Linux distro's (gematigd) positief erover.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 07:19]

[dmystic]

zolang je geen freebsd pakt, want die vindt het blijkbaar leuk om zonder enige optie gewoon de windows bootloader te overschrijven

[King4589]

even een windows rescue cd er in en de bootloader terug laten zetten zou moeten werken.

De ergste zijn die distributies die zonder enige optie ALLE HDD's formateren zoals trixbox

[arjankoole]

zolang je geen freebsd pakt, want die vindt het blijkbaar leuk om zonder enige optie gewoon de windows bootloader te overschrijven

Vreemd, ik hoefde destijds alleen windows er bij te zetten, en toen werkte het weer. Mar goed, freebsd is niet bedacht voor dt soort situaties, het gaat standaard uit van een server.

[Z_God]

Ik hoop vooral dat er een makkelijke manier gaat komen om die UEFI onzin te vermijden. Ik zal er bij de aanschaf van nieuwe hardware in ieder geval op letten. Het liefst koop ik iets wat met coreboot werkt of gewoon een ouderwetse BIOS (wat technisch n.b. superieur is aan UEFI).

[Jasper Janssen]

a) Nee, BIOS is absoluut niet technisch superieur aan UEFI.

b) hardware met coreboot out of box bestaat niet.

c) De keuze om hardware met BIOS te blijven kopen heb je niet, hoogstens kun je het moment een tikkeltje uitstellen.

[Z_God]

a) Noem 1 reden. (Anders dan dat de beperkingen van de huidige BIOSen verdwijnen.)

b) Zal nu wel meer markt voor komen. AMD support coreboot op hun chipsets, dus dat is dan een reden om AMD te kopen.

c) Ja dat is het jammere. Maar ik besteed graag wat meer aan een mobo als dat betekent dat ik er gewoon coreboot op krijg of dat ik dat er zelf op kan flashen

[0xDEADBEEF]

b) hardware met coreboot out-of-the-box bestaat wel: http://www.engadget.com/2...totype-hints-at-ivy-brid/

[Blokker_1999]

ik heb al hardware met uefi gebruikt (en de kans is groot dat de meesten dat al gedaan hebben ondertussen) en het opend een hele hoop mogelijkheden. Zolang Secure Boot geen verplichting is zie ik het probleem niet echt.

[Z_God]

Ik ben er niet bekend mee, maar ik begrijp dat UEFI nogal een gesloten gebeuren is, dus voor tweakers alles behalve interessant.

Ik ben wel benieuwd welke mogelijkheden het brengt. Zoals ik hierboven schreef, zal ik het zelf zoveel mogelijk proberen te vermijden.

[Verwijderd]

Is het mogelijk om bijvoorbeeld in een aparte partitie dan een ondertekende Grub loader te installeren ? Wegens dat het binaries zijn lijkt het me voor Ubuntu geen enkel probleem om een ouderwetse Grub loader te ondertekenen met dezelfde sleutel als waarmee ook de Linux kernel zelf ondertekend is. Installeren van deze grub loader in een aparte partitie zou het mogelijk moeten maken deze ondertekende grub loader op te starten vanuit Secure boot alsof het een compleet operatingsysteem zou zijn. Als deze ondertekende Grub eenmaal is gestart dan zou vervolgens een alternatief OS via deze tweetrapsraket gestart kunnen worden.
Zou dit haalbaar zijn ?

[Dreamvoid]

Nee, want grub is GPLv3, dit betekent dat als je grub signed, je naast de source code ook de private key moet vrijgeven. Dat maakt de key direct waardeloos.

GPLv2 code (zoals de Linux kernel) mag wel gesigned worden met een private key.

Je zou evt een secure loader (met certificaat) kunnen bouwen, die vervolgens grub laadt, maar dan heb je weer geen versleutelde boot-sequence.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 07:19]

[Verwijderd]

Het grote probleem is/blijft het locked-down system: het is gedaan met de keuze van wat je laat opstarten.
Wat je ook nergens terug vindt: "Wat er gebeurd als je een pre-installed (windows/ubuntu) computer krijgt?" Windows certificatie eist dat secure boot is ingeschakeld.

UEFI "secure boot" feature may impact Linux (machines with the Windows 8 logo with secure boot enabled that ships with only OEM and Microsoft keys will not boot a generic copy of Linux).[50][51] In response, Microsoft stated that customers may be able to disable the secure boot feature in the UEFI interface.[2][52] Concern remained that some OEMs might omit that capability in their computers.

bron: Unified Extensible Firmware Interface

PCs certified for Windows 8 will require UEFI booting by default. Many vendors have started adopting UEFI as their firmware. Some of the notable UEFI firmwares are Phoenix SecureCore Tiano, AMI Aptio, and Insyde H2O.

bron: Booting Linux natively on a UEFI system (without BIOS CSM) using GRUB2

[MadEgg]

Tja, dan kun je het vast wegflashen, maar het wordt er voor consumenten die Linux eens uit willen proberen niet makkelijker op. Aan de andere kant, als zij de keuze hebben om Fedora danwel Ubuntu eenvoudig uit te proberen omdat zij wel een signed bootloader hebben, hebben zij genoeg om initieel mee uit de voeten te kunnen op Linux gebied. En wellicht volgen er nog meer distributies.

Dat ze dan geen complexere distro's als Gentoo etc kunnen installeren omdat die geen secure boot key hebben is dan van later zorg, ze zullen toch niet in staat zijn om iets dergelijks te installeren en/of te onderhouden.

[Verwijderd]

Fijn dat secure boot meer ondersteund wordt. Het gebrek aan beveiliging van het booten van Linux was toch altijd de grootste zwakte van Linux in bedrijfsomgevingen.

[Binscow]

Ik heb zelf ook een machine met UEFI, maar weet niet echt welk voordeel dit brengt. Men heeft het over beveiligd booten; kan iemand dit verhelderen?

[Blokker_1999]

Je ziet de functionaliteit al sinds Vista zijn intrede doen. Getekende code zijn programmas waar met behulp van SSL een handtekening word aan toegevoegd en dient dan om aan te tonen wie de eigenaar is van de code alsook beveiligd het het bestand tegen wijzigingen, als je iets aanpast is de handtekening niet meer geldig. Als je een UAC melding krijgt omdat een programma adminrechten vraagt zie je bij een gehandtekend exemplaar een blauwe banner bovenaan het venster en de naam van de uitgever, is het bestand niet getekend is de waarschuwing meer prominent met een gele banner en de melding dat de uitgever onbekend is.

MS wil dit principe nu verder doortrekken naar het volledige windows boot proces. Als je in je uefi (de opvolger van het bios) de functie secure boot aanzet dan kan je enkel nog een bootloader gebruiken die voorzien is van een geldige handtekening. Op deze manier wil MS het opstartproces van Windows beveiligen. Op dit moment word Windows 7 namelijk gekraakt door het opstartproces van windows aan te passen.

secure boot zal op de desktop pc bij Windows 8 nog geen verplichting vormen, bij de ARM versie zal secure boot wel verplicht zijn.

[Freeaqingme]

Ja, want Windows doet dat al jaren... not

(dit speelt pas vanaf Windows 8 )

[Reactie gewijzigd door Freeaqingme op 25 juli 2024 07:19]

[blouweKip]

Volgens mij speelt er een gevalletje sarcasme mee in sleep0rz statement

[latka]

Wat een geleuter: in de meeste bedrijfsomgevingen (zeker de serieuze & grote) draait alles in een VM en is het veel belangrijker of de VM host wel secure boot doet (zal wel niet). De security hole hiervan is minimaal vergeleken met interne hacks en brakke (web) applicaties. FUD dus.

[humbug]

Ja, ja. Hoeveel machines ken jij die op dit moment secure boot ondersteunen?

Secure boot is een feature die in nieuwe PCs komt en eigenlijk is windows 8 het eerste OS dat hier echt mee aan de gang gaat. Vandaar ook dat Linux bedrijven als Red Hat en Canonical nu over secure boot aan het nadenken zijn en via Microsoft hun sleutels gaan regelen (Microsoft is de enige die dit op dit moment voor hen kan doen).

Natuurlijk is het gebrek aan een ondertekende bootloader een risico. Maar dat risico gaat net zo hard op voor Windows 7 als Linux. Ook zijn er nog genoeg andere "zwaktes" voor linux in een bedrijfsomgeving Met name Linux op de desktop is nog steeds een redelijk matige ervaring

[Teckna]

Ik vraag me af wat het verschil is tussen palladium waar iedereen toen zo tegen was en secure boot? Geef je nu niet in principe hetzelfde weg? Of is Secure boot een soort van palladium light?

[Verwijderd]

Ik heb ook wel enige bedenkingen bij dat Secureboot.
Ik heb het idee dat de toegestane operatingsystemen op een PC met secureboot (als deze optie niet uitschakelbaar is) nu beperkt gaat worden tot Windows-7 of 8 en Ubuntu of een andere hele beperkte lijst.
Als ik het goed begrijp dan zou dit ook betekenen dat nieuwe operatingsystemen geen enkele kans meer hebben om op een PC geïnstalleerd te worden wegens dat deze niet de juiste handtekening hebben.
Als iemand als Linus Torvalds opeens een nieuw OS zou bedenken dan zou het op deze manier niet van de grond kunnen komen omdat niemand het kan installeren als de secureboot optie niet uitgeschakeld zou kunnen worden (zie dat bericht over die HP computer waarop je alleen Windows en Suze kan installeren). Graag laat ik mij overtuigen van het tegendeel.

[kokx]

Verder werd de code van Grub als te gedateerd bestempeld.

Alsof code roest ofzo? Dit is echt een groot non-argument. Oude code is meestal juist beter en meer bug-free. Commentaar als dit lijkt erop dat Canonical steeds minder weet waar het mee bezig is.

[kjast]

Ben ik niet met je eens. Fortran wordt bijvoorbeeld ook steeds minder gebruikt, ondanks dat het (mits juist gebruikt) bloedsnel kan zijn. Op een gegeven moment wordt een dergelijke methode echter te oud omdat bepaalde functies en mogelijkheden er niet in zitten, en niet makkelijk aan toe te voegen zijn.

Grub is bijzonder gedateerd maar werkt nog prima mits je geen secure boot etc. nodig hebt. En het ombouwen van Grub om wel dergelijke functies mogelijk te maken staat gelijk aan het schrijven van een compleet nieuwe versie, kortom Grub is gedateerd.

[divvid]

goh, pas nog een stukje Fortran aangepast en een stukje Pascal gedebugged, gewoon omdat deze code goed en snel werkt. Oud is zeker geen synoniem voor slecht. Nog zo'n voorbeeld. in mijn vak groeien de data bestanden sneller dan de computer technologie kan bijhouden. Waar we vroeger nog met een perl/python scriptje uit konden blijken good old grep, awk, sed, comm, sort en uniq ineens heel erg aantrekkelijk.

[MicGlou]

Gedateerd is ook geen synoniem voor slecht... Je maakt nu eigenlijk dezelfde denkfout. Het kan allemaal prima werken waar het voor gemaakt is en zelfs de beste zijn op bepaalde vlakken, maar het kan door de tijd ingehaald worden en dat is nou ter sprake. Het heeft toch geen zin om het compleet te herschrijven om de boel geschikt te maken... sowieso wat blijft er dan over van 'goed werkende' delen want vrijwel de hele boel moet op de schop of herschreven worden.

[Jeanpaul145]

Dat is gewoonweg niet waar, in elk geval hier niet. De originele grub code is echt een rommeltje, dat was 1 van de motivaties om grub2 van scratch te schrijven.
Dit verschil wordt ook niet duidelijk gemaakt door het artikel: Canonical heeft naar grub 0.9 gekeken naast grub2, en besloten dat het niet te doen was om daarmee aan de slag te gaan.

[Jasper Janssen]

Grub2 is GPLv3 en kan dus niet gebruikt worden, en de oude grub is weliswaar gplv2 maar is gewoon kut. Grub2 is niet voor niks geschreven.

[Blokker_1999]

waarom kan Red Hat dan wel een Grub2 laten tekenen?

[Dreamvoid]

Is dat met een vrijgegeven private key gebeurd?