Anfang Dezember schrieb ich bereits über ein merkwürdiges Sicherheitsproblem bei KDE neon (siehe: Kommentar: KDE neon – Wirklich so sicher?). Nach einer genaueren Recherche ist das Problem noch deutlich gravierender, weil sich eine geringe Priorisierung der Sicherheit in den Projekten offenbart.

Anfang August schlägt das Thema im KDE Bugtracker auf. Dort erfolgt der Verweis auf einen offenen Bug in Calamares, der seit dem 29. Januar 2020 bekannt ist. Noch mal zum Rekapitulieren, hier geht es nicht um einen nicht funktionierenden Button auf Seite 3 irgendeiner Software, sondern um die falsche Speicherung des LUKS Schlüssels im initramfs, womit die komplette Systemverschlüsselung hinfällig ist.

Regelrecht erbärmlich ist der Whataboutism-Stil im Calamares-Bugtracker. Mehrere kommentierende Personen erwecken den Eindruck, eine nicht verschlüsselte Boot-Partition wäre sowieso so unsicher, dass das Thema hinfällig wäre. Das ist erstens Nonsens ist zweitens ist eine nicht verschlüsselte Boot-Partition über Jahrzehnte Standard bei allen Linux-Distributionen gewesen. Natürlich geht der Trend in die Richtung einer Komplettverschlüsselung inklusive Boot-Partition, aber der Sicherheitsgewinn ist stark theoretischer Natur. Anstelle das Problem zu lösen baut man eine kryptische Warnung ein und das war es dann bis jetzt.

Das ist auf so vielen Ebenen eine Katastrophe, das es mir sehr schwerfällt hier einen sachlichen Artikel zu schreiben.

  1. Das ist ein riesiges Sicherheitsproblem und gehört ganz weit oben in die Prioritätenliste einer Installationsroutine und nicht irgendwo unter 169 andere offene Bugs.
  2. Es zeigt einmal mehr, dass Installationsroutinen nicht so trivial sind, dass man hier mal eben so was hinzimmert (flapsig formuliert: KDE will eine eigene Installationsroutine).
  3. KDE neon steht als inoffizielles Ubuntu-Derivat natürlich der Ubiquity Installer zur Verfügung, den man auch lange verwendete. Aus irgendwelchen nicht nachvollziehbaren Gründen (ich vermute es handelt sich hier um eine „poltiische“ und nicht sachorientierte Entscheidung) wechselte man hier auf Calamares.

Jetzt kann man natürlich argumentieren, dass dem Anwender das Problem schon auffallen wird und er dann was anderes (was eigentlich?) unternimmt. Viele Distributionen mit Calamares richten sich aber eher an Einsteiger. Was ist, wenn diese den Loginscreen dann für die Passwortabfrage zur Vollverschlüsselung halten?

Meiner Meinung nach ist das ein totales Debakel. Wäre dieser Lapsus Microsoft, Apple oder Canonical unterlaufen – das Echo wäre gewaltig. So bleibt es unter dem Radar (der Fehler besteht übrigens immer noch!).

Es zeigt aber deutlich, dass Linux und Sicherheit nicht einfach gleich gesetzt werden dürfen. Linux ist sicher, aber man sollte eine professionell geführte Distribution mit einem seriösen Sicherheitsteam nehmen. Ich möchte gar nicht wissen, was bei diesen kleinen Projekten noch für Sicherheitsrisiken unter der Oberfläche schlummern, die sich einfach niemand im Detail angeguckt hat.

Für weitere Hinweise oder wenn ich hier etwas falsch interpretiert haben sollte, bin ich natürlich dankbar!


Bilder:

Einleitungs- und Beitragsbild von Tumisu via Pixabay

Moin, meine Name ist Gerrit und ich betreibe diesen Blog seit 2014. Der Schutz der digitalen Identität, die einen immer größeren Raum unseres Ichs einnimmt ist mir ein Herzensanliegen, das ich versuche tagtäglich im Spannungsfeld digitaler Teilhabe und Sicherheit umzusetzen. Die Tipps, Anleitungen, Kommentare und Gedanken hier entspringen den alltäglichen Erfahrungen.

Schreiben Sie eine Ergänzung

Ergänzungen dienen der Diskussion über die Inhalte des Artikels. Nachfragen, Anmerkungen und Ergänzungen sind dezidiert erwünscht. Ergänzungen werden vor der Veröffentlichung moderiert. Wir behalten uns vor Kommentare ohne inhaltlichen Bezug oder abseitige Diskussionen nicht zu veröffentlichen.

Bitte geben Sie Ihre Ergänzung ein!
Bitte geben Sie hier Ihren Namen ein