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)
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
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
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.
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.
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 zondag 24 juni 2012 16:09]
zolang je geen freebsd pakt, want die vindt het blijkbaar leuk om zonder enige optie gewoon de windows bootloader te overschrijven
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
De ergste zijn die distributies die zonder enige optie ALLE HDD's formateren zoals trixbox
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.zolang je geen freebsd pakt, want die vindt het blijkbaar leuk om zonder enige optie gewoon de windows bootloader te overschrijven
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..
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 hoid op zondag 24 juni 2012 16:27]
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.waarom zou je secure boot willen hebben
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....
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
Enige idee wat dat kost? Doe je niet even zomaar hoor..
99euro is wat red hat betaalt voor hun fedora key
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.waarom zou je secure boot willen hebben
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 zondag 24 juni 2012 17:32]
Met UEFI heb je in principe zelfs geen bootloaders meer nodig. Je kan parallel meerdere OS-sen starten direct vanuit de UEFI.Zou het hierdoor mogelijk worden om bvb. Ubuntu na Windows in dual-boot configuratie te installeren zonder problemen tegen te komen?
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 zondag 24 juni 2012 16:57]
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.
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?
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.
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.
Ja, want Windows doet dat al jaren... not
(dit speelt pas vanaf Windows 8 )
(dit speelt pas vanaf Windows 8 )
[Reactie gewijzigd door Freeaqingme op zondag 24 juni 2012 16:05]
Volgens mij speelt er een gevalletje sarcasme mee in sleep0rz statement
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.
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
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
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.Canonical meldt verder dat alleen de binaries van de bootloader van een Ubuntu-handtekening voorzien hoeven worden
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.
Dan zet je Secure Boot toch uit 
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'
edit: nieuws: 'Secure boot van Windows 8 maakt booten Linux onmogelijk'
[Reactie gewijzigd door Egocentrix1 op zondag 24 juni 2012 16:09]
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.
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.
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.
Een aantal van de bovengenoemde spelers hebben al aangegeven kritisch naar secure boot te gaan kijken.
Fout. Het moet juist wel uitgezet kunnen worden op een pc.
Regels die je bedoelt gelden voor ARM.
Regels die je bedoelt gelden voor ARM.
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?
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?
Precies, dat is ook waarom Linus Torvalds ook geen problemen op de horizon ziet voor Linux.
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 zondag 24 juni 2012 16:54]
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.
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.
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 zondag 24 juni 2012 17:36]
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.
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
Als iets niet installeert probeer je het niet snel een tweede keer
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
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.
Alleen zit natuurlijk niemand te wachten om als je wilt schakelen tussen OS je SecureBoot danwel in-of uit moet schakelen.
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.
Vanuit die hoek had ik het nog niet bekeken.. Goed argument!
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....
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 zondag 24 juni 2012 16:19]
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.
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 zondag 24 juni 2012 17:03]
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.
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 zondag 24 juni 2012 16:52]
Als miljoenen mensen voor zichzelf hun eigen security validatie doen, wat is die validatie dan nog waard?
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.
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.
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?
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?
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.
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.Verder werd de code van Grub als te gedateerd bestempeld.
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.
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.
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.
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.
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.
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.
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.
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.
waarom kan Red Hat dan wel een Grub2 laten tekenen?
Is dat met een vrijgegeven private key gebeurd?
Zo fijn zijn als Grub niet meer nodig was en er een bootloader komt waarbij alle Microsoft en Linux besturingssystemen onder 1 nieuwe betere bootloader gemakkelijk geinstalleerd (en beheerd) kunnen worden. Grub is "te gedateerd" en Microsoft maakt er ook een potje van, met elke nieuwe Windows versie is het weer anders, het blijft allemaal zeer gebruiksonvriendelijk om meerdere besturingssystemen te installeren.
Het zou fijn zijn, maar ik zie Apple en MS niet echt samenwerken met elkaar hier, laat staan met de FOSS community. Een extra bootloader is een wrat die we zullen moeten accepteren zolang de dominante OSen op deze planeet closed-source zijn.
Ik vind trouwens de OSX bootloader (BootCamp) de fijnste die ik tot nu toe gezien heb.
Hoe kom jij opeens bij Apple? En hoezo zouden Microsoft en Apple niet samen kunne werken hier? Doen ze wel vaker hoor, bootcamp?
Dit was op het bericht van jeanpaul145 bedoeld
Dit was op het bericht van jeanpaul145 bedoeld
[Reactie gewijzigd door churchill9 op zondag 24 juni 2012 20:06]
Niks mis met concurrentie, toch?
wat is er mis met grub? Enorm flexibele bootloader met een command line voor wanneer het mis gaat en on-the-fly aanpassingen aan boot-entries. Hoeveel boot managers kunnen dat?
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).
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.
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.
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
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
b) hardware met coreboot out-of-the-box bestaat wel: http://www.engadget.com/2...totype-hints-at-ivy-brid/
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.
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.
Ik ben wel benieuwd welke mogelijkheden het brengt. Zoals ik hierboven schreef, zal ik het zelf zoveel mogelijk proberen te vermijden.
ik heb nog steeds mijn tweifels bij deze secureboot zooi.
als ik dik geld besteed aan hardware wil ik toch echt ten alle tijden de volledige rechten hebben en volledig kunnen beslissen wat ik ermee doe en secureboot past niet in dat plaatje.
als ik dik geld besteed aan hardware wil ik toch echt ten alle tijden de volledige rechten hebben en volledig kunnen beslissen wat ik ermee doe en secureboot past niet in dat plaatje.
Had laatst een nieuwe hp windows7 laptop in handen, pre-installed, kon je ook al geen parted magic meer laten opstarten van USB stick of optische schijf. Kon ook niets meer wijzigen in de bios. Je kon alleen met een gekochte suze enterprise CD via HP nog opstarten.
Bij mij komt geen troep binnen waar ik geen volledige controle over heb. Cripleware: kunnen ze lekker houden.
Bij mij komt geen troep binnen waar ik geen volledige controle over heb. Cripleware: kunnen ze lekker houden.
[Reactie gewijzigd door Jan Gruuthuse op zondag 24 juni 2012 18:17]
Enige idee welk type?
HP ProBook 4730s dacht ik, alleen te krijgen met windows7 of SUSE Linux Enterprise 11.
Eigenaar had geen enkele toegang tot andere instellingen of documentatie dat het wel kon.
Eigenaar had geen enkele toegang tot andere instellingen of documentatie dat het wel kon.
Totdat je geen andere keus meer hebt...
Ze proberen met computers nu hetzelfde als bij smartphones en tablets: de eindgebruiker beperken in mogelijkheden zodat de vraag naar sneller en beter hoog blijft en zoveel mogelijk kleine spelers die daarbij roet in het eten gooien met (innovatieve) goedkope of gratis software buitensluiten. De enige reden dat Secure Boot er is gekomen. Er wordt helemaal niets veiliger van.
Ze proberen met computers nu hetzelfde als bij smartphones en tablets: de eindgebruiker beperken in mogelijkheden zodat de vraag naar sneller en beter hoog blijft en zoveel mogelijk kleine spelers die daarbij roet in het eten gooien met (innovatieve) goedkope of gratis software buitensluiten. De enige reden dat Secure Boot er is gekomen. Er wordt helemaal niets veiliger van.
Ik ben erg benieuwd of die bootloader ook andere linuxen gaat ondersteunen. Ten slotte was GRUB toch wel zo ingeburgerd dat het bijna alles kon starten. Of zou Canonical een aftreksel van GRUB maken?
dacht het niet?:
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.
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.
bron: Canonical explains decision to ditch GRUB 2 on UEFI systemsEmbedded into the UEFI firmware is a security key, and the OS must know the key in order to boot.
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.
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.
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.
Het kan wel, maar dan moet je de key vrijgeven
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?
Op dit item kan niet meer gereageerd worden.
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
