Wenn das Ego zum Problem wird

Linux und Open Source sind in meinen Augen einige der respektabelsten und imposantesten Projekte, die es in der heutigen Zeit gibt. Unter ‚Open Source‘ finden sich genug Skripte, Tools, Programme und Systemkerne, dass es nicht nur für ein ganzes Betriebssystem reicht, sondern für mehrere. Mit einem ganzen Ökosystem an Anwendungen, die es möglich machen, beinahe alles umzusetzen, was man möchte.

Doch so positiv und imposant diese Seite der Medaille ist, sie hat immer zwei Seiten.

Man hat es in den letzten Jahren immer wieder am Rande mitbekommen:

Hier ist die Liste der bedeutenden Sicherheitslücken, die Linux und Open-Source-Software in den letzten zehn Jahren betroffen haben und aus der Ferne ausgenutzt werden können, mit dem CVE und CVE-Score:

• Log4Shell (CVE-2021-44228, CVSS 10.0) (2021)
  • Eine Schwachstelle zur Remote-Code-Ausführung in der Apache Log4j 2-Bibliothek, die durch das Senden einer speziell gestalteten Anfrage an Server, die die Bibliothek verwenden, ausgenutzt werden kann.
• BootHole (CVE-2020-10713, CVSS 8.2) (2020)
  • Eine Schwachstelle im GRUB2-Bootloader, die den sicheren Boot-Prozess betrifft und es Angreifern ermöglicht, während des Systemstarts beliebigen Code auszuführen.
• SACK Panic (CVE-2019-11477, CVSS 7.5) (2019)
  • Eine Reihe von Schwachstellen in der TCP Selective Acknowledgment (SACK)-Verarbeitung des Linux-Kernels, die zu Denial-of-Service-Angriffen führen können.
• Ghost (CVE-2015-0235, CVSS 5.9) (2015)
  • Eine kritische Schwachstelle in der glibc-Bibliothek, die es ermöglicht, durch die gethostbyname-Funktionen Code aus der Ferne auszuführen.
• Freak (CVE-2015-0204, CVSS 4.3) (2015)
  • Eine Schwachstelle in SSL/TLS, die Clients zwingt, schwächere Verschlüsselung zu verwenden, wodurch Angreifer sichere Kommunikation abfangen und entschlüsseln können.
• Poodle (CVE-2014-3566, CVSS 4.3) (2014)
  • Eine Schwachstelle in SSL 3.0, die es Angreifern ermöglicht, sichere HTTP-Cookies zu entschlüsseln, indem sie eine Schwachstelle im Fallback-Mechanismus des Protokolls ausnutzen.
• Shellshock (CVE-2014-6271, CVSS 9.8) (2014)
  • Eine Schwachstelle in der Bash-Shell, die es ermöglicht, durch die Art und Weise, wie Bash Umgebungsvariablen verarbeitet, aus der Ferne Code auszuführen.
• Heartbleed (CVE-2014-0160, CVSS 7.5) (2014)
  • Eine Schwachstelle in der OpenSSL-Bibliothek, die es Angreifern ermöglicht, sensible Speicherinhalte auf betroffenen Servern zu lesen, indem sie eine Schwachstelle in der Heartbeat-Erweiterung ausnutzen.

Es gibt genug Seiten, Artikel und ganze Dossiers, die sich mit dem technischen und auch dem menschlichen Teil beschäftigen. Wir alle wissen: Open Source ist unterfinanziert und es gibt eine überzogene Erwartungshaltung an die „tausend Augen, die immer und überall den Code überprüfen“. Dass dieser Mythos nicht zutrifft, hat man an dem  XZ-Debakel gesehen.

Allerdings gibt es noch ein weiteres Problem in der Open Source Community: das überbordende Ego einiger Weniger, welches ganze Communities so toxisch werden lässt, dass ein Open Source Projekt entweder im Sterben liegt oder schon tot ist. Was auch immer wieder passiert, ist, dass einige wenige eine so triefende Arroganz gegenüber den Usern entwickeln, dass man nur noch mit dem Kopf schütteln kann.

Weiterlesen: Wenn das Ego zum Problem wird

Gentoo

Ein schönes Beispiel ist hier Gentoo, bei denen Leute angegiftet werden, die es wagen Verbesserungsvorschläge zu machen, oder neu hinzugefügte Funktionen in Frage zu stellen:

Es geht in dem Bug noch weiter mit mehr sinnlosem Flaming weil man es gewagt hat Feedback zu geben, aber das ist nur eine Randnotiz. „Emerge“ ist jetzt kein Tool das eine wirklich große Verbreitung hat und der Gentoo Staff ist eh ein ganz eigenes Völkchen, das schon stark an eine Diktatur erinnert.

Der menschliche Faktor hier ist aber unübersehbar. Das Ego einer einzelnen Person ist so dermaßen toxisch, dass reihenweise Mitarbeiter das Projekt verlassen. Die Entwicklercommunity wird kleiner. Das fällt übrigens auch auf: Die Anzahl der gewarteten Gentoo-Pakete wird von Mal zu Mal kleiner. Ich wollte zu diesem Thema schon 2023 einen Post verfassen, habe mich dann aber dagegen entschieden. Ich war damals einfach zu sehr in bestimmte interne Themen involviert, und das Ganze hätte aufgefasst werden können als „Der will Gentoo schaden“. Aber einige Daten kann ich aus diesem nicht veröffentlichten Artikel übernehmen:

Gentoo verliert immer mehr Package-Maintainer und Entwickler. Unser rüpelhafter Kollege aus unserem Beispiel schreibt es ja selbst: Viel Arbeit, wenig Engagement. (Sollte der Artikel auf einmal verschwinden, hier gibt es eine Kopie.) Ich fasse den Post einmal kurz zusammen:

„Gentoo-Entwickler sind überlastet, es gibt viele ungelöste Bugs, ungewartete Pakete und offene Pull-Requests. Dieses Problem betrifft jedoch nicht nur Gentoo, sondern alle großen Projekte, besonders solche, die hauptsächlich auf Freiwilligenarbeit basieren. Das Hauptproblem ist der „bit rot“ (‚verrottende bits‘)– das Veralten von Software – aufgrund von unzureichender Wartung.
Pakete sind das Herzstück einer Linux-Distribution. Eine große Anzahl an Paketen kann ein Vorteil sein, bedeutet aber auch viel Wartungsaufwand. Wenn Pakete nicht richtig gepflegt werden, werden sie veraltet und fehlerhaft. Dies führt zu Frustration bei den Nutzern, die auf unbrauchbare oder veraltete Software stoßen.
Freiwillige arbeiten an dem, was sie interessiert. Man kann sie nicht zwingen, ungeliebte Aufgaben zu übernehmen. Daher bleibt oft viel Arbeit liegen, während neue Pakete hinzugefügt werden. Der Arbeitsmarkt verschärft das Problem, da die meisten Entwickler nebenbei arbeiten und oft ausgelaugt sind.
Proxy-Maintenance sollte helfen, hat aber seine Grenzen. Es braucht immer jemanden, der die Arbeit überprüft und freigibt. Langfristig bleibt als Lösung oft nur das Entfernen ungewarteter Pakete. Das ist weniger Aufwand als sie ständig zu reparieren. Entfernte Pakete können nach GURU verschoben werden, wo sie vielleicht einen neuen Betreuer finden.
Die einzige dauerhafte Lösung ist also das Entfernen nicht gewarteter Pakete, um den Aufwand zu verringern und die Qualität für die Nutzer zu verbessern.“

Michał schreibt es also selbst: Zu viele Pakete und zu wenig Leute, die das Ganze bearbeiten und verwalten. Was er scheinbar nicht beachtet: Es hat doch bisher funktioniert? Ich kenne mittlerweile einige ehemalige Gentoo-Entwickler und Package-Maintainer, und die Aussagen von allen sind mehr oder weniger dieselben: „Ich mag Gentoo und werde es auch weiter nutzen, aber ich bin verdammt froh, da raus zu sein. Das wurde mir zu diktatorisch, zu herrisch, und wenn du nicht mitgezogen hast, wurdest du halt rausgemobbt.“ Diese Aussage wurde mir in unterschiedlichen Worten von mehreren, unabhängig voneinander agierenden Entwicklern gemacht. Also auch hier: Ein Egotrip von Wenigen, die das Projekt für viele verderben und auf kurz oder lang die Qualität oder das ganze Projekt demontieren.

Dass Entwickler und Engagement schwanken, ist bei allen Projekten so. Aber es ist nicht der Grund, warum die Arbeit immer mehr und die Mitarbeiter immer weniger werden. Die Wirtschaftslage, der Jobmarkt und andere Faktoren spielen auch nur eine untergeordnete Rolle. Wären dies die Hauptgründe, würde das Problem alle Distributionen betreffen, nicht nur Gentoo. Und um ehrlich zu sein: Ich sehe keinen Schwund bei Linux Mint, Debian oder Arch. Eher das Gegenteil. Die gewarteten Pakete steigen dort eher an.

Wer weiß, vielleicht könnte es helfen, keine arrogante „Ich-bin-was-Besseres-als-du-weil-ich-xyz-habe/bin“ Mentalität an den Tag zu legen und sein Ego im Zaum zu halten?

Das Drama zieht sich irgendwie durch viele Plattformen und es sind auch irgendwie immer dieselben Namen die hier auftauchen.

Systemd

Viel interessanter finde ich da einen recht jungen Bug über den ich gestolpert bin: Systemd und der Umgang mit „Tempfiles“.

Der „Bug“ in Systemd bewirkt das im Systemverzeichnis /home munter „aufgeräumt“ wird, wenn man eine Systemd-Funktion verwendet die eigentlich nur temporäre Dateien aufräumen sollte.

Ich fasse es einmal mit den Worten von „Betonhaus“ zusammen:

Temporäre Dateien in einem Computersystem…

• … kann man perfekt ohne signifikante Datenverluste mithilfe vorhandener Informationen regenerieren
• … wurden verwendet, um endgültige Daten zu generieren, und können gelöscht werden, sobald diese endgültigen Daten gesichert wurden
• … können gelöscht werden, wobei die einzige Konsequenz ist, dass ein Prozess, der die Daten verwendet, temporäre Dateien bei Bedarf neu generieren muss oder dass ein Neustart des Prozesses erforderlich ist, um die normale Nutzung fortzusetzen.“

Es sind „temporäre“ Daten, also Dateien die nicht dauerhaft benötigt werden.

In den Optionen von systemd-tmpfiles sieht man folgendes (Version 256.1, die bereits „gefixte“ Version):

systemd-tmpfiles --help
systemd-tmpfiles COMMAND [OPTIONS...] [CONFIGURATION FILE...]

Create, delete, and clean up files and directories.

Commands:
--create   Create files and directories
--clean    Clean up files and directories
--remove   Remove files and directories marked for removal
--purge    Delete files and directories marked for creation in specified configuration files (careful!)
-h --help  Show this help
--version  Show package version

Options:
--user     Execute user configuration
--cat-config Show configuration files
--tldr     Show non-comment parts of configuration
--boot     Execute actions only safe at boot
--graceful Quietly ignore unknown users or groups
--prefix=PATH Only apply rules with the specified prefix
--exclude-prefix=PATH Ignore rules with the specified prefix
-E         Ignore rules prefixed with /dev, /proc, /run, /sys
--root=PATH Operate on an alternate filesystem root
--image=PATH Operate on disk image as filesystem root
--image-policy=POLICY Specify disk image dissection policy
--replace=PATH Treat arguments as replacement for PATH
--dry-run  Just print what would be done
--no-pager Do not pipe output into a pager

See the systemd-tmpfiles(8) man page for details.

Unabhängig von der Beschreibung: Der Befehl, der Kontext des Befehls… Es sollte sich hier nur um TEMPORÄRE Dateien handeln.

systemd-tmpfiles löscht Daten, die durch diesen Dienst angelegt wurden. Leider macht systemd hier einen großen Fehler: Es legt auch Systemordner an. Die „Purge“-Funktion löscht also nicht nur temporäre Daten, die von den einzelnen systemd-Units/Services/Sockets angelegt wurden, sondern ALLE Daten und Ordner, die über diesen Service angelegt wurden. Warum systemd tmpfiles benutzt, um Homeverzeichnisse oder Ordner darin anzulegen, ist mir schleierhaft. Allerdings bin ich kein systemd-Entwickler. Ich bin ein User, jemand, der die Tools benutzt, die mir zur Verfügung gestellt werden. In meinem Verständnis ist es ein Fehler – ein Bug –, wenn ein Tool, das temporäre Dateien löschen soll, beginnt, munter in meinen nicht-temporären Dateien herumzulöschen.

Darum soll es aber gerade nicht gehen. VIEL INTERESSANTER ist hier die erste Reaktion eines Entwicklers:

Es wird in keiner Weise irgendwie auf den Fehler eingegangen. Statt sich genau durchzulesen, was das Problem hier tatsächlich ist, und darüber nachzudenken, dass es Anwender gibt, die nicht den Tunnelblick des Entwicklers haben (was im eigentlichen Bugreport auch angesprochen wird), kommt direkt der Beißreflex: „Das ist kein Fehler, du benutzt es falsch!“ Das ist übrigens nicht das erste Mal, dass ein systemd-Entwickler so reagiert. Vor einiger Zeit gab es einen Fehler, bei dem Benutzer mit einer Ziffer als erstem Zeichen versehentlich root-Rechte erhielten. Unabhängig davon, dass man keine Usernamen mit einer Ziffer am Anfang erstellen sollte, da diese gegen die Richtlinien verstoßen, IST ES MÖGLICH! Auch heute noch.

Die Reaktion der Entwickler? – „Unbezahlbar“:

Auf gut Deutsch: „Es gibt keinen Fehler, du nutzt es falsch“.

Dennoch: ES IST MÖGLICH! Und es gibt eine „Privilege Escalation„! ES IST EIN VALIDER BUG!

Sich hinzustellen und zu sagen: „Ja ne, ihr nutzt das falsch und alles funktioniert wie es soll“ ist hier so ziemlich das Dämlichste, was man machen kann. „Da es eine Richtlinie gibt, die sagt, man SOLLTE keine User mit führender Ziffer erstellen, müssen wir hier nichts machen. Man kann diese Richtlinie zwar ohne Konsequenzen ignorieren und beliebige Dienste mit administrativen Berechtigungen laufen lassen, aber hier gibt es kein Problem.“

Wir alle wissen ja: Hacker und andere „Bad Actors“ halten sich IMMER an OS-Richtlinien…

Böse Zungen könnten folgendes einwerfen: Beide Entwickler sind fest angestellt bei Microsoft. Und was in letzter Zeit aus dem Hause MS kommt, strotzt nicht gerade vor Qualität. Oder Sicherheit. Oder Performance. Oder intuitiver Bedienung…

Ein Schelm, wer Böses dabei denkt, bei einer solchen Mentalität. 😉

Wer Interesse am Thema „Sicherheit made by Microsoft“ hat, kann lesen:

• Outlook Zero-Day Exploit (März 2024)
• New Azure Cosmos DB Vulnerability (Februar 2024)
• ProxyNotShell-Schwachstellen (Februar 2023)
• Azure Hack durch China (2023)
• Azure Hack durch Russland (2023)

Closing Words

Ich weiß, dass dieser Post wie eine Abrechnung oder Schuldzuweisung aussieht. In gewisser Weise stimmt das auch. Ich erlebe leider immer wieder, wie großartige Projekte, vielversprechende Ansätze und neue Wege mutwillig gestoppt oder zerstört werden, weil sie das Ego eines anderen berühren. Ich möchte nicht wissen, wie viele Linux-Distributionen nur deshalb entstanden sind, weil irgendwer der Meinung war: „Ich bin besser als die anderen, ich kann das besser, ich bin einfach der King.“

Ich bin nicht anders als die hier gezeigten Beispiele. Ich bin momentan nebenher dabei, ein Webradio aufzubauen, weil ich der Meinung bin: „Ich kann das besser als XYZ.“ Wobei „besser“ hier eventuell ein wenig übertrieben ist. Ich kann das nicht „besser“, ich kann das „anders“. Ob es funktioniert oder nicht, sehe ich dann, wenn es funktioniert oder eben nicht. Der Punkt ist, dass ich nicht auf andere herabsehe und sage: „Guck dir die mal an, die sind so dumm“, oder, wie in den obigen Beispielen, anfange, Leute zu beleidigen. Konstruktive Kritik sollte konstruktiv angenommen werden.

„Halte nicht an einem Fehler fest, weil du viel Zeit damit verbracht hast, ihn zu begehen.“ Perfektion gibt es nicht, besonders nicht in der IT. Und niemand ist unfehlbar.

Was ich mit diesem Post bezwecken will, ist nicht, andere zurechtzuweisen und den erhobenen Finger zu zeigen. Der Zweck ist eher, aufzuzeigen, wie man es nicht macht, und dass man gelegentlich vielleicht mal über seine eigenen Worte und Handlungen reflektieren sollte.