sudo-rs auf Ubuntu: Was ändert sich in sudoers?

Änderungen durch sudo-rs auf Ubuntu

Ubuntu 26.04 LTS verwendet sudo-rs standardmäßig als sudo. Daher führt der Befehl sudo auf einem neuen Server die Rust-Neuimplementierung statt des ursprünglichen C-Programms aus. Die meisten sudoers-Dateien funktionieren weiterhin unverändert. Problematisch ist eine Regel mit einem Wildcard-Zeichen in den Argumenten eines Befehls, weil sudo-rs keine Glob-Muster im Argumenttext abgleicht.

Ubuntu 25.10 führte die Umstellung zuerst ein. Ubuntu 26.04 LTS behielt sie bei. Ubuntu 24.04 LTS ist nicht betroffen, weil diese Version weiterhin das ursprüngliche sudo verwendet, sofern Sie sudo-rs nicht manuell installieren. Relevant wird die Änderung, wenn Sie von Ubuntu 24.04 auf 26.04 aktualisieren oder einen neuen Server mit der neueren Version einrichten. Wenn Sie außerdem Interim-Versionen einsetzen, erklärt wie sich LTS- und Interim-Versionen von Ubuntu auf einem Server unterscheiden, welcher Rechner von einer solchen Änderung zuerst betroffen ist.

Prüfen Sie, welches sudo auf Ihrem Server tatsächlich ausgeführt wird

Ermitteln Sie das nicht anhand der Versionsnummer. Fragen Sie den Rechner.

sudo --version
update-alternatives --config sudo
dpkg -l 'sudo*'

Vertrauen Sie sudo --version auf Ihrem eigenen System mehr als jeder Versionstabelle im Internet, auch dieser Seite. update-alternatives --config sudo ist die andere Hälfte der Antwort: Der Befehl listet jeden installierten Anbieter von /usr/bin/sudo auf und kennzeichnet den ausgewählten. Ein installiertes Paket ist nicht dasselbe wie ein ausgewählter Anbieter. Lesen Sie daher die Auswahl und nicht die Paketliste.

Während der Umstellung werden beide Implementierungen als Pakete bereitgestellt. Die Rust-Implementierung ist sudo-rs und hat in 26.04 im August 2026 die Version 0.2.13. Das Original, das von Todd C. Miller gepflegt wird, ist als sudo.ws paketiert. Die zugehörigen Programme tragen das Suffix .ws: sudo.ws und visudo.ws.

Warum Ubuntu auf sudo-rs umgestellt hat

sudo läuft mit dem Setuid-Bit als root. Jeder Benutzer auf dem System kann es starten. Es startet mit vollständigen Berechtigungen. Deshalb kann ein Speicherfehler darin zu einem lokalen Root-Exploit führen. CVE-2021-3156 war genau ein solcher Fall: Ein Heap-Pufferüberlauf war für jeden lokalen Benutzer erreichbar. Der Fehler befand sich etwa zehn Jahre lang im veröffentlichten Code. Rust erkennt diese Fehlerklasse bereits zur Kompilierzeit. Das ist die zentrale Begründung für die Neuentwicklung.

Der zweite Grund ist der Funktionsumfang. Er betrifft auch Ihre Konfiguration. Das ursprüngliche sudo hat über drei Jahrzehnte einen großen Funktionsumfang angesammelt. Jede Funktion bedeutet zusätzlichen Code, der als root ausgeführt wird. sudo-rs implementiert bewusst nur eine Teilmenge. Funktionen, die seine Entwickler als speziell oder aktiv schädlich eingestuft haben, wurden weggelassen. Deshalb kann eine sudoers-Konstruktion, die jahrelang funktioniert hat, schlicht fehlen. Ihre Wildcard-Regel gehört dazu.

Speichersicherheit beseitigt eine Fehlerklasse. Sie macht ein Programm nicht fehlerfrei. sudo-rs hat seit der Umstellung als Standardprogramm eigene Sicherheitskorrekturen erhalten. Installieren Sie dafür wie bei jeder anderen Software die verfügbaren Patches.

Welche sudoers-Regeln weiterhin funktionieren

Die Datei bleibt dieselbe. sudo-rs liest /etc/sudoers und die Drop-in-Dateien in /etc/sudoers.d/. Die üblichen Einträge, die Serveradministratoren verwenden, werden unterstützt:

• deploy ALL=(ALL:ALL) ALL und Gruppenformen wie %sudo ALL=(ALL:ALL) ALL
• die Tags NOPASSWD: und PASSWD:
• User_Alias, Runas_Alias, Host_Alias und Cmnd_Alias
• ein Befehl mit einer exakten Argumentliste, zum Beispiel /usr/bin/systemctl restart app-api
• ein Befehl gefolgt von "", wodurch der Befehl nur ohne Argumente ausgeführt werden darf
• ein Befehl mit * als letztem Argument, wodurch beliebige nachfolgende Argumente erlaubt werden
• ein Verzeichnispfad, der mit / endet und jeden Befehl in diesem Verzeichnis erlaubt
• !, um einen Befehl aus einer Liste auszuschließen
• eine nützliche Teilmenge von Defaults, darunter secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw und use_pty

Zwei Defaults verhalten sich anders und führen häufig zu Problemen. env_reset kann in sudo-rs nicht deaktiviert werden. Es ist immer aktiviert. use_pty ist standardmäßig aktiviert. Daher wird der Befehl in einem eigenen Pseudo-Terminal ausgeführt.

Warum Ihre Wildcard-Regel in sudoers nicht mehr greift

Wildcards sind weiterhin an einer Stelle zulässig: im Dateinamen des Befehls. Eine Regel mit %ops ALL = /sbin/fsck* erlaubt weiterhin sudo fsck und sudo fsck_exfat, weil * Teil des Pfads ist, der mit dem Dateisystem abgeglichen wird.

Innerhalb der Argumentliste akzeptiert sudo-rs nur zwei Sonderformen, und keine davon ist ein Muster. "" bedeutet, dass keine Argumente übergeben werden. Ein abschließendes * steht für beliebige nachfolgende Argumente. Jedes andere Argument wird als Literalkontext verglichen. %ops ALL = /sbin/service ntp * ist daher gültig, weil ntp wörtlich interpretiert wird und * am Ende steht. Eine Regel wie diese gewährt dagegen nicht die beabsichtigten Berechtigungen:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart app-*

app-* ist ein Muster innerhalb eines Arguments. sudo-rs erweitert es nicht, daher deckt die Regel systemctl restart app-api nicht ab und sudo verweigert den Befehl. Mit zwei Befehlen können Sie die tatsächliche Wirkung jeder Regel auf Ihrem eigenen Server prüfen: sudo -l -U deploy zeigt, als root ausgeführt, welche Befehle dieses Konto tatsächlich ausführen darf, und sudo visudo -c prüft, ob die Datei überhaupt syntaktisch gültig ist. Führen Sie diese Befehle aus, bevor Sie wahllos Änderungen vornehmen.

Die Wildcard-Regel war immer eine Lücke

Beim ursprünglichen sudo werden die von Ihnen eingegebenen Argumente zu einer Zeichenkette zusammengefügt und mit einem Glob-Muster gegen die Argumentzeichenkette der Regel abgeglichen. Ein Glob-Muster umfasst auch Leerzeichen. Genau das übersehen fast alle.

Die Dokumentation von sudo-rs zeigt dies am deutlichsten. Eine Regel mit /bin/rm *.txt erlaubt auch sudo rm -rf /home .txt, weil das einzelne * -rf /home verschluckt und die zusammengefügte Zeichenkette weiterhin mit .txt endet. Die Regel liest sich wie „nur Textdateien“. Tatsächlich bedeutet sie: „beliebige Argumente, solange die Zeile mit .txt endet“.

Dasselbe gilt für das systemctl-Beispiel. Da die Argumente als eine zusammengefügte Zeichenkette verglichen werden, passt ein nachgestelltes Muster auch zu allem, was danach angehängt wird. Daher erlaubt restart app-* neben restart app-api auch beliebige weiteren Argumente, die der Aufrufer hinzufügt. Ein Muster innerhalb eines Arguments gibt die umliegenden Argumente frei. In den Argumenten liegt jedoch die Befehlsmacht. sudo-rs lehnt dieses Konstrukt ab, statt zu versuchen, es sicher zu machen, weil es dafür keine allgemein sichere Form gibt.

Ersetzen Sie den Wildcard durch eine explizite Befehlsliste

Wildcard-Regeln gibt es meist, weil jemand nicht vier Zeilen eingeben wollte. Geben Sie die vier Zeilen ein.

Cmnd_Alias APP_RESTART = /usr/bin/systemctl restart app-api, /usr/bin/systemctl restart app-worker
Cmnd_Alias APP_STATUS = /usr/bin/systemctl status app-api, /usr/bin/systemctl status app-worker
deploy ALL=(root) NOPASSWD: APP_RESTART, APP_STATUS

Geben Sie den Pfad korrekt an. Eine Regel mit /bin/systemctl auf einem System, auf dem sich die Binärdatei unter /usr/bin/systemctl befindet, greift nie. Der Fehler sieht dann genauso aus wie ein Berechtigungsproblem. Prüfen Sie dies mit command -v systemctl und fügen Sie die Ausgabe ein.

Legen Sie die Regel in einer eigenen Drop-in-Datei ab, statt sie in /etc/sudoers einzutragen. Dann überschreibt ein Paket-Upgrade Ihre Änderung nicht:

sudo visudo -f /etc/sudoers.d/90-deploy
sudo visudo -c
sudo -l -U deploy

Benennen Sie die Datei ohne Punkt und ohne nachgestellte Tilde. Das ursprüngliche sudo ignoriert Dateien in sudoers.d, deren Namen einen Punkt enthalten. 90-deploy.conf bleibt daher klassischerweise ohne sichtbare Wirkung. Die Konvention einzuhalten, kostet nichts.

Verwenden Sie einen Root-eigenen Wrapper, wenn die Liste zu lang wird

Wenn die Menge der zulässigen Werte zu groß für eine Auflistung ist, verlagern Sie die Entscheidung aus sudoers in ein kleines Programm, das root gehört.

sudo tee /usr/local/sbin/app-restart >/dev/null <<'EOF'
#!/bin/sh
set -eu
case "${1:-}" in
  app-api|app-worker) ;;
  *) echo "app-restart: not allowed: ${1:-}" >&2; exit 1 ;;
esac
exec /usr/bin/systemctl restart "$1"
EOF
sudo chown root:root /usr/local/sbin/app-restart
sudo chmod 0755 /usr/local/sbin/app-restart
ls -l /usr/local/sbin/app-restart

Auf der sudoers-Seite wird dann nur ein Befehl angegeben:

deploy ALL=(root) NOPASSWD: /usr/local/sbin/app-restart *

Das abschließende * ist hier vertretbar, weil das Skript und nicht sudo entscheidet, was zulässig ist. Das gilt nur, solange das Skript root gehört und für keinen anderen Benutzer beschreibbar ist. Wenn deploy in die Datei schreiben kann, kann deploy ihren Inhalt ersetzen und beliebige Befehle als root ausführen. Das ist gefährlicher als die Wildcard-Regel, die Sie entfernt haben. Prüfen Sie die Berechtigungen mit ls -l. Wenn die Ausgabe für Sie nicht unmittelbar verständlich ist, können Sie die Berechtigungszeichenfolge drwxr-xr-x lesen innerhalb von fünf Minuten lernen. Dieselbe Regel gilt für das Verzeichnis: /usr/local/sbin darf für das Konto ebenfalls nicht beschreibbar sein, weil eine beschreibbare Verzeichnisstruktur bedeutet, dass die Datei vollständig ersetzt werden kann.

Geben Sie dem Job ein eigenes Konto statt einer sudo-Regel

Die bessere Frage lautet oft, warum der Befehl überhaupt root benötigt. Ein Dienst, der unter einem eigenen Benutzer ausgeführt wird, kann von diesem Benutzer verwaltet werden. Eine sudoers-Zeile ist dann nicht erforderlich. Bei System-Units delegiert systemd diese Entscheidung bereits an polkit. Eine Regel kann daher eine Unit und einen Bediener benennen:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "app-api.service" &&
        subject.user == "deploy") {
        return polkit.Result.YES;
    }
});

Speichern Sie dies als /etc/polkit-1/rules.d/50-app-api.rules. Dann kann deploy systemctl restart app-api ganz ohne sudo ausführen. Testen Sie die Regel aus genau dem Kontext, in dem sie verwendet wird. Eine Regel, die in Ihrer SSH-Sitzung funktioniert, sollte vor dem produktiven Einsatz auch aus cron bestätigt werden. Das ausführende Konto sollte ausschließlich für diese Aufgabe existieren. Das ist derselbe Grundsatz wie bei Benutzerkonten mit den geringsten erforderlichen Rechten auf einem VPS.

Was sudo-rs nicht unterstützt

sudo -E ist nicht implementiert. Benennen Sie die benötigten Variablen stattdessen mit Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" und beachten Sie, dass env_reset immer aktiviert ist. Alles, was nicht beibehalten wird, wird daher gelöscht.

Die zentrale sudoers-Speicherung in LDAP entfällt. sudoers.ldap und cvtsudoers sind nicht implementiert, und das Paket sudo-ldap wurde in 26.04 entfernt. Die LDAP-Authentifizierung über PAM oder SSSD funktioniert weiterhin. Nicht unterstützt wird lediglich die Ablage der Richtlinie in einem Verzeichnisdienst.

INTERCEPT, das Shell-Escapes aus einem erlaubten Befehl verhindern sollte, ist nicht implementiert. Gegen einen entschlossenen Benutzer war es ohnehin nie wirksam. Wenn eine Regel jemandem erlaubt, einen Editor oder Interpreter als root auszuführen, hat diese Person root-Zugriff. Keine sudo-Option kann das ändern.

Die Sitzungsaufzeichnung ist nicht implementiert. Daher gibt es kein I/O-Log und kein sudoreplay. Die Protokollierung erfolgt ausschließlich über syslog. Eine logfile-Option zur Umleitung an einen anderen Ort gibt es nicht. sudo-Meldungen landen daher dort, wohin Ihr System syslog bereits weiterleitet.

Sollten Sie wieder zu sudo.ws wechseln?

Das ist möglich. Während des 26.04-Zyklus bleibt die ursprüngliche Variante genau aus diesem Grund paketiert.

sudo apt install sudo.ws
update-alternatives --config sudo
sudo update-alternatives --set sudo /usr/bin/sudo.ws

Übernehmen Sie die exakten Pfade aus der Ausgabe von --config und nicht von dieser Seite. Nur diese Liste enthält die Pfade, die Ihr eigenes System akzeptiert. Wenn Sie später zu sudo-rs zurückkehren, setzen Sie die Alternative auf den Pfad zur sudo-rs-Binärdatei aus derselben Liste.

Lassen Sie eine zweite SSH-Sitzung geöffnet, angemeldet und untätig, bevor Sie Änderungen an sudo vornehmen. Eine sudoers-Datei mit Syntaxfehlern oder eine Alternative, die auf eine nicht installierte Binärdatei zeigt, kann dazu führen, dass Sie auf einem entfernten System nicht mehr zu root wechseln können. Diese Gewohnheit gehört zu allem, was Sie in den ersten zehn Minuten auf einem neuen VPS tun.

Betrachten Sie den Wechsel zurück als Frist und nicht als Fehlerbehebung. Er verschafft Ihnen eine Woche, um die Regeln ordnungsgemäß neu zu schreiben. Diese Überarbeitung lohnt sich unabhängig davon, weil jede gelöschte Wildcard-Regel mehr Berechtigungen erteilt hat, als ihr Verfasser darin erkannt hatte.

FAQ

Warum funktioniert meine Sudoers-Wildcard-Regel unter Ubuntu 26.04 nicht mehr?

Ubuntu 26.04 LTS verwendet standardmäßig sudo-rs. sudo-rs gleicht keine Wildcard-Muster innerhalb der Argumente eines Befehls ab. Eine Wildcard im Dateinamen des Befehls ist zulässig. "" steht für keine Argumente. Außerdem ist ein einzelnes * als letztes Argument zulässig. Eine Regel wie /usr/bin/systemctl restart app-* enthält ein Muster innerhalb eines Arguments. Sie gewährt daher keine Berechtigung, und der Befehl wird abgelehnt. Führen Sie als root sudo -l -U deploy aus, um die tatsächlichen Berechtigungen des Accounts zu prüfen. Ersetzen Sie die Regel anschließend durch die exakten Befehle oder durch ein Wrapper-Script im Besitz von root.

Wie wechsle ich unter Ubuntu 26.04 zurück zum ursprünglichen sudo?

Das ursprüngliche sudo ist als sudo.ws paketiert. Installieren Sie es mit sudo apt install sudo.ws. Setzen Sie anschließend mit sudo update-alternatives --set sudo /usr/bin/sudo.ws die Alternative darauf. Führen Sie zuerst update-alternatives --config sudo aus, um die von Ihrem System angebotenen exakten Pfade anzuzeigen. Lassen Sie während der Änderung eine zweite SSH-Sitzung geöffnet. Dadurch wird sudo-ldap nicht wiederhergestellt. Dieses wurde unabhängig von der ausgewählten Implementierung aus 26.04 entfernt.

Liest sudo-rs dieselbe Datei /etc/sudoers?

Ja. sudo-rs liest /etc/sudoers und die Drop-in-Dateien unter /etc/sudoers.d/. Dabei gelten dieselben Syntaxregeln für Benutzer, Gruppen, Aliase, Run-as-Spezifikationen und das Tag NOPASSWD. sudo-rs implementiert nur eine Teilmenge der Sudoers-Sprache. Die Unterschiede zeigen sich daher in fehlenden Konstrukten und nicht in abweichendem Verhalten vorhandener Konstrukte. Bearbeiten Sie die Konfiguration mit sudo visudo. Prüfen Sie sie anschließend mit sudo visudo -c, bevor Sie Ihre Sitzung schließen.

Was ersetzt sudo -E in sudo-rs?

sudo -E ist nicht implementiert. Bereits im ursprünglichen sudo wurde davon abgeraten, weil ein Root-Prozess mit einer vom Aufrufer kontrollierten Umgebung sein Verhalten auf bekannte Weise verändern kann. Geben Sie in sudoers stattdessen nur die tatsächlich benötigten Variablen frei, beispielsweise mit einer Zeile wie Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". env_reset ist in sudo-rs immer aktiviert und kann nicht deaktiviert werden. Jede Variable, die Sie nicht beibehalten, wird daher entfernt.