Der Sinn eines verifizierten Systemstart (engl. „verified boot“) ist sicherzustellen, dass beim Start Komponenten aus vertrauenswürdigen Quellen geladen werden und es Angreifern nicht gelingt, manipulativ in den Prozess einzugreifen. Grundsätzlich ist vieles davon Linux nicht fremd, aber wird zum Teil aktiv unterlaufen.

Einordnung und Kontext

Die Themen verifizierte Systemstart, Secure Boot und TPM beschäftigen mich momentan. Befasst man sich mit vollständig verschlüsselten Systemen, der zusätzlichen Bindung an TPM bzw. Secure Boot, zusätzlich gegeneinander durch Verschlüsselung abgeschirmten Home-Verzeichnissen und weiterführenden Fragen, wie der Sicherheit biometrischer Verfahren und welche zusätzlichen Schutzmaßnahmen durch zusätzliche Hardware-Tokes wie FIDO2 (YubiKey) möglich sind, dann ist der verifizierte Systemstart letztlich ein logisches weiteres Puzzlestück.

Natürlich handelt es sich dabei um „advanced“ Sachen. Wer sein System nicht verschlüsselt, andauernd irgendwelche Programme von Dritten herrunter lädt und sich Kernel aus irgendwelchen PPAs installiert, der hat dadurch überhaupt keinen Sicherheitsgewinn. Ich respektiere es auch, wenn man solche „Trusted Computing“-Konzepte ablehnt oder ihnen zumindest misstraut. Ich ermuntere dennoch dazu, hier nicht einfach irgendwas nachzuplappern, weil (insbesondere in der deutschen Community?) in dem Bereich viele urbane Legenden kursieren. Neben abstrakten Informationsquellen ist meine konkrete Arbeitsgrundlage für viele Experimente das Arch Linux-Wiki und das ist nun wirklich kein Vertreter von „Corporate Linux“.

Der Blick über den Tellerrand

Der verifizierte Systemstart ist dabei keinesfalls irgendwie exotisch. Systeme wie iOS oder Android haben das ebenso implementiert, wie Windows 11 oder macOS. Das Prinzip ist einfach: Es wird eine vollständige Vertrauenskette aufgebaut. Angefangen von einer vertrauenswürdigen (Hardware-)Wurzel, bei der jeweils eine geladene Stufe die nächste authentifiziert. Also von der Hardware, über den Bootloader zu den entsprechenden Systempartitionen bis hin zu den Benutzerdaten. Das entsprechende Verfahren kann z. B. hier für Android nachgelesen oder ist hier sehr anschaulich viel Windows 11 (vor allem Abbildung 1 für Leser ohne Lust auf langwierige technische Inhalte) dargestellt. Solche Verfahren können noch mit einem Rollback-Schutz und anderen Sachen kombiniert werden, aber das führt jetzt hier zu weit.

Was kann Linux theoretisch?

Folgende Boot-Abfolge kann Linux bzw professionelle Linux-Distributionen momentan theoretisch bieten:

• UEFI startet shim (was letztlich nur eine Zertifikatesammlung mit Signatur von Microsoft ist). Das kann in das s. g. „TPM boot measure“ (keine Ahnung, wie man das gut übersetzt?) einbezogen werden.
• Shim ruft den Bootloader (i. d. R. GRUB) auf, der mit einem Schlüssel des Distributors signiert ist. GRUB kann theoretisch in das „TPM boot measure“ einbezogen werden.
• Alternativ ist theoretisch der direkte Start über ein Unified Kernel Image möglich.
• Der Bootloader ruft den Kernel auf und übergibt initrd. Der Kernel ist durch den Distributor signiert, initrd ist nicht signiert oder validiert. Kernel und initrd können theoretisch in „TPM boot measure“ einbezogen werden.
• Bei verschlüsselten Systemen fragt initrd nun nach dem Passwort für die verschlüsselte Root-Partition. Es erfolgt keine Verifikation, ob initrd manipuliert oder ähnliches wurde. Es erfolgt der Übergang ins Root-Dateisystem. Die per LUKS verschlüsselte root-Partition kann an den TPM Secure Boot Status gebunden werden.
• Abschließend erfolgt eine Anmeldung des Benutzers in der Loginmaske der Desktopumgebung. Die Daten sind bereits vorher entschlüsselt, sofern der Administrator nicht eine individuelle Konfiguration mit systemd-homed, eCryptFS oder separaten LUKS-Partitionen pro Benutzer eingerichtet hat.

Was macht Linux faktisch?

• Secure Boot wurde deaktiviert, weil man irgendwo gelesen hat, dass man das tun sollte.
• TPM ist ebenfalls deaktiviert, auf der Modul-Blacklist oder wird einfach nur nicht beachtet. Selbst wenn TPM nicht deaktiviert ist, macht eine Einbeziehung in GRUB oder initrd momentan wegen des unzureichenden Implementierungsgrades keinen Sinn.
• GRUB lädt ein nicht signiertes initrd und einen nicht signierten Kernel.
• Bei verschlüsselten Systemen fragt initrd nun nach dem Passwort für die verschlüsselte Root-Partition. Es erfolgt keine Verifikation, ob initrd manipuliert oder ähnliches wurde. Es erfolgt der Übergang ins Root-Dateisystem.
• Abschließend erfolgt eine Anmeldung des Benutzers in der Loginmaske der Desktopumgebung. Die Anmeldung ist Makulatur, da die Daten bereits vorher entschlüsselt wurden, daher erfolgt oft ein einfacher Autologin.

Ist das ein Problem?

Das hängt wie bereits oben geschildert, von der Frage ab, welches Sicherungsbedürfnis man hat. Nutzt man sowieso keine Verschlüsselung, braucht man weitere Schutzmaßnahmen eh nicht. Insbesondere auf Entwicklungssystemen ohne schutzwürdige Daten verzichtet man häufiger auf Verschlüsselung. Hier kann man dann also auch nach Belieben mit nicht signierten Kernel, selbst gebauten Modulen etc. arbeiten.

Nutzt man eine Verschlüsselung nur, um Gelegenheitsblicke von neugierigen Kollegen, Freunden oder Familienmitgliedern zu entgehen, dann benötigt man weiterführende Maßnahmen ebenso eher nicht. Es sei denn man hat eine Tochter, die gerade an einer Bewerbung für den Geheimdienst als Hackerin arbeitet.

Hat man aber ein Schutzbedürfnis für sich selbst erkannt und nutzt ein vollständig verschlüsseltes Betriebssystem, um seine Daten sicher vor den Blicken professioneller Angreifer zu schützen, dann hat der aktuelle Zustand erhebliche Schwachstellen und einige zumindest seltsame Aspekte:

• Man startet ein verschlüsseltes System von einer i.d.R. unverschlüsselten boot-Partition, ohne zu prüfen, was eigentlich mit initrd und Kernel passiert ist und gibt dort das Passwort ein. Dieses Problem wird aktuell gelöst durch eine verschlüsselte Boot-Partition, was aber GRUB immer mehr aufbläht und noch unwartbarer macht als es eh schon ist.
• Das System lässt sich einfach kopieren und danach mit Brute Force so lange „quälen“ bis man drin ist. Die Verschlüsselung mit LUKS kennt dagegen keine Schutzmaßnahmen und verhindert das auch nicht.
• Man gibt ein Passwort beim Start ein, um das Betriebssystem zu entschlüsseln und entschlüsselt nebenbei die Benutzerdaten. Der eigentliche Benutzerlogin ist nur Makulatur und weil das den meisten Anwendern klar ist, überspringen sie oft auch den Benutzerlogin per Autologin.
• Benutzerdaten sind bei Multiuser-Systemen nur mit den UNIX-Rechten gegeneinander abgeschirmt und je nach Distribution nicht mal das.

Schlussbemerkung

Das Thema ist perspektivisch kein „Entweder-Oder“, sondern ein „Und“. So wie in der Vergangenheit immer die Möglichkeit bestand, nicht verschlüsselte Systeme zu nutzen, obwohl die Distributionen die LUKS-Verschlüsselung zunehmend prominenter in den Installationsroutinen platzierten, so wird auch der verifizierte Startvorgang Einzug halten für jene, die es benötigen oder dies zumindest glauben bzw. wohl eher fürchten. Alle anderen können, aber müssen dies nicht nutzen. Unstrittig ist jedoch, dass man aktuell ein bisschen hinter den anderen Betriebssystemen her rennt und nicht mal die Möglichkeiten ausreizt, die man schon hat. Spannend dürfte sein, was Enterprise-Distributionen wie SUSE Linux oder Red Hat Enterprise Linux hier in den nächsten Jahren umsetzen. Bei beiden Firmen ist man an den Themen dran.

Das war (voraussichtlich) der letzte Artikel zu diesem Thema für die nächste Zeit. Alle, die von Secure Boot, TPM, GRUB, verified Boot & Co schon genervt sind, können also entspannt in die Zukunft schauen 😉

Der Artikel Verifizierter Systemstart (Verified Boot) – Der Stand bei Linux erschien zuerst auf [Mer]Curius

Die Linux-Community, ihre Eigenheiten und komischen Ausprägungen beschäftigen mich schon länger. Das dürfte für viele Leser hier nichts Neues sein. Momentan frage ich mich aber, ob das Problem nicht sehr spezifisch die deutschsprachige Linux-Community betrifft?

Meine Beobachtung zu den Unterschieden bei Wikipedia hatte ich kürzlich schon mal hier dargelegt. Nun bin ich aufgrund eines anderen Themas auf die systemd-Artikel bei Wikipedia gestoßen. Schauen wir uns mal drei Artikel an, deren Sprache ich beherrsche:

• Deutsche Wikipedia: systemd
• Englische Wikipedia: systemd
• Spanische Wikipedia: systemd

Die Unterschiede sind eklatant. Das ist keineswegs ein „Wikipedia-Phänomen“, denn diese Artikel schreiben Prinzip-bedingt Autoren mit Affinität zum Thema Linux bzw. Mitglieder einer weiter gefassten „Linux-Community“.

Der englischsprachige Artikel ist sehr umfassend, was vermutlich an der größeren Autoren- und Leserschaft liegt. Es geht um Geschichte, technisches Design, die zugehörigen Komponenten, die Verbreitung unter den verschiedenen Linux-Distributionen und ganz am Schluss kommt die Rezeption bzw. Kritik an systemd, sowie alternative Implementierungen. Die spanischsprachige Wikipedia orientiert sich an der englischsprachigen Wikipedia, hat aber einen längeren Teil mit Anleitungscharakter und nur einen kurzen Kritikteil.

Bei der deutschen Wikipedia geht es ganz kurz um Geschichte und Funktion und dann auf knapp 7000 Zeichen um die Kritik an systemd. Dazu ist die Auswahl der Meldungen verglichen mit der englischsprachigen Version höchst tendenziös, da immer nur die Kritik und selten die Entscheidungen und Problemlösungen thematisiert werden. Repliken auf diese Kritik (Lennart Poetterings „The biggest Myths“), die in der englischsprachigen Wikipedia erwähnt werden, finden in der deutschsprachigen Wikipedia keinen Widerhall.

Der englischsprachige Leser hat am Ende der Lektüre einen guten Überblick über Geschichte, Design, Funktionen und Kritik an systemd. Dem deutschsprachigen Leser bleibt der Eindruck, eine katastrophale Technologie hätte sich irgendwie durchgesetzt.

Läuft da was falsch bei der deutschsprachigen Linux-Community? Ist das ein spezifisches Wikipedia-Problem? Mich würden da auch Meinungen bzw. Kommentare von Lesern interessieren, die vielleicht auch in anderssprachigen Linux-Communitys unterwegs sind.

Der Artikel Sonderwege der deutschsprachigen Linux-Community? erschien zuerst auf [Mer]Curius

Verschlüsselung für mobile Betriebssystem wie Android ist trivial und mit wenigen Einstellungen aktiviert. Wegen einiger Änderungen in der Vergangenheit gibt es für Android jedoch viele veraltete Informationen.

Verschlüsselung ist bei Desktop-Betriebssystemen wie Windows, Linux oder macOS eine peinliche Leerstelle. Obwohl es für alle drei Systeme leistungsfähige Lösungen gibt, verzichten alle Hersteller auf eine standardmäßige Aktivierung und Bewerben diese auch nicht aktiv. Während Windows und macOS sich wenigstens noch nachträglich verschlüsseln lassen, schauen Linux-Nutzer in die Röhre, wenn sie bei der Installation die entsprechenden Optionen nicht gesetzt haben.

Nicht so bei mobilen Betriebssystemen. Google und Apple haben in ihre Betriebssysteme für Tablets und Smartphones selbstverständlich leistungsstarke Verschlüsselungsmethoden implementiert, die im Hintergrund automatisch aktiviert werden, sobald der Anwender die Codesperre (sowie ggf. biometrische Verfahren) aktiviert. Bei Android hat Google hier in der Vergangenheit einige Änderungen vorgenommen, weshalb viele Berichte dazu veraltet sind und teils unverständliche Kürzel kursieren.

FDE: Full Disk Encryption

Die FDE-Verschlüsselung stand am Anfang. Technisch gesehen handelte es sich um eine Festplattenverschlüsselung auf Basis von dm-crypt. Insbesondere bei diesen tieferen Bereichen von Android merkt man oft die Linux-Basis, denn letztlich ist das nicht viel anderes als die LUKS-Vollverschlüsselung bei Linux.

Technisch war das natürlich etwas aufwendiger. Die Verschlüsselung erfolgte in der üblichen Blockdevice-Methode, bei der die gesamten Userdata-Partition verschlüsselt wurde. Die Verschlüsselung erfolgte mit einem einzigartigen Schlüssel, der gleichermaßen an den Benutzer-PIN gebunden und mittels TEE signiert wurde. Mit diesem Schlüssel wurden jene Bereiche verschlüsselt, in denen Android Benutzerdaten speichert.

Es gab nur ein grundlegendes Problem. Bei einem Neustart des Android-Smartphones waren viele Funktionen nicht verfügbar, bevor der Anwender seine Passphrase eingegeben hatte. Beispielsweise Wecker oder auch Telefonanrufe. Das war natürlich für ein Smartphone-Betriebssystem keine zufriedenstellende Lösung.

Diese Lösung steht nach einer längeren Übergangsphase nicht mehr zur Verfügung. Android ab Version 10 nutzt nur noch die FBE-Methode.

FBE: File Based Encryption

Um diese Beschränkungen zu beheben, hat Google ab Android 7 die dateibasierte Verschlüsselung (FBE) eingeführt. Dabei handelte es sich um eine Neuentwicklung auf Basis des für Android verwendeten Dateisystems ext4. Die Umstellung hat je nach OEM-Hersteller etwas gedauert, weshalb zwischen den Versionen 7 und 9 die Verschlüsselung je nach Konfiguration und Hersteller unterschiedlich funktioniert hat, aber heute ist FBE die Standardverschlüsselung.

Ein netter Nebenaspekt: Diese Erweiterung des ext4-Dateisystems zog mit Kernel 4.1 bzw. 4.6 (fscrypt) direkt upstream ein und kommt dadurch allen Linux-Anwendern zugute. Die Adaption verzögerte sich hier etwas, aber mit systemd-homed steht nun erstmals eine praktikable Umsetzung für den Linux-Desktop zur Verfügung.

Technisch gibt es zwei Bereiche. Den Standarspeicherplatz (Credential Encrypted = CE), der erst nach der Entschlüsselung zur Verfügung steht und den sogenannten Device Encrypted (DE) Speicher, der während des Direct Boot-Verfahrens Anwendungen ermöglicht mit begrenztem Datenzugriff zu funktionieren.

Anfänglich war ein Nachteil der FDE-Methode die fehlende Verschlüsselung der Metadaten (Berechtigungen, Dateigröße, Verzeichnis-Layout etc.). Diese berechtigte Kritik – z. B. in diesem Short Paper – kann man auch heute noch häufiger lesen, wenn es um Android-Verschlüsselung geht. Das Problem hat Google in Android 9 behoben und es ist somit nicht mehr aktuell.

Der wesentliche Unterschied für den Anwender: Mit FBE gesicherte Android-Geräte booten ganz normal in den Sperrbildschirm und bieten dort auch vor der Entschlüsselung durch den Anwender Funktionalitäten wie Anrufe, Wecker etc.

Aktivierung durch den Anwender

Sobald der Anwender einen PIN, eine Passphrase und/oder biometrische Merkmale hinterlegt hat, ist die Verschlüsselung aktiviert. Normalerweise geschieht dies bereits bei der Initialisierungsroutine. Anwender müssen mehrfache Warnungen überspringen, um ihre Geräte ohne entsprechenden Schutz nutzen zu können. Das ist meiner Ansicht nach die richtige Vorgehensweise. Überprüfen lässt sich der Status in den Einstellungen und Sicherheit und dort in Verschlüsselung und Anmeldedaten.

Hier ist wie aus dem folgenden Screenshot bei „Smartphone verschlüsseln“ der Status Verschlüsselt zu sehen. Weitere Einstellungsmöglichkeiten oder Handlungsbedarf bestehen nicht.

Der Artikel Verschlüsselung unter Android – Von FDE zu FBE erschien zuerst auf [Mer]Curius

Do, 10. Februar 2022, Lioh Möller

In den vergangenen Wochen haben wir unterschiedliche Linux-Distributionen auf Einsteigertauglichkeit getestet. Dabei kamen zuvor definierte Bewertungskriterien zum Einsatz.

Folgende Distributionen konnten wir in unsere Tests einbeziehen:

• Fedora Silverblue
• Debian GNU/Linux
• Manjaro
• Siduction
• Linux Mint LMDE
• openSUSE Leap
• Ubuntu 22.04 LTS (pre-release)
• openSUSE Tumbleweed
• ZorinOS

Natürlich stellt die Auswahl nur einen Bruchteil der verfügbaren Linux-Derivate dar. Dennoch vermittelt sie ein gutes Gesamtbild über den aktuellen Stand der Entwicklungen.

Grundsätzlich lassen sich die Distributionen in drei Bereiche aufteilen. Dazu gehören einerseits klassische Ansätze wie bei openSUSE Leap, Ubuntu LTS, Debian GNU/Linux oder ZorinOS, andererseits Rolling-Release Lösungen wie Siduction, Manjaro oder openSUSE Tumbleweed. Fedora Silverblue verfolgt als einzige Immutable Distribution in unseren Tests neue Wege und bietet aufgrund der Stabilität und reibungslosen Updatefähigkeit ein ideales System für Einsteiger.

Davon unabhängig eignen sich alle vorgestellten Lösungen gut für einen ersten Kontakt mit dem Freien Betriebssystem. Teilweise unterstützen Assistenten oder Handbücher bei der Einarbeitung.

Fast alle getesteten Distributionen sind mit den drei grossen Desktop-Umgebungen, KDE-Plasma, GNOME-Shell und Xfce verfügbar. Obwohl wir nur jeweils eine Desktop-Variante getestet haben, sollte diese nicht den Ausschlag für die Wahl eines Einsteigers geben. Alle drei Umgebungen sind gut für Um- oder Einsteiger geeignet. Hier liegt es am persönlichen Geschmack, was einem besser gefällt.

Möchte man ein System haben, welches man einfach nur benutzen kann, ohne sich tiefer mit den Konzepten von Linux auseinanderzusetzen, ist Fedora Silverblue oder ZorinOS eine gute Wahl. Siduction hingegen bietet ausführliche Dokumentationen und Anlaufstellen bei Fragen an. Ambitionierte Einsteiger können zu Manjaro oder openSUSE Tumbleweed greifen. Und wer Linux von der Basis ab kennenlernen möchte, dem sei ein Blick in den Slackware basierten Linux-Kurs empfohlen.

Die MZLA Technologies Corporation hat mit Thunderbird 91.6 ein planmäßige Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.6

Mit dem Update auf Thunderbird 91.6 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken. Darüber hinaus bringt das Update diverse Fehlerbehebungen der Versionsreihe 91, welche sich in den Release Notes (engl.) nachlesen lassen.

Der Beitrag Thunderbird 91.6 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Anlässlich des gestrigen Releases von KDE Plasma 5.24, das die Möglichkeit Fingerabdrücke zur Authentifizierung einzusetzen, offiziell integriert möchte ich hier noch mal explizit davor warnen. Erstens weil biometrische Daten nicht zur Authentifizierung geeignet sind und zweitens weil Linux nicht die sichere Infrastruktur dafür bietet.

Ich hatte vor etwas mehr als einem Jahr, als die Bestrebungen Fahrt aufnahmen, bereits vor dieser Methode gewarnt und möchte das hier noch mal aufgreifen. Biometrische Daten sind nicht nur ungeeignet zur Authentifizierung, sondern Linux bietet nicht die notwendige Infrastruktur, um solche Daten sicher abzulegen. Die Implementierung in Linux ist ein einziges Sicherheitsrisiko und Datenverlust eine plausible Möglichkeit. Nur weil etwas freie Software ist, darf man dem nicht blind vertrauen.

Biometrische Daten zur Authentifizierung

Der erste Punkt ist natürlich, dass man besser keine biometrischen Daten zur Authentifizierung nutzt. Sie vermitteln ein falsches Sicherheitsgefühl und beim Verlust lassen sie sich nicht ersetzen. Kursiert der eigene Fingerabdruck irgendwo, kann man sich schlecht einen neuen generieren lassen. Andererseits nutzten vor dem Aufkommen solcher Verfahren viel zu wenige Anwender sichere PINs oder Passwörter für ihre mobilen Geräte. Entweder schützte man diese gar nicht oder mit simplen Wischmustern. Fingerabdruck oder Gesichtserkennung bieten hier durchaus einen Mehrwert. Mehrwert aber nur, wenn dieser Fingerabdruck sicher gespeichert wird.

Auf keinen Fall mit Linux!

Die größte Gefahr besteht darin, dass der Fingerabdruck verloren geht bzw. gestohlen wird. Google, Apple, Microsoft – sie alle sind sich dessen bei biometrischen Daten bewusst. Alle drei Anbieter haben in ihren Geräten sogenannte Sicherheitschips verbaut (Apple: Secure Enclave; Google: Titan M; Microsoft: TPM) mit denen sie solche Daten schützen. Die Daten der Fingerabdrücke können nicht vom Gerät exportiert werden.

Irgendwer kommt jetzt bestimmt wieder mit proprietärem Code und proprietärer Hardware, der man nicht vertrauen kann. Das ist Mist, mit dem man den desolaten Zustand unter Linux schönredet! Jeder Programmierer macht Fehler, kein Code ist perfekt, manchmal muss man durch die Architektur neue Sicherheitsmethoden einbauen.

Google, Apple & Co haben diese Verfahren sehr effizient eingesetzt, bisher sind trotz milliardenfacher Nutzung keine Daten abhandengekommen. Zudem speichern diese Firmen die Fingerabdrücke nicht als Bild, sondern als Hashwert. Die Apps bekommen durch das ausgefeilte Berechtigungssystem keinen direkten Zugriff auf den Fingerabdruck selbst, sondern führt nur einen Abgleich mit dem Hash durch – grob vereinfacht erklärt. Das sind die technischen Standards zur Verarbeitung biometrischer Daten und sie sind gerade so ausreichend (eigentlich sollten wir gar keine biometrischen Daten verarbeiten!)

Linux kann gar nichts davon! Hinter solchen Frontends wie bei Plasma kommt fprint zum Einsatz, die Authentifizierung erfolgt über PAM. Linux kann momentan noch nicht ausgreift und flächendeckend mit Sicherheitschips umgehen. Die Daten werden somit einfach im System gespeichert (wo auch sonst bei den aktuellen Möglichkeiten?) und können von dort auch mit entsprechenden Rechten exportiert werden.

Und da kommt mir bitte keiner mit dem tollen Berechtigungssystem von UNIX bzw. Linux. Das ist uralt und garantiert nicht für so hoch sensible Daten entworfen worden. Ein kritischer Fehler und sudo, PolKit oder wo auch immer und und wir sitzen richtig im Dreck! Berechtigungskonzepte für Apps haben wir jenseits von Flatpak gar nicht und noch immer kommen genug Helden auf die Idee, grafische Programme mit Administratorrechten zu starten. KDE hat das gerade erst wieder offiziell für Dolphin möglich gemacht.

Ich finde es in Ordnung, wenn Linux-Anwender sagen, die misstrauen Sicherheitschips wie TPM, aber dann lassen sich halt manche Funktionen wie ein biometrisches Authentifizierungsverfahren nicht umsetzen. Man kann nicht alles haben!

Schlussbemerkung

Dieser Text ist sehr hart und sehr plakativ geschrieben und man könnte zu vielen Punkten mehr schreiben und manches differenzieren. Aber anlässlich der Veröffentlichung von KDE Plasma 5.24 gestern, sehe ich mich in der Pflicht hier eindrücklich zu warnen. Es ist schön, wenn Entwickler sich mit so etwas befassen und hier grundlegende Methoden entwickeln. Wenn ein System aber nicht die geeignete Hardware-Infrastuktur hat, dann kann man an einem gewissen Punkt nicht weiter arbeiten.

Wenn Microsoft, Apple oder Google biometrische Authentifizierungsmaßnahmen so stümperhaft umgesetzt hätten, wäre jeder IT-Experte in jeder denkbaren Weise über sie hergefallen. Bei Linux ist das wieder okay, weil es ja freie Software ist und so. Nein, einsehbarer Code schützt nicht vor allem! Wenn hier Daten verloren gehen, kommen Heartbleed, Boothole und Debians OpenSSL-Fiasko zusammen. Will sagen: Dann ist der Ruf von Linux endgültig im Eimer!

---

Nachtrag 09. Februar 2022:

Anscheinend bin ich mit meiner Meinung hier wenigstens nicht ganz alleine. Durch einen Kommentar auf Linuxnews bin ich auf diesen Bugreport bei Debian aufmerksam geworden, der auf eine entsprechende Diskussion im GitLab von fprint verweist. Bitte folgenden Kommentare zur Kenntnis nehmen:

There are no short-term plans to fixing this. Any attempts at encrypting the fingerprints would just be security through obscurity as the decryption would need to be made available to fprintd and would therefore be available to other processes.

The only way to currently safeguard the fingerprints is to run with SELinux, AppArmor or another LSM enabled, and made sure that only the fprintd binary has access to those saved fingerprints.

Mal abgesehen davon, dass ich selbst die dort angedachten Schutzmaßnahmen für unzureichend halte, nutzt nur Fedora / RHEL SELinux in einer ausreichenden Konfiguration.

Folgende Aussage des Entwicklers bitte sich ebenfalls Gemüte führen:

I think we might entertain such ideas if anyone can actually point to proper research that shows it is feasible. Before then, I will continue to assume that anything like that is impossible.

Bei diesem Problembewusstsein frage ich mich, ob Debakel wirklich noch die ausreichende Beschreibung ist?

Der Artikel Warnung: Nutzt keine Fingerabdruck-Authentifizierung mit Linux! erschien zuerst auf [Mer]Curius

Mi, 9. Februar 2022, Ralf Hersel

"Zorin OS ist eine auf Ubuntu basierende Linux-Distribution, die speziell für Linux-Neulinge entwickelt wurde. Sie hat eine Windows-ähnliche grafische Benutzeroberfläche und viele Programme, die denen von Windows ähneln. Zorin OS wird auch mit einer Anwendung geliefert, mit der Windows-Programme ausgeführt werden können. Das Ziel der Distribution ist es, eine Linux-Alternative zu Windows zu bieten und Windows-Benutzern alle Funktionen von Linux ohne Komplikationen zur Verfügung zu stellen", besagt die Selbstbeschreibung von Zorin OS.

Für diesen Test habe ich mich für die Variante 'Zorin OS 16 Core' entschieden. Neben dieser gibt es auch eine Pro- und eine Lite-Version. Die Unterschiede werden auf der Download-Seite erklärt. Kurz gesagt, Core verwendet die GNOME-Shell als Desktop-Umgebung, Lite nimmt Xfce und Pro bringt unter anderem einen Desktop-Layout Switcher mit und kostet 39 Euro.

Die Version 16 stammt von August 2021, hat einen 5.13er Kernel, Gnome 3.38, Python 3.5, LibreOffice 7.1 und basiert auf Ubuntu 20.04.3 LTS. Über Zorin OS haben wir bereits des Öfteren geschrieben; schaut in den Artikelindex, um die bisherigen Berichte zu lesen.

Installation

Die ISO-Datei ist 2.7 GB gross und kann von der Download-Seite bezogen werden. Da Zorin auf Ubuntu beruht, gibt es zum Installationsprozess nicht viel zu sagen. Er funktioniert und sieht so aus, wie man ihn von fast allen Ubuntu-Derivaten kennt.

Eine Sache hat mich dennoch überrascht, die 'Volkszählung'. Diese seltsam übersetzte Option für die Telemetrie stammt auch von Ubuntu und ist als Opt-out ausgelegt. Im Gegensatz zum Original gibt es während des Installationsprozesses keine Zorin-eigene Slide-Show. Stattdessen sieht man nur das Zorin-Logo.

Ich gebe 4 von 5 Punkten, wegen der 'Volkszählung' und der verpassten Chance, die Anwenderin während der Installation zu informieren/unterhalten.

Einführung

Nach dem ersten Start sieht man die stark modifizierte GNOME-Desktop-Umgebung, die (für meinen Geschmack) sehr gut aussieht. Eine Begrüssung oder Einführung gibt es leider nicht. Der Desktop bietet zwar ein modernes Design, folgt aber dem klassischen Bedienkonzept. Es gibt ein Panel mit Menü, Favoriten-Apps und den System-Tray.

Wie man im Screenshot sehen kann, sieht alles sehr klar und aufgeräumt aus. Im Panel befinden sich: Menü, Desktop-Overview, Firefox, Dateien und der Software-Manager. Im System-Tray geht es auch sauber zu: Lautstärke, Netzwerke, Einstellungen, An/Aus sind in einem Menü vereint. Rechts daneben steht der Kalender.

4 von 5 Punkten wegen der fehlenden Begrüssung und Einführung.

Vollständigkeit

Die Software-Ausstattung (im Menü) sieht folgendermassen aus:

• Büro: LibreOffice, Evolution, GNOME-Kalender und -Kontakte
• Grafik: Eye of GNOME, GNOME-Fotos, GIMP
• Hilfsprogramme: diverse, aber nicht zu viele
• Internet: Firefox, Remmina
• Multimedia: Brasero, Pitivi, Cheese, Rhythmbox, Sound Recorder, Totem
• Spiele: Solitaire, Mahjongg, Minen, Quadrapassel, Sudoku
• Systemwerkzeuge: diverse, aber nicht zu viele
• Zubehör: Aufgaben, Dateien, Karten, Text-Editor, Uhren, Wetter

Die Wahl der vorinstallierten Apps gefällt mir sehr gut; sie stellt eine gute Balance zwischen Notwendigem und Überfrachtung dar.

Das Software-Center bindet die Repositories: main, universe, restricted und multiverse ein. Ausserdem werden eine ganze Reihe von Zorin-eigenen PPAs geladen. Flatpaks und Snap-Pakete stehen ebenfalls zur Verfügung, wobei man die Einstellungen dafür in den Optionen von GNOME-Software nicht findet.

Bei den Einstellmöglichkeiten findet man die nicht-modifizierten GNOME-Settings, das Werkzeug zur GNOME-Optimierung (Tweak-Tool) fehlt, dafür gibt es die Zorin-Appearance mit Optionen für das Desktop-Konzept, Farb-Themen und weiteren Einstellungen. Das ist sehr Einsteiger-freundlich umgesetzt.

Ich gebe 5 von 5 Punkte.

Stabilität

Machen wir es kurz: Ubuntu 20.04 LTS. 5 von 5 Punkten.

Vorkonfiguration

Aus den vorherigen Kapiteln kann man bereits herauslesen, dass die Konfiguration von Zorin OS sehr gut gelungen ist. Das Design und die Benutzerfreundlichkeit schaffen den schwierigen Spagat zwischen modern, funktional, einfach zu bedienen, nicht überlastet, aber auch nicht zu sehr vernagelt. Meiner Meinung nach gehört das zu den Hauptaufgaben einer GNU/Linux-Distribution, denn, Kernel, Systemsoftware, Pakete und Desktops können alle Distros zusammenstellen; die hohe Kunst besteht in der Ausgewogenheit. Diese gelingt Zorin wie kaum einer anderen Distribution.

Klare 5 von 5 Punkten.

Update-Prozess

Machen wir es nicht ganz so kurz wie bei der Stabilität: der Ubuntu Update-Prozess ist bekannt und etabliert. Die Aktualisierungs-Einstellung, welche aus dem Software-Center heraus erreicht werden können, sind minimalistisch. Hier gibt es nur die Optionen 'Automatische Updates' und 'Benachrichtigungen bei eben diesen'; beide Optionen sind eingeschaltet. In der Aktualisierungsverwaltung können beliebige Quellen hinzugefügt und viele weitere Einstellungen gemacht werden. Es gibt keine Optionen zu Flatpaks und Snaps; für die Einsteigerin mag das aber genau das Richtige sein.

Ein Check im Terminal ergab, dass keine Snap-Pakete vorhanden sind und für Flatpaks nicht einmal die Basis installiert ist. Zu Testzwecken habe ich TextSnatcher aus dem Software-Center installiert; die App ist ein Flatpak. Wie erwartet, werden dabei zuerst einmal alle Flatpak-Voraussetzungen installiert; was in meinem Test sehr lange dauerte. Solange möchte kein Einsteiger warten. Hier wäre es besser gewesen, die Flatpak-Basis in der Distro bereitzustellen, insbesondere, da das Software-Center Flatpaks anbietet.

Dafür gebe ich 4 Punkte.

Bewertung

Kriterium	Bewertung (max. 5)
Installation	🏆️🏆️🏆️🏆️
Einführung	🏆️🏆️🏆️🏆️
Vollständigkeit	🏆️🏆️🏆️🏆️🏆️
Stabilität	🏆️🏆️🏆️🏆️🏆️
Vorkonfiguration	🏆️🏆️🏆️🏆️🏆️
Update-Prozess	🏆️🏆️🏆️🏆️
Summe	27

Fazit

'Zorin OS 16 Core' ist einer der Einsteiger-freundlichsten Distributionen, die ich bisher gesehen habe.

Zorin OS mit dunklem Thema

Obwohl ich bei den Kriterien Installation, Einführung und Update-Prozess jeweils einen Punkt vom Maximalwert abgezogen habe, ist Zorin ein Tipp für Einsteiger:innen in die wunderbare GNU/Linux-Welt. Diese Distribution schafft eine Ausgewogenheit, die ich selten gesehen habe. Zorin ist einerseits modern und schick beim Erscheinungsbild, holt den Anwender aber beim Bedienkonzept dort ab, wo er sich auskennt, nämlich bei MS-Windows.

Da Zorin 16 auf Ubuntu 20.04 aufbaut, ist damit zu rechnen, dass es in diesem Jahr eine neue Version geben wird, die auf Ubuntu 22.04 LTS setzt, und damit auch ein paar der Neuerungen von GNOME 42 abbekommen wird.

Download: https://zorin.com/os/download/

Mozilla hat Firefox 97 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Neue Farbgebungen für Firefox

Bereits jetzt nutzen mehr Nutzer ein farbiges Theme als das mit Firefox standardmäßig ausgelieferte dunkle Theme oder auch Alpenglow, das optionale Design, welches seit Firefox 81 zusätzlich ausgeliefert wird. Dafür bietet Mozilla auf seiner Erweiterungs-Plattform addons.mozilla.org eine Auswahl von zig tausenden Themes an.

Um noch mehr Nutzer auf diese Möglichkeit der Anpassung aufmerksam zu machen, hatte Mozilla Firefox 94 und folgende Versionen mit 18 zusätzlichen Themes, sogenannten Farbgebungen, ausgeliefert, welche mit dem heutigen Tag ausgelaufen sind und nicht mehr zur Auswahl stehen. Wer sich für eine dieser Farbgebungen entschieden hatte, kann diese aber noch weiterhin nutzen.

Mit Firefox 97 liefert Mozilla dafür sechs ganz neue Farbgebungen aus – auch diese sind wieder zeitlich limitiert verfügbar.

Außerdem zeigt die Add-ons-Verwaltung deaktivierte Theme nicht länger blasser an, womit die Vorschaubilder repräsentativer sind, und fügt auch kein „(deaktiviert)“ mehr hinter den Namen an. Dass Themes deaktiviert sind, wird ohnehin durch die entsprechende Überschrift klar.

Verbesserungen der Entwicklerwerkzeuge

In den Entwicklerwerkzeugen erlaubt der Inspektor bei gedrückter Shift-Taste jetzt auch die Auswahl von Elementen, welche aufgrund einer pointer-events: none-Regel ansonsten nicht auswählbar wären.

Das Farbpipette-Werkzeug funktioniert jetzt auch auf Websites, bei denen eine Content Security Policy (CSP) zuvor verursachen konnte, dass das Werkzeug nicht funktionierte.

Sonstige Neuerungen von Firefox 97

Für die Darstellung von Scroll-Leisten nutzt Firefox unter Windows jetzt den neuen Stil von Windows 11.

Unter macOS wurden Verbesserungen beim Laden von System-Schriften vorgenommen, welche unter bestimmten Voraussetzungen in einem schnelleren Öffnen und Wechseln von Tabs resultieren.

Die Verwendung der „Zum Tab wechseln“-Funktion in der Adressleiste beeinflusst jetzt auch die Gewichtung der Adressleisten-Vorschläge, so dass ein Häufiges Verwenden dieser Funktion für eine bestimmte Seite dafür sorgen kann, dass diese in den Vorschlägen zukünftig höher erscheint.

Die Passwortverwaltung unter about:logins hat eine verbesserte Tastatur-Steuerung erhalten (Pfeil rauf / runter zum Wechseln des Eintrags, Enter zum Auswählen, ESC zum Leeren des Suchfelds). Außerdem wurde die Performance des CSV-Imports von Zugangsdaten (kann in about:config via signon.management.page.fileImport.enabled aktiviert werden) signifikant verbessert.

Hardware-WebRender ist jetzt auch auf Systemen mit Lucienne-Chip von AMD standardmäßig aktiviert.

Die Option print.tab_modal.enabled, um den alten Drucken-Dialog, welcher in Firefox 86 vor knapp einem Jahr ersetzt wurde, wieder zu aktivieren, wurde entfernt. Netzwerk-Drucker, die von Firefox bislang nicht angezeigt worden sind, werden jetzt angezeigt, sofern diese innerhalb einer bestimmten Zeit gefunden werden.

Das Problem, dass auf YouTube bei Verwendung der Textsuche die Positionen der Suchergebnisse neben der Scroll-Leiste nicht angezeigt worden sind, gehört der Vergangenheit an.

Verbesserungen der Webplattform

Die CSS-Einheiten cap und ic werden ab sofort für Längenangaben unterstützt, außerdem die @-Regel @scroll-timeline und die animation-timeline-Eigenschaft. Die Eigenschaft color-adjust wurde umbenannt in print-color-adjust. Neu ist auch die Unterstützung von @layer sowie die Unterstützung für die Eigenschaft scrollbar-gutter.

In SVG-Grafiken kann das d-Attribut jetzt auch via CSS gesteuert werden.

Eine Übersicht über alle Verbesserungen der Webplattform sowie Verbesserungen für WebExtension-Entwickler gibt es wie immer in den MDN web docs.

Geschlossene Sicherheitslücken

Auch in Firefox 97 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 97 daher für alle Nutzer dringend empfohlen.

Dazu kommen wie immer weitere Fehlerbehebungen sowie sonstige Verbesserungen unter der Haube dazu.

Der Beitrag Mozilla veröffentlicht Firefox 97 erschien zuerst auf soeren-hentzschel.at.

Zu einem guten Smart Home gehört natürlich auch eine schöne „Kommandozentrale“. Obwohl das Haus ja schlau ist und alles selbst entscheiden soll, möchte man ja dennoch wissen, was gerade los ist. Der Home Assistant, eine freie und open source Software für Hausautomatisierung, bietet mit seinen Dashboards genau solche Übersichten an. Mit wenigen Klicks lassen sich die Messdaten aus dem Haus und um das Haus visualisieren.

Regenradar und weitere Wetterdaten

Das Wetter spielt natürlich eine entscheidende Rolle für das Haus und die Bewohner. Die erste Anlaufstelle für aktuelle Wetterdaten und Vorhersagen könnte beispielsweise OpenWeatherMap sein. Die API ist gut dokumentiert, die Einbindung in den Home Assistant ist reibungslos, der Dienst ist kostenlos und es fällt keine Werbung an. Einzig eine Registrierung auf der Webseite ist nötig, um den verpflichtenden API-Schlüssel zu erhalten.

Was leider fehlt, ist der Regenradar. Jede Vorhersage ist ja nur so gut, wie die, die man mit eigenen Augen sieht. Darum lohnt es sich, einen Regenradar in das Home Assistant Dashboard einzubinden.

Die meisten Regenradare lassen sich nicht besonders einfach einbinden. Und falls doch, sind sie meistens mit Werbung übersät. Um so schöner ist es, dass die Webseite morgenwirdes.de den Regenradar vom Deutschen Wetterdienst (DWD) aufbereitet und uns als animierte gif-Datei zur Verfügung stellt. Die Einbindung in den Home Assistant ist explizit erlaubt und funktioniert folgendermaßen.

Einbindung in den Home Assistant

Zunächst bastelt man sich die URL zusammen, die man für sein Dashboard braucht. Das geht relativ einfach, wenn man sich die Struktur der URL ansieht.

https://morgenwirdes.de/api/v3/gif4.php?plz=12345&delay=70&type=1&zoomlvl=1&bar=0&map=1&textcol=ffffff&bgcol=03a9f4

Die Flagge „plz“ gibt die Postleitzahl vor. Delay ist die Zeit in Millisekunden, die pro Zeitstufe angezeigt wird. Es gibt zwei Farbschemen der Karte, typ=0 oder 1. Der Zoomlvl gibt den Zoomlevel an (hier 1 für ganz Deutschland). Eine Zeitleiste (bar) und Hintergrundkarte (map) können optional eingeblendet werden. Farblich anpassen kann man die Karte mit den beiden letzten Flaggen.

In der configuration.yaml habe ich das dann als Kamera eingebunden. Das hat den Vorteil, dass die Daten immer aktualisiert werden. Würde man es als Bild einbinden, könnte es sein, dass der Regenradar nur aus dem Cache geladen wird und deshalb nicht aktuell ist.

##### Kameras und Wetterkarten
camera:
  - platform: generic
    still_image_url: 
https://morgenwirdes.de/api/v3/gif4.php?plz=12345&delay=70&type=1&zoomlvl=1&bar=0&map=1&textcol=ffffff&bgcol=03a9f4
    name: regenradar

In Lovelace, dem Dashboard von Home Assistant, fügt man nun ein Picture-Glance hinzu, schon ist das Radar da:

type: picture-glance
title: Regenradar
entities: []
camera_image: camera.regenradar

Update 15.04.2022:

Ich habe den Artikel angepasst, das Bild wird nicht mehr als normales Bild, sondern als Kamera eingebunden. Dadurch wird das Radar zuverlässiger aktualisiert.

The post Home Assistant: Animiertes Regenradar einfügen first appeared on bejonet - Linux | Smart Home | Technik.

Es gibt vor allem in Deutschland kollektive Vorbehalte gegen moderne Techniken wie TPM oder Secure Boot. Sie sind nicht exklusiv für die Linux-Gemeinschaft, aber dort besonders stark verbreitet. Diese sind nicht auf Fakten gegründet, sondern basieren auf langjährig gepflegten Mythen.

Ich beschäftige mich aktuell ja mit Themen wie TPM. Ein Thema, um das ähnlich wie um Secure Boot unfassbar viel Fear, Uncertainty and Doubt (FUD) gestreut wird. Das ist keinesfalls von Nischenphänomen, sondern findet sich an hochkarätiger Stelle.

Die englischsprachige Wikipedia schreibt in ihrem Artikel als Einleitung zu TPM:

Trusted Platform Module (TPM, also known as ISO/IEC 11889) is an international standard for a secure cryptoprocessor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. The term can also refer to a chip conforming to the standard.

TPM is used for digital rights management (DRM), Windows Defender, Windows Domain logon, protection and enforcement of software licenses, and prevention of cheating in online games.

One of Windows 11’s system requirements is TPM 2.0. Microsoft has stated that this is to help increase security against firmware and ransomware attacks.

Und weiter:

Overview

Trusted Platform Module provides
A hardware random number generator
Facilities for the secure generation of cryptographic keys for limited uses.
Remote attestation: Creates a nearly unforgeable hash key summary of the hardware and software configuration. One could use the hash to verify that the hardware and software have not been changed. The software in charge of hashing the setup determines the extent of the summary.
Binding: Encrypts data using the TPM bind key, a unique RSA key descended from a storage key[clarification needed].
Sealing: Similar to binding, but in addition, specifies the TPM state for the data to be decrypted (unsealed).
Other Trusted Computing functions for the data to be decrypted (unsealed).

Wikipedia, Artikel „Trusted Platform Module“ unter Creative Commons Attribution-ShareAlike 3.0 Unported License (abgerufen am 08. Februar 2022.

Der deutschsprachige Artikel beginnt mit:

Das Trusted Platform Module (TPM) ist ein Chip nach der TCG-Spezifikation, der einen Computer oder ähnliche Geräte um grundlegende Sicherheitsfunktionen erweitert. Diese Funktionen können beispielsweise dem Lizenz- und Datenschutz oder der nachrichtendienstlichen Kontrolle dienen. Der Chip verhält sich in einigen Punkten wie eine fest eingebaute Smartcard, allerdings mit dem wichtigen Unterschied, dass er nicht an einen konkreten Benutzer, sondern an den lokalen Computer gebunden ist. Außer der Verwendung in PCs und Notebooks kann das TPM in PDAs, Mobiltelefonen und Unterhaltungselektronik integriert werden. Ein Gerät mit TPM, speziell angepasstem Betriebssystem und entsprechender Software bildet zusammen eine Trusted-Computing-Plattform (TC-Plattform). Eine solche „vertrauenswürdige Plattform“ kann nicht mehr entgegen den Interessen des Herstellers genutzt werden, sofern dieser Beschränkungen festgelegt hat. Ein möglicher Vorteil für einen normalen Benutzer eines solchen Systems liegt im Schutz gegen softwareseitige Manipulation durch unbefugte Dritte.

Der Chip ist aktuell überwiegend passiv und kann weder den Bootvorgang noch den Betrieb direkt beeinflussen. Er enthält einen eindeutigen kryptografischen Schlüssel und kann damit zur Identifizierung des Rechners genutzt werden. Das ist jedoch nur möglich, wenn der Eigentümer das Auslesen dieser Information auch gestattet hat. Bei x86-basierten PCs konnte das TPM bisher im BIOS vollständig deaktiviert werden, so dass keine seiner Funktionen zur Verfügung steht. Allerdings gibt es immer mehr Anwendungen, die nur auf einer TC-Plattform mit aktiviertem TPM laufen, wie es z. B. bei Windows seit der Version 11 der Fall ist.

Wikipedia (de.), Artikel „Trusted Platform Module“ unter Creative Commons Attribution-ShareAlike 3.0 Unported

Der Unterschied ist eklatant. Der deutsche Artikel enthält in der Einleitung FUD in seiner Reinform, kaschiert und versteckt im Mantel vorgeblich neutraler Beschreibung plus den Hinweis, wie man es abschalten kann.

Das selbe Spiel kann man mit Secure Boot durchspielen. Einmal der Eintrag in der deutschsprachigen Wikipedia und einmal der Eintrag in der englischsprachigen Wikipedia. Aus Gründen der Redundanz verzichte ich hier auf die Vollzitate, denn der Mechanismus ist der Gleiche. Der Abschnitt in der deutschsprachigen Wikipedia ist tendenziös, verweist auf uralte Sicherheitslücken und hinsichtlich der Zertifikate und Shim auch nicht korrekt. (Vgl. dazu auch das Zitat weiter unten aus dem Debian Wiki)

Da wundert es einen nicht, warum in Deutschland auf die Ankündigung von Microsoft, künftig in Windows 11 TPM 2.0 zur Voraussetzung zu machen, so viel Unsicherheit und Vorbehalte vorherrschten. Dabei ist das langfristig die richtige Entscheidung von Microsoft. Ein etwas überzeichneter Artikel dazu, der aber vielleicht für manchen gewinnbringend sein kann: Packungsbeilage TPM.

In einigen Kreisen – besonders gerne bei Open Source-Anhängern – herrschen bezüglich solcher Techniken wie TPM oder Secure Boot unglaubliche Vorbehalte, die teilweise auf langjährig gepflegten Mythen basieren und bei denen einem abstrakten Risiko erstaunlich selten der konkrete Nutzen gegenüber gestellt wird. Die Ursache dafür liegt meiner Ansicht nach in alten Berichten, die vor vielen Jahren Angst geschürt haben. Das ist irgendwie bei vielen Lesern – vor allem im deutschsprachigen Raum – hängen geblieben. Das hat man inzwischen selbst bei den ursächlichen Medien eingesehen, die heute kritisch auf die eigene damalige Berichterstattung schauen und festhalten, dass daran nichts dran ist.

Noch erstaunlicher ist, dass die FUD-Verbreiter in der Linux-Community sogar gegen die eigenen Knowledge-Bases – die offiziellen Wikis der Distributionen – argumentieren. Dazu kann man beispielsweise auf die tollen Artikel zu TPM und Secure Boot im Arch Linux Wiki verweisen, aber auch konservativere und auf Freiheit bedachte Distributionen wie Debian haben das längst sauber dokumentiert:

What is UEFI Secure Boot NOT?

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.

SB is also not meant to lock users out of controlling their own systems. Users can enrol extra keys into the system, allowing them to sign programs for their own systems. Many SB-enabled systems also allow users to remove the platform-provided keys altogether, forcing the firmware to only trust user-signed binaries.

Debian Wiki Artikel Secure Boot (zuletzt abgerufen am 08.02.2022)

Aus diesem Grund hat man viel zu lange in der Linux-Community Bausteine wie Secure Boot oder TPM links liegen gelassen und es kursieren abenteuerliche Anleitungen für Einsteiger, wie böse Secure Boot ist und was sie alles in UEFI-Settings deaktivieren sollten, bevor sie Linux installieren können.

Die Zukunft gehört solchen Technologien, denn die Sicherheitskonzepte von vor 20 Jahren sind halt auf die Bedrohungen von vor 20 Jahren gemünzt. Heute speichern wir andere Daten auf den Geräten, nutzen sie für andere Zwecke und sind anderen Bedrohungsszenarien ausgesetzt. „Mein System ist Open Source und ich gebe ein Passwort beim Start ein“ ist kein alleinig ausreichendes Sicherheitskonzept mehr. Passend zum Thema sind kürzlich die neuen Sicherheitsrichtlinien der US-Regierung herausgekommen (die natürlich weit darüber hinausgehen). Das BSI wird sicher irgendwann nachziehen und wenn man nicht wünscht, dass Linux eines Tages offiziell vor der Tür bleiben muss, weil es elementare Sicherheitsstandards nicht erfüllt, dann ist jetzt die Zeit proaktiv mit der Implementierung zu beginnen.

Mobile Plattformen und macOS haben vorgemacht, wohin die Reise geht und Windows zieht hier mit der neuen Version Windows 11 konsequent nach. Dabei schließen sie dankenswerterweise die PC-Plattform nicht ab, sondern ermöglichen es Linux ebenfalls von diesen Entwicklungen zu profitieren.

Also hört auf jedem zu raten, Secure Boot und TPM zu deaktivieren und blockiert nicht TPM über die Modul-Blacklist – es sei denn, ihr versteht wirklich, warum ihr was tut.

Der Artikel Kollektive Vorbehalte gegen TPM und Secure Boot – Ängste, Unsicherheit und Zweifel erschien zuerst auf [Mer]Curius

LUKS (dm-crypt) ist die Standardverschlüsselungsmethode. Dank systemd ist es seit Kurzem ein vollständig mit LUKS verschlüsseltes Linux-Betriebssystem mittels FIDO2 oder TPM zu entsperren. Das kann in Kombination mit anderen Schutzmechanismen Sinn ergeben.

TPM und ein modernes Sicherheitskonzept

Die Sicherheit von Linux (Sicherheit im Sinne des Schutzes der Daten vor unbefugte Einsichtnahme) ist ziemlich einfach aufgestellt. Mach eine Vollverschlüsselung und entsperre beim Hochfahren den Container und gut ist. Was mit den Daten im Standby oder bei der Benutzerabmeldung passiert, ist damit ebenso wenig klar wie Themen wie eine vollständige verifizierte Bootkette. Linux hinkt hier hinter Systemen wie Android oder Windows 11 hinterher.

Das Thema ist aber inzwischen auf der Agenda und ein wichtiger Baustein hier ist das Trusted Platform Module (TPM). Natürlich gehört dazu viel mehr, als hier jetzt aufgezeigt werden kann, aber man profitiert bereits von wichtigen Vorarbeiten wie systemd-cryptenroll.

Eine automatische Entsperrung des LUKS-Systemcontainers mittels TPM macht natürlich keinen Sinn, wenn es der einzige Schutzmechanismus ist. Ein Angreifer benötigt dann nur das Gerät, um an alle Daten zu kommen. Wenn man aber z. B. seine Benutzerdaten mittels systemd-homed verschlüsselt hat und diese bereits geschützt sind, geht es um andere Angriffsszenarien. Zum Beispiel ein sogenannter „Evil Maid“-Angriff, bei dem das Speichermedium entwendet oder ein Systemabbild erstellt wurde. Angriffe auf ein verschlüsseltes System lassen sich schließlich viel leichter mit einem solchen Abbild durchführen.

Hier kommt TPM ins Spiel, denn während die Vollverschlüsselung im Normalbetrieb nicht weiter auffällt, scheitert der Startvorgang, sobald das Speichermedium in einer anderen Hardware steckt oder – und das ist der zweite relevante Punkte – sofern jemand am Secure Boot zugange war. Was natürlich voraussetzt, dass Secure Boot aktiviert ist. Das ist leider dank einer verbreiteten Unart bei Linux oft nicht der Fall, obwohl alle ernst zunehmenden Linux-Distributionen Secure Boot unterstützen.

LUKS mit TPM entsperren am Beispiel von openSUSE

LUKS mit TPM zu entsperren ist gegenwärtig noch experimentell und sollte nur von Personen mit tiefer gehenden Linux-Kenntnissen umgesetzt werden.

Die folgende Anleitung basiert auf openSUSE Tumbleweed, weil die SUSE-Entwickler hier bereits erste relevante Vorarbeiten geleistet haben. Sie lässt sich mit Sicherheit auch auf andere moderne Linux-Distributionen übertragen.

Das relevante Werkzeug systemd-cryptenroll kann nur mit LUKS2-Containern umgehen. OpenSUSE legt bei der Installation aber immer noch einen LUKS1-Container an. Deshalb muss in einem ersten Schritt dieser LUKS konvertiert werden. Das ist einfach und klappt zuverlässig. Einfach mit einem Live-Medium starten und mit folgendem Befehl den LUKS-Container konvertieren:

# cryptsetup convert /dev/<laufwerk> --type luks2 

Konzeptionell bedingt funktioniert die Methode aktuell nur, wenn eine unverschlüsselte Boot-Partition zum Einsatz kommt. Das war bis vor Kurzem noch völliger Standard, inzwischen kann man aber LUKS-Container auch in GRUB entschlüsseln. Wegen der erheblichen Verzögerung nutze ich das jedoch nicht, weshalb das für mich keine Einschränkung ist.

Mein Partitionsszenario sieht wie folgt aus:

:~> sudo lsblk 
NAME                                                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                             259:0    0 476,9G  0 disk  
├─nvme0n1p1                                         259:1    0   300M  0 part  /boot/efi
├─nvme0n1p2                                         259:2    0     1G  0 part  /boot
└─nvme0n1p3                                         259:3    0 475,6G  0 part  
  └─cr_nvme-SAMSUNG_MZVLQ512HALU-000H1_S4UHNF0NA02912-part3
                                                    254:0    0 475,6G  0 crypt 
    ├─vg--system-lv--system                         254:1    0    20G  0 lvm   /var
    │                                                                          /usr/local
    │                                                                          /srv
    │                                                                          /root
    │                                                                          /opt
    │                                                                          /
    └─vg--system-lv--benutzerdaten                  254:2    0 455,6G  0 lvm   /home/gheim
                                                                               /home

Nun installiert man noch die TPM-Tools:

$ sudo zypper install tpm2.0-tools

Anschließend rollt man mittels systemd-cryptennroll TPM aus:

Die Verwendung von PCR 7 schützt nicht vor Änderungen an der /boot-Partition. Dadurch kann ein Angreifer eine modifizierte initrd booten und auf die entschlüsselten Daten zugreifen! Um auch diese in den Schutz einzubeziehen, benötigt man PCRs 2, 4, 8 und 9. Dabei müsste man nach jeder Kernel- und Bootloader-Aktualisierung sowie nach jedem Neuaufbau der initrd den Schlüssel neu hinterlegen. Das ist aktuell noch nicht praktikabel und deshalb empfehle ich hier PCR 7. Zukünftig wird das hoffentlich besser werden, das ganze Konzept ist momentan noch work in progress.

Folgende PCR Definitionen stehen theoretisch zur Verfügung:

PCR	Erklärung
0	Core system firmware executable code; changes on firmware updates
1	Core system firmware data/host platform configuration; typically contains serial and model numbers, changes on basic hardware/CPU/RAM replacements
2	Extended or pluggable executable code; includes option ROMs on pluggable hardware
3	Extended or pluggable firmware data; includes information about pluggable hardware
4	Boot loader; changes on boot loader updates
5	GPT/Partition table; changes when the partitions are added, modified or removed
6	Power state events; changes on system suspend/sleep
7	Secure boot state; changes when UEFI SecureBoot mode is enabled/disabled
8	sd-boot measures the kernel command line in this PCR.

$ sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p3 ##Laufwerknamen anpassen

Danach muss man noch die /etc/crypttab modifizieren. Dort dürfte nur eine Zeile hinterlegt sein (ansonsten die entsprechende Systempartition wählen). Dort am Ende Folgendes eintragen: tpm2-device=auto. Das Ergebnis müsste in etwa wie folgt aussehen:

cr_nvme-...  UUID=b7d...  none  x-initrd.attach,tpm2-device=auto

Nun muss noch initrd neu generiert werden:

§ sudo dracut -f

Nach einem Neustart sollte nun keine Passwortabfrage beim Bootvorgang erscheinen und man direkt beim Loginbildschirm landen, wo man den verschlüsselten systemd-homed-Account anmeldet, um seine Daten zu entsperren.

Nacharbeiten und alternative Möglichkeiten

Das LUKS-Volume kann bei einem Problem mit TPM (was in diesem experimentellen Stadium nicht ausgeschlossen werden kann) immer noch mit den zusätzlich hinterlegten Passwörtern entsperrt werden. TPM belegt einfach einen Keyslot in LUKS. Wenn man sich vollständig auf TPM verlassen möchte, muss man die entsprechenden anderen Keys entfernen. Alternativ kann man auch einen langen und besonders sicheren Schlüssel als Wiederherstellungsschlüssel hinterlegen, was ich sowieso empfehle.

Alternativ lässt sich das Prozedere auch mit einem FIDO2-Stick anstelle von TPM durchführen, was vor allem Sinn macht, wenn man kein separat verschlüsseltes Home-Verzeichnis hat und stattdessen einen zweiten Faktor zur Authentifizierung des LUKS-Containers einziehen möchte. Dadurch verschiebt sich das Schutzkonzept, weshalb das nicht hier im Artikel behandelt wird. In dem hier behandelten Kontext wäre ein FIDO2-Stick eher als Schutzmaßnahme für systemd-homed geeignet – was selbstredend auch unterstützt wird. Das Vorgehen unterscheidet sich nur in wenigen Punkten vom hier geschilderten Szenario und kann dem openSUSE-Wiki entnommen werden.

Zusammengefasst

Angesichts der noch sehr jungen Werkzeuge und eher rudimentären Vorarbeiten der Distribution, funktioniert das Ganze bereits sehr gut. Die systemd-Entwickler haben einmal mehr bewiesen, was für gute Werkzeuge sie den Linux-Anwendern zur Verfügung stellen und damit alte, unzureichende und unnötig komplexe Lösungen überflüssig machen.

Die aktuelle Entwicklung ist ein Übergangsstadium hin zu einer verifizierten Kette vom Systemstart bis zum Login des Anwenders, bei der Signierung und Verschlüsselung ineinandergreifen und nur jene Teile verschlüsselt sind, die es auch sein müssen.

Der Artikel Verschlüsseltes Linux mit LUKS mittels TPM 2.0 entsperren erschien zuerst auf [Mer]Curius

Mo, 7. Februar 2022, Ulf Bartholomäus

Bei SuSE Linux und dem darauf basierenden openSUSE Community Projekt handelt es sich um eines der ältesten Linux Distributionen überhaupt. Sie war wegen ihrer deutschen Wurzeln und insbesondere für die gute Unterstützung der deutschen Sprache sehr bekannt. SuSE war für viele ältere Linux Nutzer die erste benutzte Linux Distribution.

SuSE Linux Enterprise ist vor allen für kommerziellen Einsatz gedacht. Das davon abgeleitete openSUSE Linux Community Projekt, gibt es in zwei Varianten. Dem auf klassischen Release-Zyklus basierenden openSUSE LEAP, das demnächst in der neuen Version 15.4 veröffentlicht wird und eher einer LTS (Long Term Support) Distribution ähnelt, sowie seit etwa 10 Jahren openSUSE Tumbleweed. Welches mittlerweile ein Aushängeschild des openSUSE Projektes geworden ist. Anstelle klassischer Versionsnummern und periodischer Updates wird ein Rolling-Release-System genutzt. Updates finden kontinuierlich statt, vorherige Stände des Betriebssystems werden als „Snapshots“ gesichert. Die Mehrheit der openSUSE Anwender nutzen laut regelmäßig durchgeführten Umfragen mittlerweile Tumbleweed als Desktop Distribution.

Dabei wird nach der Factory First Policy vorgegangen, bei der alle Pakete zunächst nach Factory releast werden, bevor sie in eine Distribution aufgenommen werden können. Aus Factory wird täglich ein Snapshot gezogen und einem automatisierten Testprogramm unterzogen. Bei erfolgreichem Test wird der Snapshot publiziert. Anders als bei anderen Distributionen ist Tumbleweed somit ein getestetes Rolling Release, was der Stabilität sehr entgegenkommt.

Aussage des  Tumbleweed Portals: "Das Projekt tut dies für Nutzer, die die jeweils neueste stabile Software haben wollen." Deshalb ist Tumbleweed auch nach meinen jahrelangen Erfahrungen besonders für die ambitionierten Einsteiger geeignet.

In meiner LUG verwenden es einige Einsteiger seit Jahren, ohne damit nennenswerte Probleme zu haben. Dabei ist insbesondere die sehr gute und aktuelle KDE/Plasma sowie nahtlose Integration für viele Tumbleweed Nutzer das ausschlaggebende Argument für die Nutzung.

Installation

Das Herunterladen des ISO Images und das anschliessende (optionale aber empfehlenswerte) Überprüfen dessen, ist sehr gut und in deutscher Sprache beschrieben. Auch wird neben der Installation von DVD die Installation mit dem gleichen ISO auf einen USB-Stick unterstützt. Das Brennen könnte einfacher nicht sein, da sogar ein eigenes Programm, dass sich SUSE Studio ImageWriter nennt, dazu angeboten wird. Ist das ISO dann auf der DVD oder USB-Stick geschrieben, kommt eigentlich wie bei allen anderen Linux Distributionen auch der schwierigste Schritt. Nämlich den eigenen PC oder Notebook zu überreden, dass er von dem Installationsmedium startet. Hat man diese Hürde genommen, die leider nicht von Linux beeinflusst werden kann, sondern nur vom verwendeten PC-Hersteller abhängt, erscheint der Bootbildschirm. Hier kann man direkt die Sprache auf Deutsch umschalten oder erst nach dem Starten der Installation. Egal wie, die komplette Installation wird in sehr guten Deutsch geführt und sogar die optionale Hilfe ist komplett in Deutsch vorhanden.

Eigentlich kann man danach nicht mehr viel falsch machen, weil die meisten Einstellungen intuitiv zu tätigen sind. Auch sind immer wieder gute Tipps in der Hilfe gut beschrieben.

Mein Tipp, ist gleich KDE/Plasma als Desktop zu wählen, da dieser besonders gut in openSUSE integriert ist und die "deutsch" - "deutsche" Partnerschaft zwischen beiden eine lange Tradition hat. Ich kenne keine andere Distribution, die so hervorragend in die KDE/Plasma Desktop Welt integriert.

Selbst komplexe Aufgaben, wie ein verschlüsseltes System lassen sich mit dem geführten und mit sinnvollen Hilfetexten versehenen Installations-Programm auch für Einsteiger ohne Probleme durchführen.

Ist das System fertig zusammengestellt, kann man sich alle Einstellungen noch mal in Ruhe anschauen und bei Bedarf noch mal einfach ändern. Anschliessend braucht man nur noch mit "Installieren" alles laufen lassen, bis der Anmeldebildschirm nach dem ersten Starten erscheint.

Durch die eigentlich immer etwa 1 Monat verzögert verfügbaren aktuellen Kernel, ist auch aktuelle Hardware insbesondere bei Notebooks wichtig, bestmöglich unterstützt. Sollte es doch mal mit dem einen oder anderen Feature klemmen, kann man sicher sein, dass sich das Problem nach einigen Updates in der Regel von alleine löst. Auch das nur mit wenig Verzögerung gegenüber dem offiziellen KDE/Plasma Releases verfügbare, aber immer gut integrierte und adaptierte Desktop und Anwendungen, sind so in keiner anderen Distribution zu finden.

Einführung

Direkt nach dem ersten Start wird man mit dem "Ahoi" Fenster begrüsst. Dieser bietet direkt den Einstieg in einige sehr gute und vor allem auch fast durchgängig deutsche Einführung. Überall werden auch immer mehrere Wege zur Lösung angeboten, sodass man den für sich bevorzugten aussuchen kann.

Vollständigkeit

Insbesondere nach Aktivieren der zusätzlichen Community Repositories, kann einfach über YaST auf fast alles zugreifen, was irgendwie als Linux Programm angeboten wird. Falls doch mal was fehlt, aktiviert man im KDE/Plasma Anwendungsmanager "Discover" einfach Flatpack und bekommt standardmäßig alle auf Flathub angebotenen Programme dazu.

Stabilität

Dadurch die Factory First Policy und den vorherigen automatischen Tests der Software vor der Verteilung über die Tumbleweed Repositories, kommt es eigentlich nicht zu nennenswerten Problemen mit der Stabilität. Sollte dann doch mal der Fall der Fälle auftreten, bietet Tumbleweed zahlreiche Möglichkeiten an trotzdem mit dem System zu arbeiten. Standard mässig werden immer der aktuelle und der zuletzt verwendete Kernel in den erweiterten Optionen angeboten, zusätzlich kann jeder von ihnen im Recovery Modus gestartet werden. Wird BTRFS verwendet, werden noch sehr intelligent Snapshots angefertigt, die dann im nur-lese Modus gestartet werden kann. Kommt man mit den vorherigen Massnahmen nicht weiter, löst das Aktualisieren via bootbarem ISO das Problem sehr zuverlässig.

Vorkonfiguration

Tumbleweed ist nach dem Start komplett benutzbar konfiguriert und auch die wichtigsten Anwendungen sind vorhanden.  Möchte man auch exotische und geschützte Codecs verwenden oder die aktuellsten nVidia Grafiktreiber, kann man das durch einfaches geführtes hinzufügen von Community Repositories wie Packman erledigen. Auf dem schon erwähnten Tumbleweed Portal gibt es auch eine fast noch einfachere Anleitung via Textkonsole und einfachen kopieren und einfügen.

Update-Prozess

Der ist ganz einfach, ihn gibt es in dem Sinn ja nicht. Die täglichen manchmal bis zu hundert Pakete fixen nicht nur Fehler oder lösen kritische Sicherheitsprobleme kurz nach Bekanntwerden. Auch neue Programme und Funktionen kommen immer wieder in mehr oder weniger kleinen Schritten hinzu. Das ist sehr angenehm, da es dadurch im schlimmsten Fall nur ein paar Tage dauert, bis ein Problem einer SW gelöst und durch die fortlaufenden Updates gelöst wird.

Bewertung

Kriterium	Bewertung (max. 5)
Installation	🏆️🏆️🏆️🏆️
Einführung	🏆️🏆️🏆️🏆️🏆️
Vollständigkeit	🏆️🏆️🏆️🏆️
Stabilität	🏆️🏆️🏆️🏆️
Vorkonfiguration	🏆️🏆️🏆️🏆️🏆️ (KDE Version)
Update-Prozess	🏆️🏆️🏆️🏆️
Summe	26

Fazit

openSUSE Tumbleweed KDE/Plasma eignet sich sehr gut für Linux-Einsteiger, vor allem wenn sehr neue Hardware verwendet werden soll. Als Desktopoberfläche empfiehlt sich KDE, was man auch daran erkennen kann, dass es bei der Desktop Auswahl an erster Stelle steht. Das System ist im Standardumfang gut konfiguriert und die wichtigsten Anwendungen sind vorinstalliert. Eine Installation von weiteren Applikationen ist auch für Erstanwender ohne weiteres möglich, wobei bei KDE Discover die erste Wahl sein sollte. Mit YaST steht eine extrem leistungsfähige und benutzerfreundliche Möglichkeit zur Verfügung, das System sehr weitgehend und komfortabel anzupassen. Dabei ist insbesondere die einfache Installation von Hardware wie Druckern, Scannern und Multifunktionsgeräten via YaST sehr gut gelöst.

Download: https://get.opensuse.org/de/tumbleweed/

Mo, 7. Februar 2022, Lioh Möller

Die aus Mandriva Linux heraus entstandene Distribution OpenMandriva wurde in der Version Lx 4.3 veröffentlicht (OMLx 4.3). Eine Besonderheit stellt die Verwendung des LLVM Compilers dar, was nach Aussagen des Projektes zu einer Performance-Steigerung führt.

Wie bereits in der Vorgängerversion lässt sich mit dem Hilfsprogramm om-feeling-like das Erscheinungsbild der Standard-Desktopoberfläche anpassen und von anderen Betriebssystemen her bekannte Paradigmen nachbilden.

Der Willkommensassistent OM-Welcome wurde für die nun vorliegende Version weiter verbessert und ermöglicht Einsteigern einen schnellen Zugang zur Distribution.

Ein Port für die 64-bit ARM Architektur steht offiziell zur Verfügung. Damit einhergehend werden installierbare Images für PinebookPro, Raspberry Pi 4B und 3B+, Rock Pi 4A, 4B und 4C, Synquacer, Cubox Pulse und generische UEFI-kompatible aarch64 Geräte angeboten.

LibreOffice ist in Version 7.3.0.3 enthalten sowie Krita 5.0.2, Digikam 7.5, SMPlayer 21.10.0, VLC 3.0.16 und der Falkon Webbrowser 3.2.

PipeWire ist standardmässig aktiviert, bei Bedarf ist allerdings weiterhin ein Wechsel auf PulseAudio möglich.

Als Standardkernel kommt Version 5.16.7 zum Einsatz und der KDE Plasma Desktop wird in Version 5.23.5 ausgeliefert.

Quelle: https://www.openmandriva.org/en/news/article/openmandriva-lx-4-3-released