Ausführung mit geringsten Berechtigungen und sudo-Disziplin

Die meisten Sicherheitsverletzungen in der Automatisierung geschehen nicht aufgrund exotischer Exploits, sondern weil Skripte mit mehr Berechtigungen als nötig ausgeführt werden. Ein als root laufender Cronjob, der lediglich eine Protokolldatei rotieren muss, ist ein Sicherheitsvorfall, der nur darauf wartet, zu passieren.

Das Prinzip der geringsten Rechte besagt: Jeder Prozess sollte nur die Berechtigungen verwenden, die er für seine Aufgabe benötigt — und keine weiteren. Beim Schreiben von Bash-Skripten bedeutet das:

• Nach Möglichkeit als Benutzer ohne erhöhte Rechte ausführen
• Nur für die Befehle, die dies erfordern, zu root wechseln
• Berechtigungen sofort wieder abgeben, sobald die privilegierte Arbeit abgeschlossen ist
• Anmeldedaten niemals über ihren Gültigkeitsbereich hinaus speichern oder erben

Diese Lektion behandelt die konkreten Techniken: die Einschränkung von sudo, das Abgeben von Rechten mit su, Prüfungen der UID und die Absicherung von sudoers — für ein diszipliniertes Berechtigungsmodell in Produktionsskripten.

Vor jedem Codeblock, der tatsächlich root erfordert, sollte Ihr Skript überprüfen, ob es mit der erwarteten effektiven UID ausgeführt wird. Gehen Sie niemals von etwas aus, sondern prüfen Sie es immer ausdrücklich.

$EUID ist eine spezielle Bash-Variable, die die effektive Benutzer-ID des aktuellen Prozesses enthält. Für root ist die EUID immer 0. Eine Prüfung am Anfang des Skripts — oder rund um einen privilegierten Block — verhindert eine versehentliche Ausführung unter der falschen Identität.

Verwenden Sie dieses Schutzmuster:

Manche Skripte benötigen tatsächlich root. In diesem Fall wird die Prüfung umgekehrt: Schlagen Sie frühzeitig fehl, wenn root nicht verfügbar ist, anstatt das Skript einen privilegierten Systemaufruf erreichen zu lassen und mitten in der Ausführung einen unverständlichen Berechtigungsfehler zu erzeugen.

Die Kombination aus frühem Beenden und einer hilfreichen Nutzungsmeldung macht Skripte selbstdokumentierend:

Der häufigste Fehler besteht darin, sudo an den Anfang eines Skripts zu setzen und anschließend alles als root auszuführen. Wenden Sie sudo stattdessen nur auf den konkreten Befehl an, der es benötigt — alles andere läuft als Ihr normaler Benutzer.

Dadurch wird der mögliche Schaden begrenzt: Wenn ein Angreifer Code in Ihr Skript einschleust, kann er nur die Teile mit Root-Berechtigungen ausführen, denen sudo vorangestellt ist.

Vergleichen Sie die beiden folgenden Muster. Das zweite ist deutlich sicherer:

Der Aufruf sudo somecommand in einem Skript ist nur dann sicher, wenn die Datei sudoers genau diesen Befehl — und nichts weiter — zulässt. Vermeiden Sie Regeln wie ALL=(ALL) NOPASSWD: ALL für Dienstkonten.

Beschränken Sie Regeln stattdessen mithilfe der sicheren visudo-Syntax auf bestimmte Befehle mit bestimmten Argumenten. Wichtige Felder einer sudoers-Regel:

• Benutzer — wer sudo aufrufen darf
• Host — auf welchem Rechner (verwenden Sie ALL für Portabilität)
• RunAs — welche Identität angenommen wird (fast immer root)
• Befehl — vollständiger absoluter Pfad, optional mit literalen Argumenten

Beispiel für präzise Regeln für ein Deployment-Dienstkonto (deployer):

Wenn ein Skript als root startet (z. B. durch ein System-Init-System oder einen als root laufenden Cronjob), die meiste Arbeit aber als Benutzer ohne erhöhte Rechte erfolgen soll, sollten Sie die Berechtigungen ausdrücklich abgeben, statt das gesamte Skript als root auszuführen.

Dafür stehen zwei Werkzeuge zur Verfügung:

• su -s /bin/bash -c 'command' username — startet eine Shell als username und führt den Befehl aus
• runuser -u username -- command args — unter Linux für den Wechsel innerhalb von Skripten im Besitz von root bevorzugt; sauberer als su

Das folgende Muster zeigt einen root-eigenen Deployment-Wrapper, der für die eigentliche Anwendungslogik zum Benutzer app wechselt:

Sie müssen nicht immer zu einer vollständigen Shell-Sitzung wechseln. sudo -u username command führt einen einzelnen Befehl als angegebenen Benutzer aus und kehrt anschließend zur aufrufenden Identität zurück. Das ist nützlich, wenn Sie auf Dateien zugreifen müssen, die einem Dienstkonto gehören, ohne diesem Konto interaktiven Zugriff zu gewähren.

Kombinieren Sie dies mit einer sudoers-Regel, die genau diese Kombination aus Benutzer und Befehl erlaubt:

Eine schwer erkennbare Angriffsfläche sind von einer sudo-Sitzung geerbte Umgebungsvariablen. Standardmäßig setzt sudo die Umgebung zurück, aber falsch konfigurierte Überschreibungen von env_keep oder env_reset können vom Angreifer kontrollierte Variablen wie LD_PRELOAD, PATH oder PYTHONPATH an privilegierte Befehle weitergeben.

Bewährte Vorgehensweisen:

• Verwenden Sie in Skripten, die unter sudo laufen, immer absolute Pfade — verlassen Sie sich niemals auf $PATH
• Übergeben Sie nur die ausdrücklich benötigten Variablen: sudo env VAR=value /path/to/cmd
• Vermeiden Sie in sudoers env_keep += PATH oder env_keep += LD_*
• Verwenden Sie sudo -E nur, wenn Sie die aufrufende Umgebung vollständig kontrollieren und ihr vertrauen

Selbst wenn eine sudoers-Regel ein bestimmtes Skript erlaubt, können ihm beliebige Argumente übergeben werden, sofern die Regel diese nicht ebenfalls einschränkt. Ein häufiges Problem:

deployer ALL=(root) NOPASSWD: /opt/scripts/manage.sh

Dies erlaubt sudo /opt/scripts/manage.sh restart — aber auch sudo /opt/scripts/manage.sh --arbitrary-flag. Wenn manage.sh Argumente ungeprüft an privilegierte Unterbefehle weitergibt, entsteht ein Sicherheitsproblem.

Sorgen Sie für gestaffelten Schutz: Validieren Sie Argumente sowohl innerhalb des privilegierten Skripts als auch in sudoers:

Wenn ein Skript kurzzeitig Zugriff auf eine privilegierte Datei, ein Anmeldedatensatz oder eine Ressource benötigt, verwenden Sie Bashs trap, um sicherzustellen, dass die Bereinigung auch bei Fehlern oder Signalen ausgeführt wird. Dadurch wird verhindert, dass Privilegien zurückbleiben – beispielsweise in Form einer temporären setuid-Binärdatei oder eines Root-eigenen Sockets, der nach einem Absturz des Skripts bestehen bleibt.

Das folgende Muster erstellt als Root eine temporäre Datei, verwendet sie und entfernt sie anschließend – garantiert durch einen trap für EXIT:

Das Prinzip der geringsten Privilegien lässt sich leichter durchsetzen, wenn jedes Ereignis einer Rechteerhöhung mit Kontext protokolliert wird: Wer hat wann was und warum ausgeführt? Kombinieren Sie zwei Ebenen:

1. sudo selbst – /var/log/auth.log (Debian/Ubuntu) oder /var/log/secure (RHEL) erfasst automatisch jede sudo-Aufruf
2. Prüfprotokoll auf Skriptebene – schreiben Sie am Anfang jeder privilegierten Funktion einen strukturierten Eintrag, damit die Absicht zusammen mit dem Systemprotokoll festgehalten wird

Eine einfache Funktion für strukturierte Protokolle sorgt für konsistente und grep-freundliche Prüfpfade:

Testen Sie Ihr Verständnis der Ausführung mit geringsten Privilegien in Bash-Skripten.

In dieser Lektion haben Sie Techniken erlernt, mit denen Bash-Skripte bei jedem Schritt mit den unbedingt erforderlichen Mindestprivilegien ausgeführt werden. Hier ist eine kurze Zusammenfassung der wichtigsten Prinzipien:

• Mit $EUID absichern – brechen Sie das Skript sofort ab, wenn es unter der falschen Identität ausgeführt wird, unabhängig davon, ob Root abgelehnt oder vorausgesetzt wird
• sudo auf einzelne Befehle begrenzen – erhöhen Sie niemals die Rechte eines gesamten Skripts, sondern verwenden Sie sudo nur für die Zeilen, die es tatsächlich benötigen
• Präzise sudoers-Regeln schreiben – geben Sie und vollständige absolute Pfade und wörtliche Argumente an; vermeiden Sie Platzhalter und ALL
• Privilegien mit runuser oder sudo -u abgeben – wenn ein als Root gestartetes Skript die Ausführung an einen nicht privilegierten Benutzer übergeben muss, verwenden Sie das passende Werkzeug, anstatt alles als Root auszuführen
• Absolute Pfade verwenden – verlassen Sie sich in privilegiertem Code niemals auf $PATH; geben Sie Binärpfade fest vor, um Übernahmen zu verhindern
• Argumente in privilegierten Skripten validieren – sudoers-Regeln sind die erste Schutzlinie, aber nicht die einzige; verwenden Sie Positivlisten
• Abfangen und bereinigen – verwenden Sie trap cleanup EXIT, um sicherzustellen, dass temporäre privilegierte Ressourcen auch bei Fehlern zerstört werden
• Jede Rechteerhöhung protokollieren – strukturierte Prüfeinträge in Verbindung mit dem integrierten sudo-Syslog ermöglichen die Nachverfolgbarkeit jeder privilegierten Aktion

Konsequent angewendet reduzieren diese Praktiken die Angriffsfläche Ihrer Automatisierung von root-at-all-times auf root-only-where-provably-necessary – das Kennzeichen eines gehärteten Bash-Systems für den Produktionseinsatz.