Ubuntu ist die am weitesten verbreitete Linux-Distribution. Das gilt für die offiziellen Varianten, aber umso mehr, wenn man sich vergegenwärtigt, dass der Ubuntu-Unterbau die Basis für Distributionen wie Linux Mint, Pop!_OS oder elementary OS bildet. Wie ist es eigentlich um die Sicherheit bei Ubuntu bestellt?

Achtung: Wer keine Kritik an Debian verträgt oder jeden Vergleich von Debian mit irgendetwas anderem als Sakrileg empfindet, bitte hier gleich aufhören zu lesen.

Einordnung

Diese Frage bzw. dieser Vorwurf erreicht mich immer wieder, da ich einerseits die Situation bei Debian sehr kritisch beurteilt habe, aber andererseits immer mal wieder erzähle, dass ich Ubuntu nutze. (Kleiner Hinweis übrigens an die Alles-Hasser in den Kommentarspalten: Ich bin kein „Ubuntu-Fanboy“, wenn ich „Fan“ irgendeiner Distribution bin, dann sicher von openSUSE. Aber um das herauszufinden, müsste man ja tatsächlich diesen Blog lesen…). Zurück zu Debian vs. Ubuntu: Tatsächlich messe ich hier mit zweierlei Maß!

Der Grund dafür ist leicht zu erklären. Wenn mich irgendetwas besonders abstößt oder auch einfach nur provoziert, dann Selbstgerechtigkeit. Debian wird von seinen Anhängern immer besondere Sicherheit zugeschrieben (siehe z. B. der eigene Abschnitt bei Wikipedia) und unter jedem Debian-Artikel taucht irgendeiner auf, der sagt, dass man genau wegen der Stabilität und Sicherheit Debian verwenden muss. Im Gegensatz dazu weiß jeder, dass Ubuntu abseits von main Probleme mit der Qualität hat. Niemand in der Ubuntu Community würde das Gegenteil behaupten und der potenziell faulige Zustand der dortigen Software wird Neulingen bei jeder Gelegenheit erzählt. Ein Artikel über die Probleme bei Ubuntu universe ist also eigentlich völlig überflüssig, weil ich darüber schreiben würde, was sowieso jeder weiß (bzw. habe ich auch schon).

Kurzum: Wer eine sichere Distribution sucht, greift sowieso nicht zu Ubuntu, sondern zu RHEL oder einem freien Klon oder Fedora, wenn man es aktueller mag. Alternativ gibt es noch openSUSE Leap bzw. SUSE Linux Enterpise bei Bedarf für einen offiziellen Supportvertrag. Hier ist dann meiner Meinung nach auch schon Ende bei den Linux-Distributionen, die ich bezüglich Sicherheit besonders empfehlen würde, wenn man von Spezialdistributionen wie Qubes etc. absieht.

Wie groß ist das Problem der eigenen Installation

Die spannende Frage ist aber, wie groß das Problem bei Ubuntu wirklich ist und ob ein normaler Desktop-Nutzer wirklich eine besonders sichere Distribution benötigt. Dazu muss man ein wenig tiefer in das jeweilige System schauen. Im konkreten Fall gehe ich von Kubuntu-Installationen aus, wie ich sie normalerweise aufsetze. Den Sicherheitsstatus kann mit folgendem Befehl abfragen.

$ ubuntu-security-status

Das Ergebnis hängt dann vom jeweiligen Setup aber und kann z. B. wie folgt aussehen:

2004 packages installed, of which:
1159 receive package updates with LTS until 4/2027
   3 packages are from third parties
   2 packages are no longer available for download

Packages from third parties are not provided by the official Ubuntu
archive, for example packages from Personal Package Archives in
Launchpad.
For more information on the packages, run 'ubuntu-security-status
--thirdparty'.

Packages that are not available for download may be left over from a
previous release of Ubuntu, may have been installed directly from a
.deb file, or are from a source which has been disabled.
For more information on the packages, run 'ubuntu-security-status
--unavailable'.

This machine is not attached to an Ubuntu Advantage subscription.
See https://ubuntu.com/advantage

Das bedeutet, 1159 Pakete entstammen main und erhalten Sicherheitsupdates von Canonical. Das ist das, was ich als Betriebssystem-Basis bezeichne. 840 Pakete kommen aus multiverse oder universe und haben keinen garantierten Sicherheitsstatus.

Was das genau ist, kann sehr einsteigerfreundlich bei Muon (oder Synaptic bei GTK-Oberfläche) eingesehen werden.

Kein offizieller Support – Katastrophe?

Alle Pakete mit dem blauen Kreis haben offiziellen Supportstatus. Pakete ohne entsprechendes Symbol eben nicht. Auf einem Kubuntu-System wird der überwiegende Teil davon zum KDE-Softwarestack gehören. Das ist aus mehreren Gründen nicht kritisch:

Die Kubuntu-Entwicker pflegen die Software und bringen Updates raus. Sie reichen auch Updates von KDE weiter (bei der letzten LTS wurde z. B. KDE Plasma von der Releaseversion 5.18.4 auf 5.18.8 angehoben). Um den Vergleich mit Debian wieder zu bemühen: Dort passiert das nicht und wer den KDE-Stack nach dem zumindest halben Weggang von Norbert Preining pflegt, kann ich nicht sagen. Trotzdem behauptet Debian, dass sie KDE Software umfänglich unterstützen, während Ubuntu das hier nicht tut. So viel zum Ehrlichmachen, was ich oben angesprochen habe.

Unabhängig von dem Aspekt sind Sicherheitslücken bei KDE eher selten. Das liegt nicht zuletzt an der Art, wie freie Software aufgebaut ist. Dazu kann man einfach mal das Packprogramm Ark nehmen. Sicherheitslücken treten eher selten in der Oberfläche auf, sondern betreffen meist die Kompressionsprogramme. Ark hat keinen offiziellen Sicherheitsstatus, zip, unzip, bzip etc. schon. Das kann man auf viele andere Bereiche übertragen. Akonadi hat selten Sicherheitslücken, die PostgreSQL-Datenbank im Hintergrund dagegen häufiger.

Nicht alles in universe ist zudem gleichermaßen problematisch, sondern sehr abhängig davon, wo sich Freiwillige engagieren. VirtualBox in Ubuntu bekommt z. B. sehr regelmäßig Updates durch zwei Debian-Maintainer. Ironie am Rande: In Debian ist VirtualBox rausgeflogen, weil dort keine Updates verteilt werden dürfen, die Versionsnummern anheben, selbst wenn es wirklich nur Wartungsupdates sind, wie bei VirtualBox.

Problematische Bereiche

Also gibt es keine Probleme? Leider doch:

Der komplette Multimedia-Stack hat keinen offiziellen Supportstatus und der Zustand der Codecs ist bekanntermaßen schlecht. Das ist kein exklusives Linux-Problem, sondern der Multimedia-Bereich bei z. B. Android leider auch immer wieder ein Grund für viele Sicherheitsupdates. Die Trennung in bad, ugly & Co bei GStreamer ist auf jeden Fall kein Entwicklerspaß, sondern ernst gemeint. Ich weiß nicht, wie andere Distributionen damit umgehen. OpenSUSE hat sich des Problems formell mit Packman entledigt, Red Hat / Fedora mit EPEL. Wie Debian glaubt hier Sicherheit garantieren zu können weiß ich nicht. Besonders fatal finde ich, diese Anleitungen für Einsteiger, bei denen alle Codecs installiert werden, die es gibt, anstelle nur der wirklich genutzten Formate. Hier ist für die Sicherheit weniger einfach mehr. Egal bei welcher Distribution.

Ein weiteres Problem ist der fehlende Support von Qt5. Besonders bei Qt5Webengine ist das fatal, weil Programme wie KMail oder RSS Guard diese nutzen, um HTML-Ansichten auszugeben. Das ist ein heftiges Manko (und dass Debian da nicht besser ist, hilft leider nicht) und als Anwender kann man sich da nur behelfen, indem man HTML in Programmen wie KMail standardmäßig deaktiviert lässt.

In manchen Bereichen ist man zudem sehr zurückhaltend. Das betrifft jetzt nicht Updates und Sicherheitslücken aber Prioritätensetzung. Die Funktion systemd-cryptenroll hat Canonical z. B. für Ubuntu 22.04 faktisch deaktiviert, weshalb keine TPM oder FIDO2-Unterstützung für LUKS-Entsperrung vorgesehen ist. Bei openSUSE hat man das hingegen für 15.4 implementiert.

Abschließend sei der Vollständigkeit halber zudem noch auf die offizielle CVE-Liste von Ubuntu verwiesen, die leidlich versierten Anwendern zumindest einen Blick in den Abgrund ermöglicht. Hier kann man gut nachprüfen, wie der aktuelle Zustand von Paketen ist, die man vielleicht im Verdacht hat. Anlässlich meiner jüngsten Empfehlung das Akonadi-Backend von MariaDB auf PostgreSQL umzustellen, sei hier mal exemplarisch auf die Liste von MariaDB in 22.04 „Jammy Jellyfish“ verwiesen.

Zusammengefasst

Ubuntu ist keine perfekte Distribution, wenn man einen Fokus auf Sicherheit legt. Das hat aber auch nie jemand behauptet. Als normaler Anwender kann man trotzdem sehr gut damit arbeiten, weil die Gefahr wirklich schwerwiegender Sicherheitslücken überschaubar ist. Notwendige Updates betreffen sehr oft die „Systembasis“ und neuralgische Bereiche wie den Internetbrowser. Hier bekommt man bei Ubuntu zuverlässig Updates. Das gilt aber natürlich ebenso für Debian.

Wie groß das Problem ist, hängt ganz wesentlich von der eigenen Installation und dem genutzten Derivat ab. Anwender der Hauptdistribution mit GNOME Shell dürften vermutlich noch weniger nicht-unterstützte Pakete haben als ich mit der hier gezeigten Kubuntu-Instanz. Es kann aber auch sicherlich deutlich schlimmer sein, wenn man noch viel mehr aus Universe bezieht.

Ich persönlich schätze die Ehrlichkeit hinter der Trennung in main und universe. Deshalb gebe ich Ubuntu den Vorzug vor Debian. Für wirklich hohe Sicherheitsansprüche würde ich aber sowieso keine der beiden Distributionen nutzen.

Datensparsamkeit und Schutz der digitalen Privatsphäre ist das eine Thema, Anonymität ein völlig anderes. Leider wird beides viel zu oft vermengt. Anonymität ist nicht immer notwendig und wenn, dann nur mit strenger Disziplin und den entsprechenden Werkzeugen zu erreichen. Eines dieser Werkzeuge bietet Whonix.

Umfeld von Whonix

Anonymität ist im Internet immer noch gleichzusetzen mit Tor (trotz aller Probleme). Doch obwohl sich Tor beispielsweise einfach über die Paketquellen der meisten Linux-Distributionen installieren lässt, ist es nicht einfach damit getan, seinen Datenverkehr über ein paar Tor-Knoten zu leiten. Denn erstens erfolgt Identifizierung heute über mehr Faktoren als nur die IP-Adresse und zweitens würde man bei so einem Vorgehen auch identifizierbaren Traffic mitschicken und sich damit selbst kompromittieren.

Deshalb gibt es zwei besonders bekannte Lösungen, um anonym zu surfen. Den Tor Browser und Tails. Der Tor Browser ist ein niedrigschwelliges Angebot, das einfach unter jedem Betriebssystem installiert werden kann. Dabei handelt es sich um eine modifizierte Firefox-Version, die darauf ausgelegt ist, in der Masse unterzugehen und natürlich den Datenverkehr über das Tor-Netzwerk leitet. Für den Einstieg und „kleinere“ Anonymitätsbedarfe völlig ausreichend.

Die Arbeit auf dem eigenen Desktop hat aber auch Nachteile. Downloads können manipuliert sein oder der ein oder andere Link aus Versehen doch im falschen Browser geöffnet werden. Für diese Zwecke gibt es Tails, das nur als Live-System funktioniert und somit immer eine saubere Arbeitsumgebung startet. Die Funktionsweise bedingt natürlich einen abwechselnden Betrieb zum eigenen System und die eigene Hardware sollte mit GNOME Shell flüssig laufen, denn Tails versucht im Linux-Umfeld möglichst wenig aufzufallen. Ein zufälliger Beobachter im Café soll eben nicht sehen, dass man gerade mit Tails arbeitet. Tails ist unpraktisch und will auch genau das sein.

Whonix

An diesem Punkt kommt Whonix ins Spiel. Die Entwickler haben den Anspruch ein „wasserdichtes Betriebssystem für die Privatsphäre“ zu schaffen und durchaus prominente Fürsprecher. Anders als Tails setzt man auf Virtualisierung, weshalb sich Whonix in das eigene Arbeitsumfeld einfügt, aber im Gegensatz zum Tor Browser dennoch hinreichend separiert.

Dieses Ziel erreichen die Entwickler mit Virtualisierung. Whonix gibt es für VirtualBox (Windows, macOS, Linux) und für das erste Setup ist dies auch der einfachste Weg. Linux-Anwender können aber auch eine Virtualisierung über KVM vornehmen und besonders sicherheitsbewusste Anwender können zu Qubes greifen.

Whonix verwenden

Die Installation und Einrichtung funktioniert für VirtualBox über den Download von OVA-Images. Diese können über die Schaltfläche Importieren in VirtualBox importiert werden. Dabei werden zwei virtuelle Maschinen angelegt:

• Whonix Gateway
• Whonix Workstation

Beide Maschinen müssen gestartet werden. Whonix Gateway ist dafür zuständig, die Verbindung zum Tor-Netzwerk aufzubauen. Ansonsten macht man als Anwender nichts in dieser Maschine. In der Workstation darf gearbeitet werden. Diese Workstation kann nur über den Gateway nach außen kommunizieren. Die Idee dahinter ist, dass selbst bei einer Kompromittierung der Workstation Informationen wie die öffentliche IP-Adresse nicht offen gelegt werden kann.

Beide Maschinen müssen über den Befehl upgrade-nonroot aktualisiert werden, um Sicherheits- und Funktionsupdates zu erhalten. Als Desktop kommt das ressourcensparsame Xfce zum Einsatz. Eine kleine Softwareauswahl ist bereits vorinstalliert. Insbesondere der zentrale Tor Browser in einer speziellen Ausfertigung.

Vor- und Nachteile

Whonix soll in einer virtuellen Umgebung laufen. Dadurch kann der Anwender das System anpassen und konfigurieren und startet anders als bei Tails nicht jedes mal mit einem blanken System. Das ist Vor- und Nachteil zugleich, weil es eben auch Spielräume zur Kompromittierung lässt. Zudem müssen Gateway und Workstation aktuell gehalten werden, weshalb eine gewisse Systempflege notwendig ist.

Der Betrieb von zwei virtuellen Maschinen zusätzlich zum Host-System erfordert zudem eine hinreichend potente Hardware.

Kontact bzw. der Akonadi-Unterbau sind so ein Thema für sich. Ein Paradebeispiel für Overengineering aber bei KDE hält man stoisch daran fest. Wer also einen konsistenten KDE-Arbeitsplatz haben möchte, kommt nicht daran vorbei. Leider sind die Abhängigkeiten bei Kubuntu 22.04 schlecht gesetzt. Eine Alternative mit PostgreSQL steht aber bereit.

Viele Fehlentscheidungen aus den frühen KDE 4-Zeiten haben die KDE-Entwickler inzwischen korrigiert – Akonadi leider nicht. Die längere Zeit in Entwicklung befindliche Alternative Kube ist eingeschlafen und auch neue Apps wie Kalendar basieren im Hintergrund leider weiter auf Akonadi. Viele grobe Bugs sind ausgeräumt, aber das vollkommen überdimensionierte Backend ist immer noch ein Garant für Probleme und Schwierigkeiten. Warum es für die Speicherung von Mails und PIM-Einträge so ein gewaltiges Backend braucht, wo doch Thunderbird und Evolution ohne auskommen, konnte nie jemand stimmig erklären. Wie so oft gilt hier vermutlich Entwicklerspaß vor Nutzerinteressen.

KDE-Anwender müssen also leider weiter mit Akonadi leben. Die Kubuntu-Entwickler haben als seit 20.04 als Standard Thunderbird vorgesehen (was schon ein Statement für sich ist), aber Kontact & Co natürlich weiter in den Paketquellen. Leider nicht besonders durchdacht. Das Paket akonadi-backend-mysql verweist nämlich auf MariaDB. Ich vermute, das hat man einfach von Debian übernommen. Leider setzt Canonical im Gegensatz zu vielen anderen Distributoren nicht auf MariaDB, sondern hält MySQL die Treue. MariaDB ist nur in Universe enthalten und hat somit einen nicht garantierten Sicherheitsstatus.

Die Derivate bzw. Universe und Sicherheit sind ein Thema für sich, das hier nicht im Detail diskutiert werden kann. Grundsätzlich ist nicht jede Software sicherheitskritisch und zumindest beim KDE-Stack verfolge ich das Thema engmaschig genug, um prüfen zu können, ob Kubuntu hier Probleme behebt. Die Basis (macht bei Installation hier circa 1200 von 1900 Paketen aus) wird ja direkt von Canonical gepflegt. Bei Software wie MariaDB hört aber bei mir die Toleranz auf, wenn es um nicht geschlossene Sicherheitslücken geht.

Zum Glück gibt es noch ein weiteres Akonadi-Backend und zwar das für PostgreSQL. Das ist nicht schlecht gepflegt, da einer der Kern-Entwickler von Kontact viele Jahre selbst PostgreSQL als Backend nutzte. Entwickler beheben Bugs ja auch gerne für sich selbst – warum also nicht davon profitieren? Der Vorteil für Kubuntu-Nutzer ist, dass PostgreSQL in main liegt und direkt von Canonical unterstützt wird.

Vorher unbedingt ein Backup machen. Das Szenario geht davon aus, dass E-Mails und PIM-Daten lediglich via IMAP und Cal-/CardDAV eingebunden sind und somit nicht verloren gehen können.

Der Umstieg ist ziemlich leicht. Zuerst Akonadi stoppen und das neue Backend installieren:

$ akonadictl stop

$ sudo apt install akonadi-backend-postgresql

Anschließend noch die Benutzerkonfiguration in der Datei ~/.config/akonadi/akonadiserverrc ändern:

[%General]
Driver=QPSQL

[QPSQL]
Host=/tmp/akonadi-<benutzername>.hash
InitDbPath=/usr/lib/postgresql/14/bin/initdb
Name=akonadi
Options=
ServerPath=/usr/lib/postgresql/14/bin/pg_ctl
StartServer=true

Nun noch die alte MariaDB-Daten löschen, indem man das Verzeichnis ~/.local/share/akonadi/db_data umbenennt in z. B. db_data_bak. Sollte die Migration erfolgreich sein, kann es später gelöscht werden.

Nun noch Akonadi wieder starten und prüfen. Sollte es Probleme geben, wird hier auch aufgelistet, wo es klemmt.

$ akonadictl start
$ akonadictl fsck

Nun läuft Akonadi mit einem offiziell supporteten Backend. Negative Erfahrungen für Stabilität und Performance kann ich nicht berichten.

openSUSE lässt sich traditionell am Ende der Entwicklungs-Roadmap viel Zeit. Am 27. April erschien die RC-Version, einen Monat später erfolgte heute der Gold-Master-Build. Früher liefen dann die CD-Pressen an. Heute wartet man noch ein wenig bevor in zwei Wochen die Version final freigegeben wird. Höchste Zeit für einen tiefen Blick in die neue Version.

Diese Version ist im Wesentlichen eine Fortentwicklung der früheren Versionen der Leap 15-Serie:

• Leap 15.3
• Leap 15.2
• Leap 15.1
• Leap 15.0

Umstürzende Änderungen sind bei den Minor-Versionen einer Hauptserie nicht geplant. Ein umfassender Test entfällt daher, genau wie bei den Vorversionen auch schon. Stattdessen möchte ich ein wenig auf das Leap-Entwicklungsmodell eingehen, das immer noch bei vielen für Verwirrung sorgt, weil es nicht der von Debian geprägten „Standardnorm“ für LTS-Distributionen entspricht.

Das Leap-Entwicklungsmodell

Die neue Version ist die jüngste Inkarnation der 15er-Serie von openSUSE Leap. Diese ist höchstwahrscheinlich die letzte traditionelle Linux-Distribution aus dem Hause SUSE/openSUSE, bevor man mit Version 16 in zwei Jahren auf die neue SUSE Adaptable Linux Platform wechselt. Die 15er Version folgt einem Wechselsystem. Auf eine sehr zurückhaltende Version – das war die letzte Version 15.3 – folgt eine Version mit mehr Aktualisierungen.

Um ein etwas schiefes Bild zu benutzen: Durch den Entwicklungsprozess von openSUSE gleicht die neue Version einem Menschen im fortgeschrittenen Lebensalter, dem man ein paar Organe erneuert und die Gesichtshaut ordentlich hinter die Ohren gezogen hat. Optisch ganz gut anzusehen und sollte noch eine Weile laufen, aber im Kern eben doch schon ein paar Jahre alt.

Der Hintergrund ist, dass jede openSUSE Leap Version sich an den Service Packs von SLE orientiert und eine Weiterentwicklung der Hauptversion darstellt. Ein solcher Zyklus kann durchaus mehrere Jahre gehen. Leap 15.0 erschien 2018, seitdem entwickelt man auf dieser Basis weiter. Die Anwender müssen dabei immer auf die neueste Minor-Version aktualisieren, um weiterhin Sicherheitsaktualisierungen zu erhalten. Das ähnlich ähnlich wie bei Red Hat, aber anders als bei z. B. Debian oder Ubuntu, wo alle zwei Jahre eine neue LTS zusammen gebaut wird, die dann 3-5 Jahre eingefroren wird und keine substanziellen Änderungen mehr erfährt.

Im Gegensatz zu den Debian-Entwicklern glaubt man bei SUSE (und mit Abstrichen auch Red Hat) diese Versionsaktualisierungen hinreichend gut testen zu können. Dahinter steht die Überzeugung, dass eine vorsichtige Aktualisierung unterm Strich mehr bringt als eine Bugsammlung über Jahre einzufrieren. Gleichzeitig sind einschneidende Änderungen neuen Hauptversionen vorbehalten. So ist bei Leap 15.4 der usr-merge ebenso noch nicht erfolgt, wie die weitere Einbeziehung von systemd-Diensten anstelle z. B. von chrony oder cronie. Den Wechsel auf Plasma 6 würde man – so er denn irgendwann mal kommt – sicherlich auch nicht in einer Minorversion vollziehen, den Sprung von 5.18 auf 5.24 aber eben schon.

Schaut man tiefer in die Paketquellen, sieht man, dass viele Pakete direkt von SUSE aus SLE kommen (Versionen enden auf 150400). Andere Pakete stammen von openSUSE (Versionen enden auf lp154 oder bp154). Ebenso gibt es unterschiedliche Updatequellen für SLE- und openSUSE-Pakete. Diese Feinheiten müssen Anwender aber eigentlich nicht interessieren.

Versionen

Das bedeutet konkret für die Versionen, dass die Desktopumgebungen von KDE Plasma 5.24 über GNOME 41 bis zu MATE 1.26 und Xfce 4.16 relativ aktuell sind und teils aktueller als bei komplett „neuen“ Distributionen wie dem vor zwei Monaten veröffentlichten Ubuntu 22.04.

Der Kernel ist mit 5.14 schon ein wenig abgehangener, ebenso systemd 249. Beides aber nicht dramatisch alt und vermutlich nur relevant für Anwender von sehr aktueller Hardware oder sehr neuen Funktionen in systemd.

Schaut man dann tief in den Kern, sind Sachen wie glibc in Version 2.31 oder auch PolKit 0.116 richtig alt. Standardmäßig kommt für den GNU C Compiler die Version 7.5 zum Einsatz, GCC 10 und GCC 11 in aber in den Paketquellen enthalten. Eingefleischte openSUSE-Anwender werden das kaum seltsam finden, aber für Außenstehende wirkt das etwas seltsam. Unerwünschte Nebenwirkungen sind in meinen Tests aber nicht aufgetreten.

Installation und Vorkonfiguration

Installation und Vorkonfiguration wurden nicht verändert. Hier ist ein neuer Test also überflüssig. Als Standarddateisystem kommt Btrfs zum Einsatz, das mittels Snapper Betriebssystemschnappschüsse bei Updates anlegt. Datenpartitionen werden standardmäßig mit XFS angelegt, was bei einer dezidierten Home-Partition auch für diese zum Einsatz kommt.

Als Bootloader nimmt openSUSE GRUB 2.06. Man unterstützt Secure Boot und mittels Trusted Boot auch ein rudimentäres TPM-Measurement für den Boot-Prozess.

Die Verschlüsselung geschieht bei der Installation immer noch mit LUKS1 und das System benötigt weiterhin einen dezidierten root-Account. Neu ist die Möglichkeit bei der Installation SELinux anstelle von AppArmor aktivieren zu können. Die SELinux-Integration steckt bei SUSE aber noch in den Kinderschuhen und ich persönlich würde bei einem Produktivsystem davon absehen.

Nutzungserlebnis

Die Entwickler haben aus manchen vergangenen Fehlern gelernt. Die SLE-Updatequellen sind so schon seit längerem eingebunden. Allerdings ist der Entwicklungsprozess immer noch etwas schwierig und die Kommunikation zwischen SLE-Teams und openSUSE klappt manchmal nicht. Das hatte in der RC-Phase durch plötzliche massive Änderungen bei SLE SP4 einige Verzögerungen ausgelöst. Trotzdem halte ich unliebsame Überraschungen direkt nach dem Release dieses Jahr für nahezu ausgeschlossen.

Im täglichen Nutzungserlebnis profitiert man von der gut abgehangenen Basis, die lediglich an relevanten Stellen wie Kernel oder Mesa behutsam modernisiert wurde und den gleichzeitig aktuellen Desktopanwendungen. Da es hier bei den Desktopumgebungen quasi von KDE Plasma bis MATE und bei den Anwendungen von LibreOffice bis Firefox in den letzten Jahren keine umstürzenden Änderungen gab, sind diese aktuell sehr ausgereift und es entsteht eine wirklich gelungene Gesamtkomposition.

Fazit

Ein rundum gelungenes Release. Bestehende Anwender von openSUSE Leap können gefahrlos und mit Vorfreude aktualisieren. Ob Wechselwillige die Version zum Anlass nehmen umzusteigen, steht auf einem anderen Blatt. Nächstes Jahr kommt planmäßig dann noch mal eine deutlich moderatere Wartungsversion, bevor 2024 dann vermutlich revolutionäre Änderungen anstehen.

Leider haben die Entwickler nicht alle notwendigen Änderungen für systemd-homed zurück portiert, weshalb ich wohl bei Tumbleweed bleibe, da ich mich sehr an die TPM-Entsperrung mit zusätzlich abgesicherten Nutzerprofilen gewöhnt habe.

Mozilla rollt aktuell den sogenannten vollständigen Cookie-Schutz für alle Firefox-Nutzer aus und verbessert damit den Datenschutz seiner Nutzer.

Derzeit erhalten einige Nutzer von Firefox 91 und höher nach dem Start von Firefox einen Dialog mit der Option, die „leistungsstärkste Datenschutzerfahrung aller Zeiten“ zu aktivieren. Was hat es damit auf sich?

Vollständiger Cookie-Schutz – was ist das?

Im Februar 2021 hat Mozilla mit der Veröffentlichung von Firefox 86 den sogenannten „vollständigen Cookie-Schutz“ eingeführt. Vereinfacht gesagt bedeutet dies, dass die Cookies jeder Domain in einem separaten Cookie-Container gespeichert werden – seitenübergreifendes Tracking über Cookies soll damit erschwert werden.

Mehr Datenschutz für alle Firefox-Nutzer

Aktiviert war diese Datenschutz-Verbesserung bisher nur für Nutzer, welche in den Datenschutz-Einstellungen von Firefox den strengen Schutz vor Aktivitätenverfolgung aktiviert haben, sowie in privaten Fenstern.

Mit dem Dialog, den einige Firefox-Nutzer aktuell angezeigt bekommen, lädt Mozilla seine Nutzer ein, diese Datenschutz-Verbesserung auch in der Standard-Konfiguration von Firefox zu aktivieren und vorab zu testen, ehe dies irgendwann in der Zukunft vermutlich Standard für alle Nutzer werden wird.

Übrigens lässt sich die Entscheidung jederzeit über die Datenschutz-Einstellungen ändern. Nutzer, welche diesen Dialog gesehen haben, erhalten in den Datenschutz-Einstellungen auch eine zusätzliche Checkbox, über welche das Feature aktiviert respektive deaktiviert werden kann.

Der Beitrag Firefox: Mozilla rollt vollständigen Cookie-Schutz für alle Nutzer aus erschien zuerst auf soeren-hentzschel.at.

Eine kleine Lektüreempfehlung zum Feiertag. Andreas Proschofsky hat bei DerStandard eine sehr lesenswerte Erklärung der wichtigsten Linux-Begriffe verfasst. Sachlich korrekt, ausgewogen und ab und an mit einer kleinen Prise Humor.

Sicherlich nicht nur für Neulinge im Linux-Universum eine interessante Lektüre. Vom Kernel bis zu Wayland und Pipewire wird alles, was momentan so relevant ist ausführlich erklärt. Natürlich immer ein bisschen subjektiv, aber es ist auch kleine Enzyklopädie. Wer Wahrheiten sucht und andauernd „Fakten“ brüllt, sollte auch hier woanders weiter schauen. Mich hatte der Autor an diesem Punkt:

Bonus-Hinweis für Puristen: Genau genommen ist der Kernel nicht der zentrale Teil von Linux, er ist Linux. Über die Jahre hat sich aber eingebürgert, auch (viele) ihn umgebende Systeme als Ganzes so zu benennen. Wer gerne recht hat, darf diesen Umstand also unter jedem Artikel zu Linux als System als faktische Korrektur anmerken. Oder aber man verzichtet freiwillig darauf, sich bei allen anderen unbeliebt zu machen.

Kernel? Wayland? Pipewire? Die wichtigsten Linux-Begriffe, einfach erklärt

Viel Spaß beim lesen.

Ich nutze rsync in Verbindung mit dem rsync-time-backup für einfache Backups eines Servers. In letzter Zeit erhielt ich dort ein Problem mit bestimmten Dateien, welche ich synchronisieren wollte. rsync brach hier mit der Meldung: ab. Abhilfe schaffte es hier rsync, ohne die Option –compress zu nutzen. Hier liegt wohl ein Problem bzw. ein Bug vor, der unter Umständen zu diesem Verhalten führt.

Quelle

Passwörter sind eine unsichere Angelegenheit. Deshalb gab es in den vergangenen Jahren viele Versuche, Passwörter zu ersetzen oder sicherer zu machen. Einer dieser Versuche, ist der Ansatz mit einem physischen zweiten Faktor zu arbeiten. Dank systemd lässt sich das nun einfacher denn je für Linux Verschlüsselung nutzen.

Die Erkenntnis, dass Passwörter unsicher sind, gehört inzwischen zum Standardsatz, mit dem man jeden Artikel dazu einleiten muss. Firmen arbeiten deshalb mit biometrischen Verfahren und vielen anderen Ansätzen. Ich persönlich schätze meinen YubiKey sehr, aber leider unterstützen den noch viel zu wenige Dienste.

Dank der tollen Entwickler im systemd-Umfeld, die stetig daran arbeiten, neue Funktionen für Linux zur Verfügung zu stellen, kann man nun aber einen FIDO-Stick wie YubiKey (Alternativen wie Nitrokey gehen natürlich auch) sehr einfach nutzen, um vollständig mit LUKS verschlüsselte Linux-Systeme zu sichern. Das geht für Arch Linux und Debian schon länger, war aber ein ziemliches „gefrickel“ und ist ein tolles Beispiel dafür, wie systemd Sachen einfach besser umsetzt und auf solidere Füße stellt. Die Funktionsweise ähnelt der Entsperrung von LUKS-gesicherten Systemen mittels TPM.

Einrichtung

Im Folgenden zeige ich die Einrichtung unter openSUSE. Sie funktioniert für openSUSE Tumbleweed und Leap 15.4. Das Verfahren dürfte aber für jede Distribution funktionieren, die systemd nutzt und keine Sonderlocken verfolgt. Arch Linux hat sie kürzlich in archinstall integriert.

Die Voraussetzung ist aktuell ein Partitionslayout mit einem vollständig verschlüsselten LUKS-System (egal, ob Root-Partition und Home-Partition getrennt sind) und eine unverschlüsselte Boot-Partiton. Der LUKS-Container muss dem LUKS2-Standard folgen. Bestehende SUSE-Installationen müssen daher erst auf LUKS2 konvertiert werden. Neue Installationen können mit der Startoption YAST_LUKS2_AVAILABLE=1 direkt als LUKS2 angelegt werden.

Nach der Umsetzung der Anleitung benötigt man für jeden Systemstart den eingesteckten YubiKey. Es gibt keinen automatischen Fallback-Mechanismus.

Zuerst ist ein Paket nachzuinstallieren. Je nach Setup ist es möglicherweise schon installiert (z. B. als Abhängigkeit von KeePassXC).

# zypper install libfido2-1

Nun steckt man den YubiKey ein. Mit folgendem Befehl führt man die Integration des YubiKey als Schlüssel für LUKS aus.

# systemd-cryptenroll --fido2-device=auto /dev/<LUKS-DEVICE>

Das Laufwerk ist natürlich anzupassen. In der Regel muss man mit dem bisherigen LUKS-Passwort bestätigen. Der YubiKey wird dann in den nächsten freien Key-Slot geschrieben.

Anschließend ist noch die /etc/crypttab zu bearbeiten und fido2-device=auto am Ende zu ergänzen. Das Ergebnis sieht dann in etwa wie folgt aus:

cr-auto-1  /dev/<LUKS-Device>  none  x-initrd.attach,fido2-device=auto

Nun noch mittels dracut den initramfs neu erstellen.

# dracut -f

Bei einem Neustart wartet das System nun auf die Betätigung des YubiKey. Mangels Implementierung in Plymouth gibt es keinen grafischen Hinweis dazu auf dem Bildschirm, aber der YubiKey blinkt und zeigt dadurch an, dass eine Interaktion notwendig ist.