Beiträge von El Pollo Diablo im Thema „Secure Boot, TPM und die Paranoia der deutschsprachigen Linux Community“

    Nun ja, mit der Marktmacht von MS wird es nun ein neues Tastatur-Layout geben. Also warum nicht auch TPM 2.0 nicht mehr deaktivierbar. Evt. ab 14 Okt. 2025.

    Ich gebe Dir absolut Recht!

    Ich bin mir nicht sicher, ob ich im letzten Jahr zu tief in die Linux Bubble abgerutscht bin und meine immer größer werdende Aversion gegen MS ein - wie nennt man es neudeutsch? - "Bias" aus der Echokammer meiner Linux Peers ist. Aber ich sehe hier eine Megacorp, die immer aggressiver im Kampf um eine Vorherrschaft im IT-Sektor vorgeht. Ihre Kunden geht MS doch gelinde gesagt am Allerwertesten vorbei. Von den Privatanwendern ganz zu schweigen. Überall wird, ob sinnvoll oder nicht, ihre KI eingebaut (Stichwort "CoPilot im kommenden Notepad"), um dann fürstlich abzukassieren oder das Produkt ohne Lizenz schlichtweg unbrauchbar zu machen.

    Kennt Ihr noch aus den frühen 2000ern auf MTV die Auto-Aufmotz-Sendung "Pimp my Ride"? Was haben ich mich köstlich darüber amüsiert, wenn die Jungs in inflationärer Weise in die Karren überall kleine LCD Monitore an den unmöglichsten Stellen eingebaut haben. MS macht es heute mt dem Copilot nicht anders. Der Unterschied: Damals bei Pimp my Ride war es lustig, heute bei MS ist es beängstigend.

    Könnte man sollte so ein Fall eintrit, nicht immernoch SecureBoot deaktivieren?

    *Ironie EIN*

    Bisher kenne ich keinen Hersteller, wo man SecureBoot nicht wieder ausstellen kann. Wie das vielleicht mal in weiter Zukunft aussieht, wenn Windows 15 den Weltmarkt dominiert und wir den PC nur starten können, wenn wir uns über eine neuronale Schnittstelle im Hinterkopf am Rechner einklinken müssen, damit sichergestellt ist, dass wir authentifiziert sind und unsere „Benutzererfahrung“ durch einen KI optimiert wird, dann könnte es durchaus sein, dass es nur noch SecureBoot gibt.

    *Ironie AUS*

    Mich würde es nicht verwundern, wenn SecureBoot von den großen Softwarebuden irgendwann erzwungen wird und die Hardwarehersteller dann nachziehen und es alternativlos fest aktivieren. Ich habe per se nichts gegen SecureBoot und sehe durchaus Vorteile, wenn es um IT Sicherheitsaspekte geht. Ich finde es nur „unglücklich“, dass eine Megacorp auf dem SecureBoot sitzt und die Schlüssel zertifiziert. MS hat die Rolle zwar nur übernommen, weil es damals niemand anderes machen wollte, aber es ist nicht von der Hand zuweisen, dass sie dadurch einen mächtigen Hebel haben, mit dem sie unerwünschte Mitbewerber oder unliebsame Anbieter oder Anwender aussperren können. Würde eine unabhängige Stelle die SecureBoot Schlüsselzertifizierung verantworten, hätte ich keinen faden Beigeschmack.

    Von einem Generalschlüssel habe ich bis jetzt noch nichts mitbekommen. Was aber nicht heißt, dass es so etwas nicht gibt. Wenn dem so ist, wäre das ganze Konzept für die Tonne und ich gebe Dir recht.

    Der wahrscheinlichere Fall, den ich mir vorstellen kann, ist: Anwender bootet sein verschlüsseltes System direkt in den Desktop (ohne Passwort / bzw. mit gespeichertem Passwort). Das System ist dann "offen" und vom TPM als "trusted" erkannt. Ich kann dann in dieser Session versuchen, den TPM Chip aunzugreifen. In diesem Beispiel müsste ich auf die Bequemlichkeit des Anwenders setzen.

    Das Szenario ist hier beschrieben.

    Der Punkt ist doch der:

    TPM und Verschlüsselung = gut

    Schlüssel außerhalb des Geräts zu lagern = schlecht

    Ein Schlüssel, der das Gerät verlässt ist der reinen Security-Lehre nach verbrannt. In der Cryprowelt gibt es das schöne Zitat "Not your keys, not your coins!". Das sollte hier auch gelten.

    Sicherheit auf Kosten von Komfort zu verschlechtern (Schlüssel bei einem Dienstleister zu hosten), bricht die Sicherheit auf und muss per se als unsicher eingestuft werden.

    Aber dafür kann man TPM nun keine Schuld geben, sondern sich an die eigene Nase fassen und Anbieter meiden, die das alleinige Halten des Schlüssels durch den Anwender nicht unterstützen.

    kim88

    Guter Punkt und gut nachvollziehbar.

    Vielleicht ist das Thema ein schönes philosophisches Fallbeispiel für die Stärken und Herausforderungen "diverser" (im Sinne "vielseitig" und "vielschichtig") Gesellschaften am Beispiel der Linuxcommunity. Je heterogener und freidenkender die Gesellschaft ist, umso schwieriger wird es fundamentale Reformen in ihr wachsen und gedeihen zu lassen und den Leuten Gewahr werden zu lassen, was eine gewinnbringende Neuerung / "Bereicherung" sein kann und was eine "böse" abzulehnende Neuerung / "Bedrohung" ist.

    Mit der Zeit wird sich das gewinnbringende durchsetzen - da bin ich mir ziemlich sicher. Nur braucht es halt seine Zeit. Artikel wie Deiner geben dabei die richtigen Impulse. :)

    Meine Kritik ist das Geräte mit vorinstalliertem Windows Bitlocker bereits aktiv haben, ohne das der Käufer, Nutzer etwas davon weiß. Wenn dann auch nicht mal ein Backup der Daten gemacht wurde kann es in der Tat zu Frustrationen kommen. Wüsste das der Kunde / Anwender bereist das die Festplatte verschlüsselt ist hätte man nach dem Erwerb einen Entschlüsselung Key generieren können. Leider wird das im Verkauf nicht kommuniziert weil auch der Vertrieb davon nichts weiß.

    Dem kann ich nur beipflichten. Im Privatbereich kann es für den IT-Laien wie z.B. meiner 76 jährigen Mutter eine böse Überraschung geben, wenn Windows kaputt gegangen ist und sie bzw. ihre zur Hilfe gerufenen Kinder im Supportfall nicht mehr an die physischen Daten herankommen, weil sie verschlüsselt sind. Hier wäre es gut, wenn Microsoft bei der ersten Anmeldung eines neuen Users eine Info ausgeben würde, dass dieser PC verschlüsselt ist, wie man als Anwender an den Recovery Key kommt und wie man ihn sichert.

    In Unternehmen sehe ich das hingegen nicht kritisch. Hier ist es die Kernaufgabe einer IT, sich um diese Belange zu kümmern. In einer ActiveDirectory-Landschaft lassen sich die Recovery Keys z.B. mit geringer Konfiguration komfortabel in dem AD Computerobjekten als Attribut speichern und im Supportfall kann der Helpdesk den Recovery Key für einen PC direkt aus dem ActiveDirectory auslesen. Wir machen das seit Win10 so und fahren echt gut damit.

    Ich glaube, Omas Linuxlaune spricht die Möglichkeit an, dass ein TPM Chip defekt geht und dann der mit dem Chip verschlüsselte Content verloren ist.

    Wir hatten vor vielen Jahren (ich rede jetzt so von vor 10 Jahren) in der Firma Malessen mit den damaligen Dell Latitude Laptopes. Diese Laptops hatten ab Werk TPM und wir nutzten Hardwareverschlüsselung der Festplatten über dieses Chip. Bei einem Mainboardtausch wegen Defekt (das war damals leider nicht selten) konnte dann die HD auf dem Rechner nicht mehr entschlüsselt werden.

    Damals gab es keinen Mechanismus wie z.B. Bitlocker, der ja einen Wiederherstellungsschlüssel mitbringt.

    Also sollte man eigentlich diese Distros eher meiden oder nicht?

    Das wäre sehr radikal, oder? Wenn die eigene Seeligkeit und das eigene Sicherheitsempfinden Secure Boot als unentbehrlich voraussetzen, dann könnte man das vielleicht.

    In meiner fast 25 jährigen Tätigkeit als IT-Admin bin ich weder mittelbar noch unmittelbar einen einen Security Breach geraten, der über das Vorhanden- oder nicht Vorhandensein von Secure Boot verursacht wurde. Phishing, Ransomware, die sich ins OS eingenistet hat etc., habe ich schon erlebt. Aber Malware, die auf so tiefer Ebene wie dem Bootprozess und dem Hardware-Layer ansetzt, habe ich noch nicht erlebt. Aber das ist natürlich meine rein subjektive Meinung. :)

    Grundsätzlich halte ich das für einen Fehler der Distributionen - aber es ist natürliche ihre Freiheit das so zu handhaben wie sie es für richtig halten.

    Besser kann man das nicht zusammenfassen. Dake dafür. :)

    Ohne jetzt der Linux Community zu nahe treten zu wollen und als "Nestbeschmutzer" beschimpft zu werden - ich glaube dass das "Mindset" der Community ein Faktor ist, der Secure Boot in den Distros nicht flächendeckend möglich macht. Was da stellenweise mit einer toxischen Arroganz reagiert wird lässt tief blicken - lies Dir alleine mal den verlinkten Manjaro Thread durch.

    Auf der anderen Seite kann ich den Standpunkt der OSS Enthusiasten nachvollziehen. Wenn Du der reinen Lehre von OSS folgst, ist ein Verfahren, wo alle Macht (der Zertifizierer) in der Hand eines Groß-Monopolisten liegt (Microsoft) und diese Institution eines Tages hypothetisch darüber entscheiden kann, wer mitspielen darf und wer nicht (indem z.B. die Zertifikate ungültig gemacht werden) wird Secure Boot niemals Option sein und dieses Feature als ein Gängelband, statt einem Sicherheits-Seil gebrandmarkt werden.

    Dieser Tipp von damals hat sich leider bis heute gehalten. Viele deaktivieren direkt Secure Boot bevor sie Linux Installieren, statt Linux einfach mit aktiven Secure Boot zu installieren. Obwohl ALLE Main-Stream Dsitributionen (Debian, Ubuntu, Linux Mint, Fedora, openSuse, etc) längst absolut keine Probleme mit Secure Boot hat.

    ...

    Daher eine bitte von mir an euch alle: Bitte gebt niemanden als ersten Tipp, dass er "Secure Boot" ausschalten soll. Es kann Situationen geben wo man Secure Boot ausschalten muss (z.b. wenn man Virtual Box verwendet, da das Kernel-Modul von Virtual Box nicht sginiert ist). Aber auch da könnte man vorher überlegen ob man vllt nicht besser mit KVM/QEMU arbeitet bzw. virt-manager und gnome-boxes, die dieses Problem nicht haben.

    Danke für Dein flammendes Plädoyer. Im Großen und Ganzen unterschreibe ich Deine Meinung.

    Hier ein "Fun-Fact" direkt von der System76 Support-Seite für Pop_OS!:

    Zitat

    Secure Boot

    Secure boot must be disabled before installing Pop!_OS. Secure boot can be disabled in the BIOS of most computers; however, the process to disable secure boot will vary by laptop and motherboard model.

    Oder bei Manjaro, wo es erst nach der Installation und dann nur mit hochgekrämpelten Ärmeln geht:

    Is there a plan to support secure boot in manjaro by default?
    I know there are ways to set it up after installation, but I wanted to know that is there any intention or interest in supporting it in manjaro out of the box?…
    forum.manjaro.org

    Beide Distros würde ich zu den "Großen" zählen. Bei meinem Laptop musste ich vor der Installation von Pop!_OS tatsächlich Secure Boot deaktivieren, um es überhaupt installieren zu können.