© Chris Up / Photocase.com

Linux-Programme nutzen zahlreiche von Bibliotheken bereitgestellte Features. Mit ein wenig C-Code ersetzen Sie über die Variable LD_PRELOAD Bibliotheksfunktionen durch eigene und ändern so das Programmverhalten.

Möchten Sie herausfinden, welche Dateien ein Programm öffnet oder löscht und welche Netzwerkverbindungen es aufbaut? Mit einem Trick lassen sich Standardfunktionen wie das Öffnen von Dateien oder das Lauschen auf einem TCP-Port durch selbst programmierte Versionen ersetzen, die nicht nur protokollieren, was die Anwendung tut, sondern auf Wunsch sogar das Verhalten verändern. Den Schlüssel zu diesen Möglichkeiten bietet die Variable »LD_PRELOAD«, die den Linux-Programmlader beeinflusst.

Wenn Sie ein Programm starten, erzeugt der Linux-Kernel einen neuen Prozess und lädt die ausführbare Programmdatei in dessen Speicherbereich. Das ist aber meist nicht alles: Programme nutzen in der Regel Bibliotheken, die dynamisch hinzugeladen werden. Welche davon eine Applikation lädt, erfahren Sie über das Kommando »ldd« (Abbildung 1).

Abbildung 1: Der Kommandozeilenaufruf »ls« nutzt nur wenige Bibliotheken; bei grafischen Anwendungen fällt die Liste deutlich länger aus.

“Echte” Bibliotheken sind in Abbildung 1 nur die Einträge »libselinux.so.1« (Unterstützung für die Sicherheitserweiterung SELinux), »libc.so.6« (die Standard-C-Bibliothek) und »libpcre2-8.so.0« (Funktionen, mit denen ein Programm reguläre Ausdrücke verarbeiten kann).

Der oberste Eintrag »linux-vdso.so.1« gehört zum Kernel. Der untere (»ld-linux-x86.64.so.2«) ist der Programmlader selbst, der die benötigten Dateien lädt. Die wichtigsten Standardfunktionen, etwa für den Dateizugriff, Prozess- und Thread-Steuerung und auch alle Low-Level-System-Call-Wrapper finden sich in »libc.so.6«. Programme, die die grafische Oberfläche (also meist das X-Window-System X11) nutzen, laden zudem die X11-Bibliothek »libX11.so.6«.

Eine der Dateien in der Bibliotheksliste ist »libc.so.6«, eine GNU-C-Bibliothek [1]. Sie bringt zahlreiche häufig benötigte Funktionen mit, darunter »open()«, »read()«, »write()« für den Low-Level-Zugriff auf Dateien, »malloc()« für die dynamische Speicherverwaltung, »printf()« für die formatierte Ausgabe von Daten und »exit()« zum Beenden des Programms. Starten Sie ein grafisches Programm, kommen noch zahlreiche weitere Bibliotheken hinzu. So listet der Aufruf von »ldd /usr/bin/gedit« auf Ubuntu 22.04 beispielsweise 80 Bibliotheken auf, die der Gnome-Editor benötigt.

Eine komplette Liste aller sogenannten Symbole, die eine Bibliothek bereitstellt, rufen Sie mit »readelf« ab. So zeigt der Aufruf aus Listing 1 zum Beispiel die mit über 3000 Einträgen sehr lange Liste der Symbole der Standard-C-Bibliothek an. Nicht alle Einträge stehen für Funktionen: Zu den Symbolen gehören auch globale Variablen und Konstanten.

$ readelf -Ws /lib/x86_64-linux-gnu/libc.so.6

Statisch gelinkt

Bei manchen Programmdateien listet Ldd keine Bibliotheken auf, sondern gibt die Fehlermeldung Das Programm ist nicht dynamisch gelinkt aus. Solche Programme startet Linux ohne das Laden zusätzlicher Dateien. Wenn Sie ein C-Programm mit Gcc übersetzen, erzeugen Sie über die Option »-static« eine solche statisch gelinkte Binärdatei. Abbildung 2 zeigt einige Experimente mit einem kleinen C-Programm.

Abbildung 2: Da sie alle notwendigen Bibliotheken selbst mitbringen, fallen statisch gelinkte Binaries deutlich größer aus als dynamisch gelinkte.

Oben sehen Sie den Quellcode. Das Programm gibt »Hello world« und – falls vorhanden – das erste Aufruf-Argument aus. Um die Funktion »printf()« aus der Standardbibliothek zu nutzen, bindet der Code die Header-Datei »stdio.h« ein.

Die beiden Gcc-Aufrufe erzeugen eine dynamisch (»test-printf-dynamic«) und eine statisch (»test-print-static«) gelinkte Version des ausführbaren Programms. Beachten Sie den Größenunterschied: Das dynamisch gelinkte Binary belegt etwa 16 KByte, während die statische Version etwa 900 KByte groß ist, weil sie auch die Bibliotheksfunktionen enthält.

Die beiden Aufrufe von Strace prüfen, welche Dateien während des Starts und der Ausführung des Programms geöffnet werden. Die Datei »/etc/ld.so.cache« enthält eine Liste aller Bibliotheken, die bei Programmstarts automatisch geladen werden können, »libc.so.6« ist die bereits bekannte Standard-C-Bibliothek. Nur die dynamische Version des Programms öffnet die beiden Dateien. Die statische dagegen enthält schon alles an Code, was sie braucht.

Unten im Bild folgen noch Testaufrufe der beiden Programme; sie arbeiten identisch.

Eingriff

Der Programmstart lässt sich unter Linux feintunen. Insbesondere können Sie festlegen, wo der Programmlader »ld-linux-x86-64.so.2« nach Bibliotheken sucht. Das klappt entweder über eine feste Systemeinstellung in der Konfigurationsdatei »/etc/ld.so.conf« und weitere Dateien im Ordner »/etc/ld.so.conf.d/« (in diesen Dateien stehen Verzeichnisse, die Bibliotheken enthalten) oder über die Umgebungsvariable »LD_LIBRARY_PATH«: In ihr geben Sie zusätzliche Ordner mit Bibliotheken an, in denen der Loader dann mit Priorität sucht.

Diese Flexibilität ermöglicht unter anderem, dass Sie verschiedene Versionen der gleichen Bibliothek installieren und dann für einzelne Anwendungen einstellen können, welche davon sie verwenden. Am grundsätzlichen Ablauf ändert sich durch diese Anpassungen nichts: Der Loader prüft, welche Bibliotheken ein Programm benötigt, sucht diese in den vorgesehenen Ordnern und lädt sie.

Ein besonderes Ladeverhalten erzielen Sie mit der Variablen »LD_PRELOAD«: Hier tragen Sie einzelne Bibliotheken ein, die der Loader zusätzlich laden soll. Sie können auch Funktionen enthalten, die bereits in einer der regulären Bibliotheken vorkommen. Über diesen Mechanismus lässt sich beispielsweise eine einzelne Bibliotheksfunktion durch eine selbst entwickelte Variante ersetzen.

Logger

Als erstes, einfaches Beispiel für den Einsatz von »LD_PRELOAD« erstellen Sie eigene Varianten der System-Call-Wrapper »open()« und »close()«. Listing 2 zeigt den kompletten Code der Datei »openclose.c«, die Sie mit dem Kommando aus Listing 3 in eine Bibliotheksdatei »openclose.so« übersetzen. Beide Funktionen geben mit »printf()« eine Debug-Meldung auf der Konsole aus und erledigen ansonsten ihre Aufgaben, indem sie die regulären Versionen von »open()« und »close()« aufrufen. Das gelingt über einen Trick.

#define _GNU_SOURCE
#include <dlfcn.h>
#include <unistd.h>
#include <stdio.h>
#include <stdarg.h>
int (*true_close)(int fd);
int (*true_open)(const char *pathname, int flags, va_list mode);
int open (const char *pathname, int flags, va_list mode) {
  true_open = dlsym (RTLD_NEXT, "open");
  int fd = true_open (pathname, flags, mode);
  printf ("DEBUG: open(\"%s\") = %d\n", pathname, fd);
  return fd;
}
int close(int fd) {
  true_close = dlsym (RTLD_NEXT, "close");
  printf ("DEBUG: Closing fd = %d\n", fd);
  return true_close(fd);
}

$ gcc openclose.c -o openclose.so -fPIC -shared -ldl

Die Funktion »dlsym()« findet Funktionen aus Bibliotheken über deren Namen. Darum lautet der zweite Aufrufparameter in Zeile 11 und Zeile 18 »”open”« respektive »”close”«. Das würde eigentlich Zeiger auf die hier implementierten Versionen zurückliefern, also nicht weiterhelfen. Über den Parameter »RTLD_NEXT« lässt sich aber jeweils der erste Treffer überspringen. Die fortgesetzte Suche nach den Funktionsnamen findet dann die Implementierungen in der Standardbibliothek.

Um die Funktionen dann auch aufrufen zu können, definiert der Code in den Zeilen 7 und 8 zwei Variablen, die vom richtigen Funktionstyp sein müssen. Nach den Zuweisungen in Zeile 11 und 18 ist es dann möglich, »true_open()« und »true_close()« aufzurufen.

Ein beliebiges Programm lassen Sie nun mit diesen veränderten Dateizugriffsfunktionen laufen, indem Sie dem Programmaufruf die Variablenzuweisung »LD_PRELOAD=Pfad/zur/Bibliothek« voranstellen, wobei Sie den Pfad absolut angeben müssen (Listing 4).

$ cat test.txt
Hello
$ LD_PRELOAD=$PWD/openclose.so \
cat test.txt
DEBUG: open("test.txt") = 3
Hello
DEBUG: Closing fd = 3

Verhalten anpassen

Typisch für den Einsatz von »LD_PRELOAD« ist das folgende Szenario: Sie beobachten in einer Ihrer Anwendungen ein unerwünschtes Verhalten, das Sie ändern möchten. Der Quellcode ist aber zu komplex, um dort nach der richtigen Stelle zu suchen, oder er ist nicht verfügbar. Ersatzweise überprüfen Sie mit Strace oder Ltrace (siehe Kasten “Strace und Ltrace”), in welcher Reihenfolge das Programm zum Beispiel versucht, Dateien zu öffnen oder Netzwerkverbindungen aufzubauen.

So stellt sich vielleicht heraus, dass ein Programm in einer globalen Konfigurationsdatei Informationen findet, mit denen es nicht zurechtkommt. Sie möchten aber die globale Datei nicht verändern, weil andere Anwendungen auch darauf zugreifen und diese Informationen benötigen.

$ strace -o prog.log -e trace=open,openat,close prog
$ ltrace -x open+openat+close prog

Hier hilft es, exklusiv für das problematische Programm den Zugriff auf eine andere Datei umzubiegen, die Sie mit passendem Inhalt füllen, sodass das Programm korrekt arbeitet. Dazu passen Sie die Funktion »open()« so an, dass sie jeden Versuch, eine bestimmte Datei zu öffnen, einfach mit dem Öffnen der Alternativdatei quittiert. Listing 6 zeigt, wie Sie alle Versuche, die Datei »/etc/fstab« zu öffnen, auf »/tmp/fstab.test« umbiegen.

#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <string.h>
#define SEARCH_PATH "/etc/fstab"
#define REPLACE_PATH "/tmp/fstab.test"
int (*true_open)(const char *pathname, int flags, va_list mode);
int open (const char *pathname, int flags, va_list mode) {
  true_open = dlsym (RTLD_NEXT, "open");
  char *longpath = realpath (pathname, NULL);
  if (!strncmp (longpath, SEARCH_PATH, PATH_MAX))
    pathname = REPLACE_PATH;
  int fd = true_open (pathname, flags, mode);
  free (longpath);
  return fd;
}

Die neue Fassung von »open()« erzeugt zum angegebenen Dateinamen zunächst mit »realpath()« eine absolute Pfadangabe. »open()« lässt sich auch mit relativen Pfaden aufrufen, die je nach Arbeitsverzeichnis dann sehr unterschiedlich aussehen können. Das Umwandeln stellt sicher, dass nur ein einziger Pfad zu prüfen ist. Die Funktion »strncmp()« vergleicht den Pfad dann mit einem Suchbegriff (in unserem Beispiel: »/etc/fstab«) und ersetzt ihn bei einem Treffer durch den Namen der alternativen Datei (»/tmp/fstab.test«).

Danach geht es wie gewohnt weiter, »true_open()« öffnet die Datei. Der Aufruf von »free()« am Ende ist notwendig, weil »longpath()« Speicher fürs Ablegen der Pfadangabe reserviert hat. Den sollte man wieder freigeben, bevor man die Funktion verlässt. Auch hier übernimmt das Kompilieren wieder ein Einzeiler (Listing 7, erste Zeile).

$ gcc openother.c -o openother.so -fPIC -shared -ldl
$ echo "Das ist nicht /etc/fstab" > /tmp/fstab.test
$ LD_PRELOAD=$PWD/openother.so cat /etc/fstab
Das ist nicht /etc/fstab

Wenn Sie jetzt mit dem Aufruf aus der zweiten Zeile eine Datei erzeugen und mit Cat und der über »LD_PRELOAD« aktivierten Bibliothek auf »/etc/fstab« zugreifen, öffnen Sie stattdessen die in »/tmp« erstellte Datei (letzte Zeile).

Zugriffsverbot

Statt den Dateizugriff umzubiegen, kann die Problemlösung auch darin liegen, den Zugriff komplett zu verbieten. Dazu brechen Sie in bestimmten Fällen ohne Aufruf der Originalfunktion ab, setzen die globale Fehlervariable »errno« und geben den Exit-Code »-1« zurück.

Listing 8 zeigt den Code, über den »open()« beim Zugriff auf die Datei »/etc/fstab« mit dem Fehlercode »ENOENT« und dem Exit-Code »-1« abbricht. Der Versuch, die Datei zu öffnen, führt dann gewünscht zum Programmabbruch (Listing 9).

#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#define SEARCH_PATH "/etc/fstab"
int (*true_open)(const char *pathname, int flags, va_list mode);
int open (const char *pathname, int flags, va_list mode) {
  true_open = dlsym (RTLD_NEXT, "open");
  char *longpath = realpath (pathname, NULL);
  int check = strncmp (longpath, SEARCH_PATH, PATH_MAX);
  free (longpath);
  if (!check) {
    errno = ENOENT;  // Datei nicht gefunden
    return -1;
  }
  return true_open (pathname, flags, mode);
}

$ LD_PRELOAD=$PWD/dontopen.so cat /etc/fstab
cat: /etc/fstab: Datei oder Verzeichnis nicht gefunden

»ENOENT« steht für “Datei oder Verzeichnis nicht gefunden”. Die Definitionen für Fehlercodes finden Sie in »errno-base.h« und »errno.h« im Ordner »/usr/include/asm-generic/«, sodass Sie auch andere Codes auswählen können.

Wenn Sie die Zugriffssperre mit anderen Programmen testen, fällt Ihnen vielleicht auf, dass einige Editoren wie Vim, Mcedit oder Nano ebenfalls am Zugriff gehindert werden, Gedit aber die Datei öffnen kann. Eine Analyse mit Strace zeigt, dass dieser Editor Dateien nicht mit »open()« öffnet, sondern mit »openat«. Dafür gilt es, eine alternative Implementierung bereitzustellen.

Mehr Beispiele

Einige weitere mögliche Anwendungen finden Sie auf der Github-Seite Awesome LD_PRELOAD [2]. Mit Faketime gaukeln Sie Prozessen beispielsweise eine abweichende Systemzeit und damit insbesondere ein anderes Datum vor. Das erweist sich etwa als nützlich, wenn Sie ein Programm starten möchten, dessen Nutzungslizenz abgelaufen ist. Die Änderung gilt dabei nur für Prozesse, die von Faketime gestartet werden. Das Tool lädt über »LD_PRELOAD« eine Bibliothek, die verschiedene Funktionen austauscht, darunter »time()«, »ftime()« und »gettimeofday()« (Abbildung 3).

Abbildung 3: Dank Faketime ist es auf der rechten Uhr schon 2,5 Stunden später als auf der linken.

Die Bibliothek Stderred (der Name setzt sich aus der Bezeichnung stderr für die Standardfehlerausgabe und der Farbe “red” zusammen) färbt im Terminal alle Ausgaben, die ein Prozess über die Standardfehlerausgabe erzeugt, rot ein, sodass sich Fehlermeldungen leicht von anderen Ausgaben unterscheiden lassen.

Fsatrace beobachtet Dateizugriffe und erkennt dabei neben Lese- und Schreibzugriffen auch Verschieben, Löschen und Statusabfragen. Dasselbe Verhalten lässt sich aber alternativ auch mit Strace problemlos erreichen.

Fazit

Der Kreativität sind beim Einsatz von »LD_PRELOAD« keine Grenzen gesetzt: Finden Sie häufig genutzte Bibliotheksfunktionen heraus, schreiben Sie einen Wrapper dafür und bauen Sie dort kleine Veränderungen ein. Wenn Sie die Variable in einer Shell definieren und exportieren, gilt sie in allen Prozessen, die Sie von dort starten, ohne dass Sie jedem Befehl die Definition voranstellen müssen. (tle/jlu)