Die weitverbreiteten Datenkompressionswerkzeuge XZ Utils (früher LZMA Utils) enthalten in Version 5.6 eine Backdoor. Ziel der Backdoor ist nach aktuellem Kenntnisstand eine Kompromittierung von SSH-Servern. Dies wurde gestern auf der oss-security-Mailingliste von Andres Freund nebst einer umfangreichen Analyse des Sachverhalts bekannt gegeben. Durch den Einsatz der Werkzeuge in Linux-Distributionen haben wir hier einen Fall einer Supply-Chain-Attacke. Red Hat hat dem Vorfall die CVE-Nummer CVE-2024-3094 vergeben.

Vorab eine Liste mit weiteren Links:

• Stellungsnahmen von verschiedenen Distributoren
  • Arch Linux
  • Debian
  • Red Hat
  • SUSE
• FAQ
• Hacker-News-Diskussion
• Zeitleiste

Wirkungsweise

Dabei wird die Backdoor nur unter bestimmten Bedingungen ausgeführt, wie das FAQ beschreibt. Im Wesentlichen muss argv[0] auf /usr/sbin/sshd gesetzt sein und eine Reihe an Umgebungsvariablen entweder gesetzt oder nicht gesetzt sein. Normalerweise hängt OpenSSH nicht von liblzma ab. Einige Distributoren patchen OpenSSH allerdings so, dass systemd-Notifcations funktioniert, welches wiederum auf liblzma setzt und die Backdoor möglich macht. Technisch werden einige Checks durchgeführt und anschließend mittels IFUNC Bibliotheksaufrufe umgeleitet. Dies betrifft nach aktuellem Stand auch Aufrufe während der Kryptoroutinen bei der SSH-Authentifizierung.

Betroffenheit

Der Wirkungsweise der Payload ist noch nicht abschließend geklärt. Besonders auch aus diesem Grund wird ein unverzügliches Update angeraten. Im Folgenden einige unverbindliche Faktoren, die eine Verwundbarkeit wahrscheinlich machen. Auf diese Weise kann man priorisieren, welche Systeme zuerst aktualisiert werden sollten.

Versionierte Distros wie z. B. Debian oder RHEL sind nach aktuellem Kenntnisstand mit ihren stabilen Versionen nicht direkt betroffen, da die Versionen 5.6 noch keinen Einzug in das System gefunden haben. Die Testing-Versionen dieser Distros wie z. B. Debian Sid wurden allerdings aktualisiert und sind betroffen.

Rolling-Release-Distros sind naturgemäß auch betroffen, wenn sie schon Version 5.6 in ihre Pakete aufgenommen haben. Dies betrifft zum Beispiel Arch Linux oder Gentoo. Da allerdings einige Distributionen wie Arch Linux OpenSSH nicht gegen liblzma linken, wird die Bibliothek nicht direkt in die Ausführung der Komponenten eingebunden.

Nach aktuellem Stand wird eine Verwundbarkeit besonders kritisch, wenn auf dem betroffenen Host ein öffentlich erreichbarer SSH-Server läuft, da die oben beschriebenen Faktoren ein Laden der Payload auslösen können.

Wie kam es?

Aufgefallen ist die Backdoor nur durch Zufall durch das Debugging von Performanceproblemen, die durch die Backdoor verursacht wurden. Die Backdoor wurde obfuskiert im Rahmen von Buildskripten untergebracht, sodass aufgrund der Komplexität die Lücken noch nicht direkt aufgefallen sind.

Das Repository hinter xz kann als kompromittiert gesehen werden und ist auch auf GitHub schon gesperrt worden. Auffällig ist, dass die Backdoor in den Tarballs der Releases enthalten war, nicht jedoch im Repository-Dump selber. Auch personell gab es einige Auffälligkeiten, da es vor kurzem einen Maintainerwechsel beim Projekt gab und die Lücken vom neuen Maintainer, der seit 2 Jahren am Projekt mitarbeitet, zumindest begünstigt wurden. Die Art und Weise lässt auch auf ein koordiniertes, von langer Hand geplantes Vorgehen schließen.

Einfluss und Folgen

Das große Ganze ist ein Paradebeispiel von xkcd 2347 "Dependency". Wir sehen hier Live ein Beispiel einer Supply-Chain-Attacke. Ein kleines, scheinbar unbedeutendendes Projekt wird übernommen, nur um strategisch Commits zu platzieren, die automatisch "flussabwärts" ihren Weg in größere Distributionen finden, die allesamt auf das Projekt setzen. Alles passiert trotz Open Source. Besonders pikant: der Maintainer hat aktiv versucht, die Backdoor-begünstigenden Umgebungsfaktoren, konkret das Umbiegen von Bibliotheksaufrufen mittels ifunc, in Fuzzing-Projekten wie oss-fuzz, die aktiv nach sowas suchen, zu deaktivieren.

Software wird immer bedeutender und benötigt Vertrauen. Dabei ist jetzt schon klar, dass niemand selber solch komplexe Systeme von alleine bauen kann. Aber auch die Kontrolle der Quellen ist eine große Herausforderung. Neue Gesetzgebung wie der geplante Cyber Resilience Act in der EU versuchen in der Industrie Anreize zu schaffen, die Softwarequalität zu erhöhen.

Diese Attacke konnte einigermaßen abgewendet werden, sollte die umfassende Analyse der Payload keine belastenden Neuigkeiten hervorbringen. Eines ist aber auch klar: Die Angreifer studieren das Verhalten der Verteidiger und werden in Zukunft ihre Vorgehensweise dahingehend optimieren, nicht so einfach mehr gefunden zu werden. Es ist also möglich, Backdoors in so ein Ökosystem hineinzuschummeln. Umso besser müssen aber die Identifikations- und Abwehrmöglichkeiten werden, damit solche Angriffe wirksam verhindert werden können.

Die gestrige Veröffentlichung von Linux 6.6 bedeutet, dass das Merge-Window wieder geöffnet ist. Ein erster Kandidat wurde bereits gemerged mit einem Vorhaben, das in den vergangenen Wochen zu vielen Diskussionen geführt hat: bcachefs.

Um bcachefs zu erklären, muss ich kurz ein wenig weiter ausholen. bcachefs geht - wie der Name schon vermuten lässt - auf bcache zurück. Hierbei handelt es sich um ein Kernelmodul, das Einzug in Linux 3.10 in 2013 fand und einen Caching-Layer für Block-Devices einführte.

Daten können somit hybrid zwischen ganz schnellem Speicher (RAM), schnellem Speicher (SSDs) und langsamem Speicher (HDD) aufgeteilt werden. Werden bestimmte Blöcke häufiger abgerufen, werden sie in den schnelleren Speicher verschoben und anders herum ebenso. Dabei handelte es sich aber immer um eine Zwischenschicht, auf der ein echtes Dateisystem aufbauen musste. Während der Entwicklung fiel dem Hauptentwickler Kent Overstreet jedoch schnell auf, dass zu einem "full-fledged" Filesystem nicht mehr viel fehlte.

Ein erster Prototyp entstand bereits im Jahre 2015 und hat somit die Ära der Dateisysteme der neusten Generation eingeläutet. Auch btrfs gehört zu diesen moderneren Dateisystemen und setzt auch auf das Copy-on-Write-Prinzip. Da die Blöcke einer Datei nicht bei einer Kopie dupliziert werden, spart dies Speicherplatz und ermöglicht verzögerungsfreie Snapshots.

bcachefs mit seinen über 90.000 Zeilen Code konnte zwar - wie für ein neues Dateisystem üblich und nötig - ausgiebig getestet werden, war allerdings bisher nicht im Mainline Linux vorhanden. Mitte des Jahres ging es dann an die Einarbeitung des Codes.

Eigentlich sollte bcachefs schon in Linux 6.5 Einzug halten. Aber aufgrund andauernder Spannungen wurde auch bei Linux 6.6 aus dem Vorhaben nichts. Eines der Probleme sind die teils umfangreichen Änderungen in fremden Modulen, die den Unmut der Maintainer auf sich gezogen haben. Wer sich dafür interessiert, kann sich den großen E-Mail-Thread ansehen. Linus Torvalds stand grundsätzlich einer Übernahme positiv gegenüber, wollte aber noch einen Test in linux-next abwarten. Dies ist zwischenzeitlich geschehen.

Nun also der Merge in den Kernel. Sollten sich die Änderungen bis zum Release halten, steht somit dem Einsatz des neuen Dateisystems ab der Veröffentlichung von Linux 6.7 nicht mehr viel im Wege. Die Aufnahme in Mainline vereinfacht aber auch die Entwicklung, da diese nun nicht mehr Out-of-Tree stattfindet, was aufgrund der hohen Änderungsgeschwindigkeit im Linux-Source-Tree schnell zu aufwändigen Anpassungsarbeiten führen kann.

Weitere Informationen zu bcachefs sind auf der eigenen Homepage abrufbar. Hier ist auch eine Schnellstartanleitung für den eigenen Einsatz zu finden.

Weitere Quellen

• Larabel: Bcachefs Merged Into The Linux 6.7 Kernel (31.10.2023)
• Larabel: Bcachefs Looks Like It Won't Make It For Linux 6.6 (08.09.2023)
• Larabel: Linus Torvalds Comments On Bcachefs Prospects For Linux 6.6 (06.09.2023)
• Thommes: Dateisystem Bcachefs für Linux 6.7 vorgesehen (31.10.2023)

Diese Nachricht ist insbesondere für alle Testing-Nutzer von Bedeutung: Arch Linux wird die Repositories umstellen, die für den Bezug der Testing-Pakete erforderlich sind.

Hintergrund ist die Migration von SVN auf Git in der Infrastruktur von Arch Linux. Dazu werden von Freitag, dem 19. Mai 2023 bis Sonntag, dem 21. Mai 2023 die Repositories eingefroren - das Arch Linux Packaging Team wird in der Zeit keine neuen Pakete bereitstellen können. Durch die Umstellung werden der SVN-Zugriff sowie der svn2git-Mirror obsolet.

Nach der Umstellung werden die Testing- und Staging-Repositories aufgespaltet und das Community-Repository aufgelöst:

• [testing] wird aufgeteilt in [core-testing] und [extra-testing]
• [staging] wird aufgeteilt in [core-staging] und [extra-staging]
• [community] wird in [extra] überführt

Nutzer von Arch Linux müssen auf die Änderungen folgendermaßen ab Montag, dem 22. Mai 2023 reagieren:

• (Optional) für alle Nutzer: in der /etc/pacman.conf kann der [community]-Abschnitt entfernt werden.
• Für Testing-Nutzer: in der /etc/pacman.conf müssen der Abschnitt für [testing] entfernt und zwei neue für [core-testing] und [extra-testing] hinzugefügt werden. Das gleiche muss, wenn eingesetzt, für das Staging-Repository unternommen werden.

Wer als Nutzer von Arch Linux keine Testing-Repositories einsetzt, muss kurzfristig auch nichts unternehmen, da das Extra-Repository nun auch alle Pakete des Community-Repositories führt. In einer Übergangsphase werden die drei nun aufgelösten Repositories (community, testing, staging) leer ausgeliefert. Mittelfristig sollten diese Repositories aber aus der /etc/pacman.conf entfernt werden, um Fehler zu vermeiden, wenn die Bereitstellung endet.

Weitere Inforamtionen zur Umstellung sind in der Mitteilung von Arch Linux vom 15. Mai 2023 zu finden.

Viele der Technologien, die wir heutzutage einsetzen, haben eine lange Geschichte hinter sich. Moderne Ansätze, sie nachzurüsten, können in bestimmten Szenarien jedoch unangenehme Auswirkungen haben. Ein kleines Beispiel möchte ich euch heute vorstellen.

Craig Younkins hat in seinem Blog auf Medium ein kurzes Szenario beschrieben, das verschlüsseltes DNS (DoH/DoT) und NTP involviert. Normalerweise gibt es bei so einem Setup wenig Probleme: der Client synchronisiert seine Zeit über NTP, kann Abweichungen ausgleichen und seine DNS-Anfragen über TLS-verschlüsselte Verbindungen abwickeln. Dabei hat der Client jederzeit seine vertrauenswürdigen Zertifikate lokal gespeichert, ebenso die Standardserver für NTP, die üblicherweise durch einen Hostname nach dem Muster *.pool.ntp.org adressiert werden.

Das Problem

Der Fallstrick: vergisst der Client die Zeit komplett, kann er in einem Deadlock landen und gegebenenfalls die Zeit nicht mehr synchronisieren. So ein Szenario kann auftreten, wenn ein System ausgeschaltet wurde und keine Real-Time-Clock in der Hardware verbaut wurde, die über eine eigene Batterieversorgung (i. d. R. Knopfzelle) verfügt. Bei einigen günstigen Routern bzw. IoT-Geräten wie dem Raspberry Pi ist das der Fall.

Findet das System keinen Anhaltspunkt über die aktuelle Zeit, so startet es, je nach Implementierung, meist beim Unix-Timestamp 1 bzw. am 01.01.1970. Dies kann jedoch in Verbindung mit TLS eine gefährliche Wirkung entfalten, da für die Zertifikatsvalidierung auf das aktuelle Datum zurückgegriffen wird – schließlich verfügen die meisten Zertifikate über einen festen Gültigkeitszeitraum, der nur wenige Monate umfasst.

Das Ergebnis: alle mit TLS abgewickelten DNS-Anfragen über die NTP-Server schlagen fehl. Dabei ist hervorzuheben, dass NTP selber unverschlüsselt weiterhin abläuft, es können lediglich die IP-Adressen der Server nicht ermittelt werden.

Lösungen

Damit soetwas nicht passiert, können Administratoren auf verschiedene Art und Weise vorbeugen. Eine erste Möglichkeit wäre, wie im Artikel beschrieben, das Hinterlegen von IP-Adressen im NTP-Client. Damit umgeht man DoH/DoT und kann direkt mit der NTP-Synchronisation fortfahren. Nachteil dieser Variante ist jedoch, dass es einerseits nur wenige NTP-Server mit wirklich statischen Adressen gibt (einer der wenigen Anbieter ist z. B. die NIST) und andererseits NTP generell eher auf Hostnames arbeitet, um z. B. einen Lastausgleich sicherzustellen.

Die zweite Variante wäre der Einsatz spezieller DHCP-Optionen wie Option 42, mit der beim Bezug der Netzwerkkonfiguration auch durch den DHCP-Server bestimmte IPv4-Adressen empfohlen werden können. In der Regel handelt es sich um lokale IPv4-Adressen, wenn lokal ein eigener NTP-Server betrieben wird, der seine Zeit mit höherrangigen Servern wiederum synchronisiert. DHCPv6 verfügt mit Option 56 über ein Äquivalent. (Q, RFC 2132 sec. 8.3., RFC 5908)

Es gibt allerdings auch spannendere Methoden: so ist der Ansatz von tlsdate, die Zeit über den TLS-Handshake von Internetdiensten wie Google oder Wikipedia zu extrahieren. Darüber hinaus wird momentan bei der IETF die Entwicklung von roughtime vorangetrieben, das hierfür ein eigenes kryptographisches Protokoll einsetzt. (Q, draft-ietf-ntp-roughtime-07, Artikel von Cloudflare)

Wer ein Dateisystem wie ext4 nutzt, findet darüber hinaus im Superblock aus dem vergangenen Mount hilfreiche Zeitangaben. Diese mount time und write time werden nämlich in der Regel bei jedem Mount und Schreibvorgang gesetzt und können als Anhaltspunkt für die Systemzeit des vergangenen Starts dienen - genug, um bei regelmäßig verwendeten Systemen immerhin die DoH-Anfrage für die initiale NTP-Namensauflösung abzuwickeln. (Q)

Fazit

Verschiedene komplexe Komponenten wie DoH/DoT und NTP können bei bestimmten Randbedingungen zu Situationen führen, die man bei der Erstkonfiguration vermutlich nicht vor Augen hatte. Wer jedoch mit dafür anfälligen Systemen ohne Real-Time-Clock arbeitet, kann auf verschiedene Strategien zur Abhilfe setzen: einerseits können Anhaltspunkte für die Zeit aus dem vergangenen Start gesucht werden oder zunehmend Protokolle genutzt werden, die genau dieses Problem adressieren.

Man pages formen auf heutigen unixoiden Systeme eine entscheidende Säule. Sie sind das integrierte Handbuch, das einerseits die Kommandos erklärt und andererseits auch eine Referenz für die jeweiligen C-Bibliotheken und Syscalls darstellt. Wer also Anwendungsentwicklung auf Linux o. ä. betreibt und dabei insbesondere auf C zurückgreift, kommt an man pages schwer vorbei. Dabei bieten sie einige Vorteile: sie sind lokal verfügbar, nach einem konsistenten Schema aufgebaut und erklären die verschiedenen Befehle und Schnittstellen. Man pages sind tatsächlich so unverzichtbar, dass jeder C-Entwickler sie regelmäßig konsultieren sollte. Immerhin werden hier nicht nur die Kommandos und ihre Wirkungsweise erklärt, sondern auch auf Seiteneffekte und Fehlermeldungen eingegangen. Dies ist essentiell, da viele Bestätigungen oder Fehler nur über Rückgabewerte kommuniziert und im letzteren Fall über spezielle (globale) Variablen wie errno erläutert werden.

In diesem Zusammenhang ist es wichtig, diese man pages aufzusuchen und durchsuchen zu können. Den ersteren Teil könnt ihr im Artikel von Ralf Hersel auf gnulinux.ch nachlesen, das konkrete durchsuchen aller man pages möchte ich heute in diesem Artikel kurz betrachten.

Wir können mit dem man-Kommando alle Beschreibungen der man pages (-k, apropos) und auch den gesamten Inhalt der man pages (-K) durchsuchen.

Beschreibungen durchsuchen

Für den heutigen Fall möchten wir uns damit beschäftigen, wie wir ein Programm beenden können. Grundsätzlich kann ein exit vielfältig aussehen: wir können ihn auf der Shell durchführen, exit könnte aber auch einen Syscall oder eine C-Funktion aus der Standardbibliothek bezeichnen. Wenn wir schon dabei sind: exits gibts natürlich auch auf der pthread-Ebene, wir können aber auch eine Funktion registrieren, die bei einem normalen exit aufgerufen werden soll. Kurzum: wir müssen uns vorher erst einmal informieren, was wir überhaupt finden können, um dann die richtige man page aufzurufen. Diese Suche geht mit folgenden Kommandos, die auf das gleiche Ergebnis kommen:

man -k exit
apropos exit

Uns wird eine Liste aller man pages zusammengestellt, die exit im Namen oder der Kurzbeschreibung enthalten. Hier haben wir die Möglichkeit, die richtige Handbuchseite aufzufinden, um dann z. B. exit(0) im C-Programm aufzurufen.

Komplette man pages durchsuchen

Manchmal kann es allerdings passieren, dass wir zu einem gegebenen Suchbegriff über apropos nicht fündig werden. Dann müssen wir den kompletten Inhalt der man pages einbeziehen, weil der gesuchte Begriff mitunter in den detaillierten Beschreibungen erst zu finden ist.

Um bei unserem Beispiel zu bleiben, möchten wir weitere Informationen über die Konstante EXIT_SUCCESS finden, die oft anstelle von 0 als exit-Code benutzt wird. Hier müssen wir alle man pages nun durchsuchen, weil es keine man page dazu gibt, die diese Konstante in der Kurzbeschreibung erwähnt.

Wir nutzen:

man -K EXIT_SUCCESS

Nun werden alle man pages durchsucht, was zu vielen Ergebnissen führen kann. Das erste Ergebnis wird automatisch geöffnet (bei mir ist es das certtool), das mag uns aber nicht zufriedenstellen.

Wir können den Pager über q verlassen und nun durch die anderen Ergebnisse uns durcharbeiten. <Enter> führt zur Anzeige der man page, <Strg + D> zum Überspringen des Suchergebnisses und <Strl + C > zum Abbruch der Suche.

Bei dieser konkreten Konstante müssen wir uns Beispiele und Hinweise anschauen, um die Verwendung zu verstehen, deswegen kann es sein, dass man sich mehrere man pages anschauen muss, die thematisch dazu passen.

Zusammenfassung

Man pages sind das klassische Offline-Handbuch von unixoiden Systemen. Wenn man nicht sofort weiß, wo man etwas suchen soll, kann man die beiden Suchfunktionen (Beschreibung, Volltext) nutzen, die das man-Kommando bereitstellt. Weitere Informationen hierzu sind unter man man (man(1)) verfügbar.

Am Samstag, dem 15.10.2022 wurden neue Versionen des Linux-Kernels veröffentlicht, darunter 6.0.2, 5.19.16 und 5.15.74. Mit diesen Versionen werden verschiedene Sicherheitslücken geschlossen, die der Sicherheitsforscher Sönke Huster aufgedeckt hat.

Konkret geht es hierbei um den WLAN-Stack. Er ist im Kernel notwendig, um drahtlose Netzwerkzugriffe zu ermöglichen. Verschiedene Treiber unterstützen die verschiedenen WLAN-Chips, welche die Kommunikation zur Außenwelt bereitstellen. Trotzdem teilen sich die Treiber eine gemeinsame Infrastruktur – und in dieser Infrastruktur wurden einige Fehler gefunden.

Den Fehlern wurden verschiedene CVEs zugewiesen. Konkret geht es um:

• CVE-2022-41674: fix u8 overflow in cfg80211_update_notlisted_nontrans
  • (max 256 byte overwrite) (RCE)
• CVE-2022-42719: wifi: mac80211: fix MBSSID parsing use-after-free
  • use after free condition (RCE)
• CVE-2022-42720: wifi: cfg80211: fix BSS refcounting bugs ref counting
  • use-after-free possibilities (RCE)
• CVE-2022-42721: wifi: cfg80211: avoid nontransmitted BSS list corruption
  • list corruption, according to Johannes will however just make it endless loop (DOS)
• CVE-2022-42722: wifi: mac80211: fix crash in beacon protection for P2P-device
  • NULL ptr dereference crash (DOS)

Besonders ins Auge fällt eine Lücke, die einen Buffer Overflow beim Scannen verschiedener WLAN-Netze zur Anzeige verfügbarer Netze ermöglicht. Die Brisanz entsteht dadurch, dass die Lücke interaktionslos (Zero Click) ausgenutzt werden kann: dadurch, dass der Scan automatisch abläuft und ein Angreifer bösartige WLAN-Frames ausstrahlen kann, die dann automatisch verarbeitet werden, ist kein aktives Klicken auf eine ausführbare Datei nötig. Glücklicherweise existiert zum aktuellen Zeitpunkt noch kein bekannter Exploit, der diese Lücke bösartig ausnutzt. Die Updates sollten trotzdem eingespielt werden, um hier nicht unnötig einem Risiko ausgesetzt zu sein.

Weitere Details und die Geschichte hinter der Lücke gibt es in der Sonderepisode 6 meines Risikozone-Podcasts. In dieser Episode führen Prof. Dr. Andreas Noack und ich ein Interview mit Sönke Huster, dem Entdecker der Lücke. Sönke erklärt in der Episode die Lücken und erläutert, wie er sie entdeckt und gemeldet hat. Insbesondere der Disclosureprozess wird Thema der Episode sein, da hier die Arbeitsweise in einem Open-Source-Projekt wie dem Linux-Kernel bei so einem Vorfall deutlich wird. Die Podcastepisode ist ab sofort auf risikozone.de/rz006 als Audio und – extra für diese Episode – auf YouTube als Video verfügbar. Sie ist aufgrund des besonderen Themas mit etwa 90 Minuten etwas länger als die üblichen 40 Minuten, aber dennoch für den Ausklang des Wochenendes sehr empfehlenswert.

Konkrete Informationen zur Lücke in der E-Mail von Sönke verfügbar, LWN.net hatte bereits am Donnerstag darüber berichtet. Mittlerweile hat auch das BSI eine Warnung aufgrund der CVEs herausgegeben.

Was sich als Projekt vor zwei Jahren langsam abzeichnete, geht nun in die finale Umsetzung: der Linux-Kernel soll zukünftig nicht nur in der Programmiersprache C, sondern auch in Rust geschrieben sein. Während die Rust-Unterstützung noch die Aufnahme in Linux 6.0 knapp verpasst hat, soll es mit Linux 6.1 nun so weit sein. ZDNET berichtet von einer geplanten Aufnahme in die kommende Linux-Version:

The implementation has begun. In an email conversation, Linux's creator Linus Torvalds, told me, "Unless something odd happens, it [Rust] will make it into 6.1." (Steven Vaughan-Nichols, ZDNET.com, 19. September 2022)

Für die Implementierung ist das Projekt "Rust for Linux" zuständig (siehe Git-Repo auf GitHub). Federführend bei der Implementierung ist Miguel Ojeda, die Entwicklung wird von Unternehmen wie Google unterstützt und gesponsert.

Während C oft als "portable Assemblersprache" wahrgenommen wird, die viel Eigenverantwortung voraussetzt, abstrahiert Rust insbesondere das Speichermanagement zu gewissen Teilen über die Ownership-, Reference- und Borrowing-Konzepte weg. Die Sicherheit und Zuverlässigkeit des Linux-Kernels soll erhöht werden, indem bestimmte Programmierfehler konzeptionell verhindert werden.

Rust soll dabei den Kernel nur ergänzen und mittelfristig nicht ersetzen. Die Anstregungen, die das Rust-for-Linux-Projekt auf sich genommen hat, umfassen eine Infrastruktur und Umgebung, um Treiber in Rust für den Kernel entwickeln zu können.

Zur üblichen Arbeit eines Systemadministrators gehört der Umgang mit persistentem Speicher (a.k.a. Festplatte), der heutzutage in Form von HDDs, SSDs oder auch NVMes daherkommt. Üblicherweise werden in Produktivsystemen die Platten in einem RAID angeordnet, um bei einem Festplattenausfall die Verfügbarkeit des Systems zu erhöhen. Soll in diesem Zusammenhang allerdings eine Festplatte vor einem drohenden Ausfall manuell aus dem RAID entfernt werden, ist es ratsam, sie vorher sicher zu löschen. In diesem Artikel möchte ich allerdings kurz umschreiben, warum der Hinweis, Backups vor jeglicher Formatierung zu erstellen, so wichtig ist - besonders bei NVMe-Speichern.

Um die gleich folgende Syntax zu verstehen, sei noch gesagt, dass unter Linux ein bestimmtes Schema existiert, wie Festplatten oder eben NVMes angesprochen werden. Bei SCSI- bzw. SATA-Platten kennt man z. B. /dev/sda für die erste erkannte SATA-Festplatte (= sd für den Treiber und a für die Platte) und /dev/sda3 für die dritte Partition (= 3) auf der ersten erkannten SATA-Festplatte. Wichtig ist, dass "erste erkannte Festplatte" genau so relativ verstanden werden muss, wie es klingt. Wird, aus welchem Grund auch immer, eine andere Festplatte zu erst erkannt und ist die Buchstabenzuweisung nicht persistiert, ändert sich über mitunter auch die Zuweisung. Nicht ohne Grunde werden Linux-Nutzer angehalten, mit UUIDs eindeutig identifizierbare Bezeichner für ihre /etc/fstab zu nutzen.

Bei NVMe ist das scheinbar ähnlich, auch wenn es hier einen Zusatz gibt. Eine Partition auf einem NVMe-Gerät, das alleine in einem Rechner steckt (d. h. nur eine NVMe ist eingebaut) könnte /dev/nvme0n1p3 heißen. Hier bedeutet die Syntax, dass es sich um die dritte Partition (p3) auf dem ersten Namespace (n1) hinter dem Controller mit der Nummer 0, handelt, das über den NVMe-Treiber angesprochen wird. NVMes verfügen mit Namespaces über eine weitere Abstraktionsschicht, sodass der NVMe-Controller seinen Storage in Namespaces unterteilen kann, die jeweils über eine eigene Partitionstabelle verfügen.

Im administrativen Umgang arbeitet man oft mit mehreren Block-Devices, einerseits der "Platte selber", klassischerweise einer /dev/sda, und den Partitionen, also /dev/sda3. Bei NVMe ist die "Platte selber" in den allermeisten Fällen ein Namespace, also /dev/nvme0n1 und NICHT /dev/nvme0.

Es gibt allerdings ein Szenario, wo man mal den Controller direkt ansprechen muss: beim Kommando nvme format. Hier gibt es eine Syntax, wo als Argument das NVMe-Device, also der Controller, angesprochen und der Namespace per Option übergeben wird. Ich durfte nun erleben, wie das sehr, sehr schiefgehen kann.

Wer nämlich glaubt, dass man von /dev/nvme1n1 auf den Controller /dev/nvme1 schließen kann, irrt sich gewaltig. Diese beiden Bezeichner haben streng genommen nichts miteinander zu tun. Und so kann es dazu führen, dass wenn

• man zwei NVMe-Devices hat
• /dev/nvme1n1 behalten und
• /dev/nvme0n1 mittels nvme format /dev/nvme0 -n 1 löschen möchte,

man sich potenziell den Boden unter den Füßen wegzieht und die eigentlich zu behaltende NVMe löscht - was nach der Formatierung mit der netten Fehlermeldung bash: <executable>: cannot execute binary file: Exec format error quitiiert wird, wenn man das nächste Kommando in der Bash aufrufen will.

Der Zusammenhang wird zwischen /dev/nvmeX und /dev/nvmeYn1 nämlich - NVMe Multpathing sei dank - dynamisch gewählt. Und ich bin nicht der einzige, dem das aufgefallen ist. Normalerweise hängen die Bezeichner zusammen, aber wenn man beim Tausch der NVMes zwischendurch Reboots durchführen muss, kann sich die Reihenfolge schon mal verdrehen - aber eben nur halb.

Und so muss man manuell nachprüfen, welches Device wirklich hinter dem Block-Device eines Namespaces steckt:

me@server:~$ ls -l /sys/block/nvme1n1/device
lrwxrwxrwx 1 root root 0 Aug 31 19:43 /sys/block/nvme1n1/device -> ../../nvme0

In diesem Fall steckt hinter /dev/nvme1n1 das Device /dev/nvme0. Muss man beachten.

Dies hat übrigens nicht nur auf das Formatieren Auswirkungen: auch die SMART-Überwachung zeigt für /dev/nvme0n1 und /dev/nvme0 völlig unterschiedliche Resultate an. An dieser Stelle ist mir übrigens erst aufgefallen, dass der Zusammenhang zwischen den Devices mitunter nicht-systematisch gewählt werden könnte.

Was lernen wir daraus? Neue Treiber, wie in unserem Fall nvme, bringen neue Herausforderungen mit. Es ist gut, sich jedes Mal, wenn man seine Produktivsysteme mit neuen Fähigkeiten ausstattet, mit der Dokumentation und dem Standard hinter dem Treiber zu beschäftigen. Darüber hinaus - und das ist noch viel wichtiger - sollte man jederzeit auf seine Backups als zusätzliches Sicherheitsnetz achten, weil es immer etwas geben wird, was man übersieht. In meinem Fall hatte ich Glück, weil der betroffene Server aus der Testumgebung stammte und das Formatieren der falschen Platte nur vernachlässigbare Auswirkungen hätte - ich bin aber froh, auf diesem Umstand aufmerksam geworden zu sein und wollte euch an dieser Stelle einfach "vorwarnen".

Im heutigen Artikel möchte ich euch kurz ein Werkzeug vorstellen, das immer dann sinnvoll ist, wenn mehrere Dateien auf einmal nach einem bestimmten Muster umbenannt werden sollen. Das Werkzeug heißt rename (man prename) und kann unter Debian/Ubuntu als solches aus den Repositories bezogen werden. Bei anderen Distributionen muss man darauf achten, dass man die Perl-Variante nimmt (teils auch als prename bekannt) und nicht auf die util-linux-Variante zurückgreift, die zwar simple Ersetzungen beherrscht, aber kein Regex/Perl-Expression beherrscht und nur den ersten Treffer im Dateinamen ersetzt.

Das Kommando ist relativ einfach aufgebaut:

rename OPTIONS perlexpr [ files ]

Die wichtigste Option, das möchte ich vorab schon sagen, ist -n, da hiermit ein "Trockenlauf" durchgeführt und somit überprüft werden kann, ob das Muster auch passt. Darüber hinaus halte ich -v für die zweitwichtigste Option, da man im "scharfen" Lauf dann überwachen kann, was konkret umbenannt wurde. Das Muster selber wird als Perl-Expression übergeben, die in vielen Fallen an die Syntax vom Kommandozeilenwerkzeug sed für die Ersetzung von Text erinnert.

Das Kommando kann dann zum Beispiel so eingesetzt werden:

rename 's/TEst/Test/g' *.txt

Hier sollen alle Stellen mit "TEst" in den Dateinamen, die auf .txt enden, durch "Test" ersetzt werden. Mit einem klassischen mv ließe sich das nicht ohne weiteres umsetzen, da dieses Werkzeug nicht kontextbezogen ersetzen/umbenennen kann.

Natürlich können auch komplexere (Regex)-Muster umgesetzt werden: soll z. B. die Dateiendung aller Dateien, die auf ".htm" enden, in ".html" umbenannt werden, geht das mit folgendem Kommando:

rename 's/\.htm$/\.html/' .htm

Weitere Beispiele und Bedienungshinweise können aus dem Ubuntuusers-Wiki bezogen werden. Meiner Erfahrung nach spart das Werkzeug besonders viel Zeit bei Umbennungsaufgaben und ersetzt somit ggfs. eigene Skripte mit find-mv-Konstruktionen.

Kurz notiert: Arch Linux, die Linux-Distribution, die besonders durch ihr KISS-Prinzip bekannt geworden ist, feiert heute ihren 20. Geburtstag. Sie erblickte die Welt am 11. März 2002 mit dem Release der Version 0.1. Klassische (Major-)Releases gibt es bei Arch Linux nicht, da das Rolling-Release-Modell genutzt wird. Die "Versionen" fungieren dabei eher als Einstiegspunkt. Als Paketverwaltung kommt das eigene System pacman zum Einsatz. Bei Arch Linux stehen die Prinzipen der Einfachheit, Modernität, Benutzerorientierung, Vielseitigkeit und des Pragmatismus im Mittelpunkt. (siehe Wiki)

Wer mehr zur Geschichte von Arch Linux lernen will, kann einen Blick in das Arch Wiki sowie die heutigen Artikel auf Heise und LinuxNews werfen.

Ich selber habe Arch vor knapp 10 Jahren das erste Mal ausprobiert, damals noch mit initscripts und knapp vor der systemd-Umstellung – und bin bis heute der Distribution treu geblieben. Es wirkt, als würde die Zeit zu rasen beginnen, wenn man bedenkt, dass bei vielen, einschließlich mir, der Arch-Einstieg zeitlich näher am ersten Release zurückliegt, als am heutigen Tage.

In diesem Sinne: Happy Birthday, Arch Linux!

Kurz angemerkt: beim Update eines GitLab-Servers per APT trat folgende Fehlermeldung auf:

The following signatures were invalid: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) <packages@gitlab.com>

Der Hintergrund ist recht einfach und wird auch auf der entsprechenden Hilfeseite erklärt:

This key’s expiration was extended from 2022-03-02 to 2024-03-01. If you encounter a complaint of expiration on 2022-03-02, perform the steps in Update keys after expiry extension to incorporate the updated public key content.

So lief tatsächlich der Repository Key in der Mitte der Woche regulär aus und muss nun erneuert bzw. aktualisiert werden, da seine Laufzeit erweitert wurde. Die Anleitung, wie man den Key aktualisieren kann, wird auf besagter Hilfeseite ebenfalls zur Verfügung gestellt. Danach verläuft das Upgrade wieder wie gehabt.

[GitLab.com Issue]

Im Februar 2020 wurde schon angekündigt, dass OpenSSH die Unterstützung von ssh-rsa auslaufen lässt. Umgesetzt wurde dies in Version 8.8, die vor gut einem Monat veröffentlicht wurde.

Leider unterstützt nicht jedes System moderne HostKeyAlgorithms. Ein solches Beispiel konnte ich die Tage z. B. bei einem Switch beobachten konnte. Hier erscheint folgender Fehler:

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

In so einem Fall kann man ausnahmsweise doch noch ssh-rsa erlauben und das geht entweder per Option im ssh-Aufruf:

ssh -o HostKeyAlgorithms=+ssh-rsa 192.168.1.1

oder man trägt es in die ~/.ssh/config dauerhaft ein:

Host XYZ
    HostName 192.168.1.1
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Kurz notiert: es gibt Situationen, in denen man Pfade auflösen, also relative Pfade in absolute umwandeln möchte. Für Anwender, die dabei Konstruktionen mit pwd und kompliziertes Parsing umgehen wollen, bietet sich realpath aus den GNU Coreutils an.

Die Bedienung ist denkbar einfach: realpath nimmt beliebig viele Pfade als Argumente auf und gibt die absoluten Pfade zeilenweise aus. Dabei werden standardmäßig auch Symlinks aufgelöst, sodass der „wahre“ Pfad, im Programmkontext auch physischer Pfad genannt, angezeigt wird.

Mit einigen Zusatzoptionen, die sich in der Manpage realpath(1) finden lassen, kann weiterhin das Verhalten angepasst werden. Hier sei zum Beispiel -e erwähnt, das einen strikteren Modus aktiviert und überprüft, ob das letzte Element im Pfad überhaupt existiert – stanardmäßig ist dies nicht der Fall. Mit -s kann die bereits beschriebene Auflösung von Symlinks deaktiviert werden.

Alles in allem, ein hilfreiches Werkzeug, besonders für Shellscripte. Der Quelltext von realpath ist auch überschaubar und beispielsweise auf GitHub zu finden.