Bash-Skripte mit geringsten Rechten ausführen: sudo-Regeln statt SUID-Fallstricke

1. Least Privilege bei Deployment-Skripten: das Grundproblem

Ein Deployment-Skript braucht selten wirklich vollen Root-Zugriff. Meist reicht es, eine Handvoll Dateien mit bestimmten Rechten zu schreiben, einen Dienst neu zu starten oder einen einzelnen privilegierten Port zu binden. Trotzdem landen solche Skripte in der Praxis regelmäßig in einer sudoers-Zeile wie deploy ALL=(ALL) NOPASSWD: ALL, weil das schneller einzurichten ist als eine präzise, auf das Skript zugeschnittene Regel.

Das Problem dabei ist nicht theoretisch: Wird der Account, mit dem das Skript läuft, kompromittiert, etwa über eine Schwachstelle in einer der aufgerufenen Anwendungen, erbt ein Angreifer sofort vollen Root-Zugriff auf den gesamten Server, statt auf die eigentlich benötigten, begrenzten Aktionen beschränkt zu bleiben. Least Privilege bedeutet, diesen Radius von Anfang an so klein wie möglich zu halten, nicht nachträglich einzuschränken, wenn es bereits zu spät ist.

2. Präzise sudoers-Regeln statt globalem ALL=(ALL)

Eine gezielte sudoers-Regel erlaubt genau die Befehle, die ein Skript tatsächlich benötigt, mit exakten Argumenten oder Argumentmustern, statt einem pauschalen Freibrief. Die Datei /etc/sudoers.d/deploy-nginx-reload etwa kann festlegen, dass der Nutzer deploy ausschließlich systemctl reload nginx ohne Passwort ausführen darf, aber weder systemctl stop noch einen beliebigen anderen Dienst neu starten kann.

Wichtig ist, den vollständigen Pfad zum Kommando anzugeben und keine Wildcards zu verwenden, die mehr erlauben als beabsichtigt. Ein Eintrag wie deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx lässt sich nicht durch zusätzliche Argumente erweitern, während /usr/bin/systemctl * faktisch wieder vollen Zugriff auf sämtliche systemctl-Unterkommandos gewährt, inklusive potenziell gefährlicher wie systemctl edit.

# /etc/sudoers.d/deploy-nginx-reload -- edit only with visudo -f
# Precise: exact command, exact arguments, no wildcards
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart php8.4-fpm

# Bad: grants full control over every systemctl subcommand
# deploy ALL=(root) NOPASSWD: /usr/bin/systemctl *

3. Deployment-Skripte gezielt mit sudo aufrufen statt komplett als Root laufen zu lassen

Statt ein komplettes Deployment-Skript als Root zu starten, ist es robuster, das Skript größtenteils als eingeschränkter Nutzer laufen zu lassen und nur die einzelnen Schritte, die tatsächlich erhöhte Rechte brauchen, gezielt mit sudo aufzurufen. Das reduziert die Angriffsfläche erheblich, weil ein Fehler oder eine Schwachstelle im überwiegenden Teil des Skripts nicht automatisch zu vollem Root-Zugriff führt.

In der Praxis bedeutet das, ein Skript in klar getrennte Funktionsblöcke aufzuteilen: Build-Schritte, Datei-Kopieroperationen und Health-Checks laufen als normaler Deployment-Nutzer, während nur der Neustart eines Dienstes oder das Schreiben in ein root-eigentümerschaftliches Verzeichnis über eine präzise sudo-Zeile erfolgt, die in der sudoers-Datei exakt freigegeben ist.

#!/usr/bin/env bash
set -euo pipefail

# Runs as the unprivileged 'deploy' user, no sudo needed here
rsync -a --delete ./build/ /var/www/app/
bin/magento setup:upgrade

# Only this single step needs elevated rights, scoped by sudoers
sudo /usr/bin/systemctl reload nginx

curl -fsS https://shop.example.com/health >/dev/null

4. Warum das SUID-Bit auf einem Bash-Skript wirkungslos ist

Ein naheliegender, aber falscher Gedanke ist, ein Skript wie eine kompilierte Binärdatei mit dem SUID-Bit auszustatten (chmod u+s script.sh), damit es beim Ausführen automatisch mit den Rechten seines Besitzers läuft. Bei einer echten ELF-Binärdatei funktioniert das tatsächlich so, bei einem Skript mit Shebang-Zeile ignoriert der Linux-Kernel das SUID-Bit jedoch bewusst und startet es weiterhin mit den Rechten des aufrufenden Nutzers.

Der Grund ist eine seit Jahrzehnten bekannte Race Condition: Zwischen dem Moment, in dem der Kernel die Shebang-Zeile liest und den passenden Interpreter startet, und dem Moment, in dem dieser Interpreter das Skript tatsächlich öffnet, kann ein Angreifer die Datei austauschen (Time-of-Check-to-Time-of-Use). Ein SUID-Interpreter würde dann ein beliebiges, vom Angreifer kontrolliertes Skript mit erhöhten Rechten ausführen. Der Linux-Kernel deaktiviert das SUID-Bit deshalb pauschal für alle interpretierten Skripte.

# This has NO effect on Linux for a script with a #!/bin/bash shebang
chmod u+s /usr/local/bin/deploy.sh
ls -l /usr/local/bin/deploy.sh
# -rwsr-xr-x 1 root root ... deploy.sh   <- bit is set, kernel ignores it

# Verify: still runs as the invoking user, not as root
whoami
/usr/local/bin/deploy.sh  # prints the caller's UID, not root's

5. Alternativen zum SUID-Bit: kleine C-Wrapper und sudo-Policies

Wer wirklich eine SUID-artige Anhebung von Rechten für eine ganz konkrete Aktion braucht, etwa das Binden an einen privilegierten Port oder das Schreiben in eine root-eigentümerschaftliche Datei, sollte einen minimalen, kompilierten C-Wrapper schreiben, der exakt diese eine Aktion ausführt und danach seine Rechte sofort wieder abgibt (setuid/seteuid im Code, nicht über das Dateisystem-Bit). Ein solcher Wrapper ist auditierbar, klein und nicht von der Shebang-Race-Condition betroffen, weil er eine echte Binärdatei ist.

Für die überwiegende Mehrheit der Deployment-Fälle ist ein C-Wrapper aber unnötiger Aufwand, wenn eine präzise sudoers-Regel dasselbe Ergebnis erreicht, ohne zusätzlichen Code pflegen zu müssen. Die Faustregel lautet: sudo für Aktionen, die ein anderer Nutzer im Klartext nachvollziehen und in einer Textdatei versionieren kann, ein Wrapper nur für die seltenen Fälle, in denen selbst sudo zu grobkörnig ist.

6. Linux Capabilities als feingranulare Alternative zu Root

Statt einem Prozess pauschal Root-Rechte zu geben, erlauben Linux Capabilities, genau eine einzelne privilegierte Fähigkeit freizuschalten, etwa CAP_NET_BIND_SERVICE, um einen Port unterhalb von 1024 zu binden, ohne alle anderen Root-Rechte zu erhalten. Mit setcap lässt sich diese Fähigkeit direkt an eine Binärdatei binden, was für kompilierte Programme eine deutlich feinere Alternative zu SUID darstellt.

Für reine Bash-Skripte greift setcap allerdings aus demselben Grund wie SUID nicht direkt, da Capabilities ebenfalls an eine ausführbare Binärdatei gebunden werden, nicht an ein interpretiertes Skript. Wer Capabilities für eine Skript-gesteuerte Aktion braucht, muss die eigentliche privilegierte Operation in einen kleinen kompilierten Helfer auslagern und diesen mit der passenden Capability versehen, während das Bash-Skript selbst unprivilegiert bleibt.

# Grant only the ability to bind privileged ports, nothing else
sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/http-helper

# Verify which capabilities a binary actually carries
getcap /usr/local/bin/http-helper
# /usr/local/bin/http-helper cap_net_bind_service=ep

7. sudo-Nutzung nachvollziehbar machen: Logging und Auditing

Jede über sudo ausgeführte Aktion landet standardmäßig im System-Log, meist über syslog oder journald, inklusive Zeitstempel, aufrufendem Nutzer und exaktem Kommando. Für Deployment-Skripte lohnt es sich, diese Logs gezielt auszuwerten, um zu erkennen, ob ein Skript regelmäßig mit unerwarteten Argumenten aufgerufen wird oder ob eine sudo-Regel großzügiger ist, als tatsächlich genutzt wird.

Mit sudo -l lässt sich für jeden Nutzer jederzeit prüfen, welche Kommandos konkret erlaubt sind, was sich hervorragend als regelmäßiger Audit-Schritt eignet, gerade bevor eine neue sudoers-Regel produktiv geschaltet wird. Eine Regel, die nach einigen Monaten im Log nie mit vollem Argumentumfang genutzt wurde, sollte enger gefasst werden, statt großzügig zu bleiben, nur weil sie einmal so eingerichtet wurde.

8. Praxisbeispiel: ein least-privilege Deployment-Setup für Magento

In einem typischen Magento-Deployment läuft der überwiegende Teil, Composer-Install, Static-Content-Deploy, Cache-Flush, vollständig als eigentümerschaftlicher www-data- oder Deployment-Nutzer ohne jede erhöhte Berechtigung. Nur zwei Schritte benötigen tatsächlich erhöhte Rechte: der Neustart von PHP-FPM nach einem Opcache-relevanten Update und gegebenenfalls das Setzen von Datei-Besitzern nach einem Composer-Install, das versehentlich falsche Owner hinterlassen hat.

Für genau diese zwei Fälle reichen zwei präzise sudoers-Zeilen völlig aus, ohne dass der Deployment-Nutzer jemals volle Root-Rechte braucht. Dieses Muster lässt sich auf praktisch jedes Deployment-Skript übertragen: zuerst den kompletten Ablauf ohne sudo skizzieren, dann nur die tatsächlich privilegierten Einzelschritte identifizieren und für jeden davon genau eine sudoers-Zeile schreiben.

# /etc/sudoers.d/deploy-magento
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart php8.4-fpm
deploy ALL=(root) NOPASSWD: /usr/bin/chown -R www-data\:www-data /var/www/app/pub/static

#!/usr/bin/env bash
set -euo pipefail
composer install --no-dev --optimize-autoloader
bin/magento setup:static-content:deploy -f
sudo /usr/bin/chown -R www-data:www-data /var/www/app/pub/static
sudo /usr/bin/systemctl restart php8.4-fpm

9. sudo, SUID und Capabilities im Vergleich

Alle drei Mechanismen lösen dasselbe Grundproblem, einem Prozess mehr Rechte zu geben als sein aufrufender Nutzer besitzt, unterscheiden sich aber deutlich in Sicherheit, Auditierbarkeit und Eignung für Shell-Skripte. sudo ist für Skripte die einzige praktikable, direkt einsetzbare Option, während SUID auf Skripten wirkungslos bleibt und Capabilities nur für kompilierte Helfer greifen.

Die folgende Tabelle fasst zusammen, welcher Mechanismus für welchen Anwendungsfall geeignet ist, und macht deutlich, warum sudo mit präzisen Regeln für die allermeisten Bash-Deployment-Skripte die richtige und einzig direkt wirksame Wahl bleibt.

10. Zusammenfassung

11. FAQ: Least Privilege für Bash-Skripte: Das Wichtigste auf einen Blick