Zusammenfassung

  • Im Modell mit privilegiertem Master öffnen die meisten Postfix-Dienste zuerst benötigte Dateien und geben Root vor der Bearbeitung von Anfragen auf; vier Zustelldienste behalten für klar begrenzte Aufgaben eine gespeicherte Root-Identität.
  • Ein unprivilegierter Master senkt die Rechte des Supervisors, schwächt aber die interne Trennung, erweitert bei einer Dienstkompromittierung den Zugriff auf Schlüssel und Protokolle und ist nur für wenige Produktionskonfigurationen vorgesehen.

Die Frage, ob ein Mailserver „als Root läuft“, sagt wenig darüber aus, wo das Risiko liegt. Postfix legt präzisere Fragen nahe: Welcher Prozess benötigt welches Recht, in welcher Phase einer Anfrage und für welche Dateien oder Ressourcen anderer Nutzer?

Eine Nachricht, die per SMTP oder QMQP eintrifft, erreicht zunächst einen netzwerkseitigen Postfix-Dienst. Dieser prüft die Eingabe und übergibt Envelope und Inhalt an cleanup(8). Cleanup übernimmt die letzte Verarbeitung vor dem Einreihen, schreibt die Nachricht in die Eingangswarteschlange und benachrichtigt qmgr(8). Der Queue-Manager wählt anschließend die Zustellagenten. Seine aktive Warteschlange ist begrenzt; ein großer Rückstau zwingt den Prozess deshalb nicht, alle wartenden Nachrichten gleichzeitig zu öffnen. Der residente Prozess master(8) überwacht die Dienste, startet sie bei Bedarf und setzt die konfigurierten Prozessgrenzen durch.

Supervisor und anfragebearbeitende Dienste haben unterschiedliche Aufgaben. Im Postfix-Modell mit privilegiertem Master kann ein Dienst mit Root-Rechten starten, sensible Dateien wie private TLS-Schlüssel oder Datenbankpasswörter öffnen und Root anschließend unwiderruflich ablegen, bevor er Anfragen bearbeitet. Laut aktueller Sicherheitsdokumentation kann ein Dienst, der nach diesem Schritt kompromittiert wird, die betreffenden Dateien, Datenbanken oder Protokolle nicht mehr öffnen. Root gehört damit zur Initialisierung und Rechtevergabe, aber nicht zwangsläufig dauerhaft zu jedem netzwerkseitigen Prozess.

Es gibt Ausnahmen. Die meisten Dienste geben Root endgültig auf, doch local(8), pipe(8), spawn(8) und virtual(8) behalten eine gespeicherte effektive Root-Identität. Sie benötigen sie, um als Zielnutzer aufzutreten oder auf Ressourcen außerhalb von Postfix zuzugreifen, etwa ein Postfach oder ein externes Programm. Postfix unterscheidet dabei zwei Aufgaben: Root kann Rechte zwischen Postfix-Diensten trennen und Postfix begrenzen, wenn ein Dienst Nutzerdateien oder fremde Programme erreicht. Der pauschale Ausdruck „Root-Prozess“ verdeckt diese unterschiedlichen Grenzen.

In einem LISA-Vortrag von 2010 beschrieb Wietse Venema Postfix als aufgeteilte Least-Privilege-Architektur. Als einen Einfluss nannte er einen Firewall-Entwurf, der Mailannahme und Zustellung durch Prozesse mit niedrigen Rechten in einer chroot-Umgebung trennte. Er erläuterte auch, dass kleinere Programme die Wartung erleichtern können, sobald die Kommunikationsinfrastruktur steht. Das ist eine historische Selbstdarstellung des Entwurfs, keine aktuelle Zahl von Postfix-Diensten und keine Messung von Sicherheitsergebnissen.

Die heutige Projektdokumentation beschreibt die getrennten Aufgaben für Annahme, Aufbereitung, Warteschlangenverwaltung und Zustellung.

Die jüngste Änderung behauptet nicht, dass ein Master ohne Root automatisch das gesamte System sicherer macht. Laut Postfix-Dokumentation implementierte Venema den unprivilegierten Betrieb von master(8) 2025 zunächst für unveröffentlichte Integrationstests. Nach einer Kundenanfrage im Jahr 2026 machte er ihn für einen begrenzten Produktionseinsatz tauglich und ergänzte die Dokumentation. In diesem Modus läuft der Master unter der festen Identität postfix statt als Root. Die Dienste besitzen bei der Initialisierung und bei der Bearbeitung von Anfragen dieselben Postfix-Rechte. Laut Projekt lassen sich dadurch weder die interne Privilegientrennung noch die übliche Begrenzung beim Zugriff auf fremde Dateien, Postfächer oder externe Befehle beibehalten.

Der Unterschied zeigt sich unmittelbar in den Dateirechten. Geheime Postfix-Schlüsseldateien müssen für den Nutzer postfix lesbar sein; ein kompromittierter Dienst kann sie daher auslesen. Optionale Postfix-Protokolldateien müssen postfix gehören, sodass ein kompromittierter Dienst sie lesen, ändern oder löschen kann. Konfigurationsdateien dürfen dagegen nicht diesem Nutzer gehören. Bei Installationen mit mehreren Instanzen müssen alle entweder den privilegierten oder alle den unprivilegierten Master verwenden; eine Mischung ist nicht möglich.

Der erlaubte Produktionseinsatz ist eng begrenzt. Postfix gestattet den unprivilegierten Master für Installationen, die alle Nachrichten per SMTP oder LMTP weiterleiten. Für Produktionssysteme verbietet die Dokumentation Konfigurationen, in denen lokale Dienste fremde Programme ausführen oder Nachrichten in Postfächerdateien ablegen. Als Risiko nennt sie einen Befehl in der .forward-Datei eines Nutzers: Er würde mit postfix-Rechten statt mit den Rechten des Zielnutzers laufen und könnte diesem Kontrolle über das Mailsystem geben. Die Warnung betrifft bestimmte Konfigurationen, ist aber eindeutig.

Die architektonische Lehre lautet weder „Root ist sicher“ noch „Root ist gefährlich“. Eine Rechteänderung verschiebt Risiken zwischen Grenzen. Ein unprivilegierter Master kann zu einem eingeschränkten Relay passen; seine Dienste teilen dann jedoch den Zugriff auf Schlüssel und Protokolle, die das privilegierte Modell nach der Initialisierung abschirmen kann. Betreiber sollten zuerst ihre Zustellpfade erfassen, bevor sie die Identität des Masters ändern, und anschließend prüfen, ob das gewählte Modell zu den Dateien und Befehlen passt, die jeder Dienst erreichen kann.

Die öffentliche Dokumentation legt die Abwägung offen, belegt aber weder die Verbreitung der beiden Modi noch ihre Sicherheitsergebnisse im laufenden Betrieb.

Quellen