Firmware, de nachtmerrie. Deel 4: De pikzuigwedstrijd

Een deel van de zorg om te willen dat de kernel de veilige start op een laag niveau afhandelt, is dat de sleutels van Microsoft kunnen worden gebruikt om het systeem te hacken, en als dat gebeurt, zijn ze bang dat Microsoft de sleutel zal uitschakelen en dus Linux-pc's. Laat ze draaien met die sleutel (en dat wil niemand).

Het begon allemaal met een pull-verzoek van David Howells waarmee binaire sleutels ondertekend door Microsoft dynamisch in de kernel konden worden geladen in veilige opstartmodus. Degene met de deken vond het onzin en dat het beter zou zijn om de X.509-parser te verbeteren. Matthew Garrett antwoordt dat er maar één tekenbevoegdheid is en dat ze alleen PE-binaries (draagbare uitvoerbare bestanden) ondertekenen. En hier laat Linus zijn scherpe tong los en zegt:

Jongens, dit is geen wedstrijd om pik te zuigen. Ga je gang als je PE-binaire bestanden wilt parseren. Als Red Hat je wil vragen garganta profunda voor Microsoft is het * jouw * probleem. Het heeft niets te maken met de kernel die ik onderhoud. Het is voor u triviaal om een ​​ondertekeningsmachine te hebben die het PE-binaire bestand ontleedt, de handtekeningen verifieert en de resulterende sleutels ondertekent met een eigen sleutel. Ze hebben de code al geschreven, bij God, het is in die verdomde volgorde. Waarom zou het mij iets kunnen schelen? Waarom zou de kernel zoiets geven als "we ondertekenen alleen PE-binaries"? We ondersteunen X.509, de standaard voor ondertekening. Doe het aan de kant van de gebruiker op een betrouwbare machine. Er is geen excuus om het in de kernel te doen.

Matthew antwoordt:

Verkopers willen sleutels meenemen die zijn ondertekend door een vertrouwde derde partij. Nu is de enige die het meet, Microsoft, want blijkbaar volgen de specificaties van Microsoft het enige waar leveranciers meer van houden dan waardeloze firmware. Het equivalent is niet alleen dat Red Hat (of wat dan ook) die sleutels programmatisch opnieuw ondertekent, het is het opnieuw ondertekenen van die sleutels met een vertrouwde sleutel door de upstream kernel. Zou u bereid zijn om standaard een vertrouwde sleutel bij u te hebben als een lid van de vertrouwde vereniging een dienst voor opnieuw ondertekenen host? Of gaan we ervan uit dat iedereen die externe modules wil lanceren een idioot is en het verdient om ellendig te zijn?

Linus antwoordt dat hij betwijfelt of het iemand iets kan schelen. Dat het al stom is om kernelmodules te ondertekenen met een Microsoft-sleutel. Ook zal Red Hat de binaire NVIDIA- en AMD-modules ondertekenen. Peter Jones zegt nee, dat Red Hat geen module zal ondertekenen die door een ander is gebouwd. Garret voegt eraan toe dat RHEL uiteindelijk zal vertrouwen op sleutels van NVIDIA en AMD en dat het zeer waarschijnlijk is dat ze gebaseerd zullen zijn op de ondertekeningsservice van Microsoft.

En hier pauzeer ik en vat ik gedeeltelijk en brutaal samen voor degenen die niet op technische details willen ingaan:

Alle ontwikkeling rond de veilige start is gek geworden, maar omdat de hardwareleveranciers (de grootste tenminste) nog steeds Microsoft willen deepthroaten.

Dus besloot Linus de volgende suggesties te doen, dus stoppen ze met neuken ……:

Snijd het af met bangmakerij.

Dit is wat ik zou willen voorstellen, en het is gebaseerd op ECHTE VEILIGHEID en in ZET DE GEBRUIKER OP DE EERSTE PLAATS in plaats van zijn "laten we Microsoft verwennen door onzin te doen" -benadering.

Laten we dus in plaats van Microsoft tevreden te stellen, proberen te kijken hoe we echt beveiliging kunnen toevoegen:

- een distro moet zijn eigen modules ondertekenen EN NIETS MEER standaard. En het zou ook helemaal niet moeten toestaan ​​dat een andere module standaard wordt geladen, want waarom zou dat verdomme wel moeten? En wat heeft een microsoft-firma met iets anders te maken?

- Controleer voordat u modules van derden laadt vraag de gebruiker om toestemming. Op de console. Zonder sleutels te gebruiken. Niets daarvan. De sleutels worden gecompromitteerd. Probeer de schade te beperken, maar wat nog belangrijker is, laat de gebruiker de controle hebben.

- Animeer dingen zoals willekeurige sleutels per host - met stomme UEFI-controles uitgeschakeld indien nodig. Ze zullen vrijwel zeker veiliger zijn, dus afhankelijk van een of andere gekke vertrouwensbasis op basis van een groot bedrijf, met ondertekenende autoriteiten die iedereen vertrouwen die een creditcard heeft. Probeer mensen die dingen te leren. Moedig mensen aan om hun eigen (willekeurige) sleutels te maken en deze toe te voegen aan hun UEFI-instellingen (of niet: alles aan UEFI heeft meer te maken met controle dan met beveiliging), en streef ernaar om dingen te doen zoals eenmalig ondertekenen met de privésleutel weggegooid. Met andere woorden, probeer dat soort beveiliging te animeren, zoals "we zorgen ervoor dat we de gebruiker expliciet vragen met grote waarschuwingen en maken hun eigen sleutel voor die specifieke module." Echte veiligheid, geen veiligheid "wij controleren de gebruiker."

Natuurlijk gaan gebruikers het ook verpesten. Ze zullen NVIDIA binaire modules en al die onzin willen laden. Maar laat het zo zijn SU beslissing, en onder SU controle, in plaats van de wereld te vertellen hoe dit door Microsoft zou moeten worden gezegend.

Omdat dit niet over MS-zegeningen zou moeten gaan, maar over de gebruiker zegent de kernelmodules.

Eerlijk gezegd, jij bent wat de gekke anti-key mensen vrezen. U verkoopt de "controle, geen beveiliging" shitware. Alle "MS is eigenaar van uw machine" is gewoon de verkeerde manier om wachtwoorden te gebruiken.

Vanaf dat moment kalmeerde de draad ... en het is niet de moeite waard om te volgen.

Vrienden van DesdeLinux. Hoy cumplo mi primer aniversario como redactor en un blog de linux, a pesar de no haber debutado como tal aquí sino en el blog de frannoe que por entonces se llamaba Ubuntu Cosillas y que hoy es LMDE Cosillas. Y fue allí un 2 de marzo cuando escribí el primer capítulo de esta saga del firmware que luego continué aquí. Quisiera agradecer a todos los que me leen y me leyeron, sobretodo a Frannoe y todo el staff de Desdelinux por hacerme un lugar. Si no fuese por haber hecho aquel curso de Programación Funcional Avanzada, y un compañero que me sugirió usar un linux para trabajar con ghc, seguro que me seguiría importando 3 pepinos todo lo de linux.

Ik ga eindigen met deze zin: "Als je je onwetendheid niet schreeuwt, komt er niemand naar buiten om je te corrigeren en daarom heb je gelijk als je ongelijk hebt"

Relevante berichten uit de lijst met kernel-mails:

https://lkml.org/lkml/2013/2/21/196

https://lkml.org/lkml/2013/2/21/228

https://lkml.org/lkml/2013/2/21/275

https://lkml.org/lkml/2013/2/25/487


11 reacties, laat de jouwe achter

Laat je reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

*

*

  1. Verantwoordelijk voor de gegevens: Miguel Ángel Gatón
  2. Doel van de gegevens: Controle SPAM, commentaarbeheer.
  3. Legitimatie: uw toestemming
  4. Mededeling van de gegevens: De gegevens worden niet aan derden meegedeeld, behalve op grond van wettelijke verplichting.
  5. Gegevensopslag: database gehost door Occentus Networks (EU)
  6. Rechten: u kunt uw gegevens op elk moment beperken, herstellen en verwijderen.

  1.   Juan Carlos zei

    Het probleem is dat als de fabrikanten van notebooks en anderen zeker achter Wintel's UEFI staan ​​(we mogen niet vergeten dat UEFI het idee van Intel is) en, in het ergste geval, ze allemaal besluiten om de optie om het te deactiveren niet op te nemen, Linux-distributies zijn gaan er zwart uitzien als ze de handtekening niet hebben, en ik denk dat dat iets is wat de mensen bij RedHat hebben opgemerkt. Ik wil zien wat ze over een paar jaar gaan doen als Linux niet op een nieuwe computer kan worden geïnstalleerd omdat het de handtekening niet heeft.

    1.    Ankh zei

      In het ergste geval ondertekenen de distributies de kernel met de sleutels die door Microsoft zijn ondertekend. In feite is het wat verschillende al doen.
      Wat Torvalds zegt, is dat dit bij elke distro moet worden opgelost, omdat de kernel het niet gaat doen. En dit is het meest verstandige, het heeft geen terugkeer.

  2.   pavloco zei

    Linus is mijn favoriete persoonlijkheid uit de echte wereld. Het is alsof hij uit een film van Quentin Tarantino is gehaald om een ​​gemeenschap te leiden. Je hebt helemaal gelijk met wat je zegt.

  3.   Alf zei

    En de LinuxMint-machines, worden ze geleverd met UEFI / Secure boot? Ik sta erop dat als ik er een nodig heb, ik er een zal kopen.

    Mijn schoot is een jaar oud, tegen de tijd dat ik er nog een nodig heb, denk ik dat het UEFI / Secure-opstartprobleem al goed is opgelost, of correct geïmplementeerd of naar behoren geëlimineerd, ha.

    1.    merlin de debianite zei

      Ik betwijfel het echt, het is onmogelijk, want hoewel de mintbox is ontworpen om te worden gebruikt met linuxmint, fedora, ubuntu en debian, zoals het in de specificaties staat, zou het dwaas zijn om veilig opstarten op iets te zetten dat zeker dualboot zal hebben, of het is ontworpen voor gratis of redelijk gratis software in het geval van Ubuntu XD.

  4.   nano zei

    Welnu, het is een onderwerp dat altijd tot controverse heeft geleid sinds het uitkwam. Het is interessant om te zien hoe hij vooruitgaat en als Alf denk ik dat het op middellange termijn zal verbeteren. Er zijn fabrikanten die altijd de deactivering van secure boot zullen toestaan ​​en anderen die Linux al voorgeïnstalleerd hebben, zoals ThinkPenguin of System76, ik hoop dat er na verloop van tijd meer en meer geboren zullen worden om een ​​keuze te hebben ... ik zal altijd de voorkeur geven om iets te kopen dat 100% compatibel is met Linux, gegarandeerd om ze met elke andere machine te spelen.

  5.   levendig zei

    Ik begrijp deze shenanigans van UEFI en anderen nog steeds niet zo goed .. Shit .. trouwens diazepan: Gefeliciteerd! Het is ons een genoegen u hier te hebben.

  6.   Daniel zei

    Uiteindelijk kopen we pure serverapparatuur, tenminste als ze deze shit daar niet naartoe vervoeren.
    Het zou een groot persoon moeten zijn dat de meeste van de grote en kritieke servers met Linux werken en velen van hen (afhankelijk van hun behandeling) zijn extreem veilig, alsof ze aannemen dat deze beveiligingstrek al die kwaadaardige software zal doden.

  7.   Charlie-bruin zei

    Zoals altijd ben ik het ZEER eens met wat Linus naar voren brengt, zoals hij terecht zegt, dit UEFI-onderwerp gaat meer over "controle" dan over "beveiliging". Wat mij betreft, ik vertrouw helemaal niet op dit vermeende beveiligingsmechanisme en als een team met UEFI in mijn handen valt, is het eerste wat ik zal doen het deactiveren en doorgaan zoals voorheen. Aan de andere kant geloof ik niet dat fabrikanten van apparatuur de deactivering van de UEFI zullen voorkomen, omdat ze het risico lopen marktaandeel te verliezen; dat er iemand zal zijn die risico's neemt of het op zijn minst doet in sommige specifieke modellen, ik twijfel er niet aan, maar ik denk dat er altijd oplossingen zullen zijn, onthoud dat dit niets meer is dan een BIOS met steroïden en de mogelijkheid om te upgraden het met "open" versies zal altijd latent zijn.

  8.   Alexander zei

    Voor zover ik weet werkt de eufi alleen voor win8 als je een dual-boot-systeem wilt, omdat je de bios zelf kunt deactiveren, dus het maakt niet uit of je alleen linux hebt en die optie uit de bios deactiveert en dat is niet nodig zoveel gedoe over de kwestie.

  9.   Fabri zei

    Dit onderwerp is een beetje groot voor mij, maar door persoonlijke afleiding zie ik dat de Microsoft-poppen ze zwart begonnen te zien toen ze zagen hoe volwassen Linux is…. En hoe ze de grote fabrikanten monopoliseren sinds het begin der tijden, voor mij is het duidelijk waarom er zoveel moeite is met die verdomd veilige laars ... zelfs een of ander groot of middelgroot bedrijf. Ik veronderstel dat ik andere opties zou nemen zonder reken op meer en daar ga ik mijn volgende machine kopen ... dat is zeker 😉