Ubuntu 26.04: sudo-rs und sudoers-Regeln

Was sudo-rs unter Ubuntu ändert

Ubuntu 26.04 LTS liefert sudo-rs als standardmäßiges sudo aus. Daher führt der Befehl `sudo` auf einem neuen Server die in Rust neu implementierte Variante statt des ursprünglichen C-Programms aus. Die meisten sudoers-Dateien funktionieren weiterhin unverändert. Die problematische Regel enthält ein Platzhalterzeichen in den Argumenten eines Befehls. sudo-rs gleicht Glob-Muster nicht mit dem Argumenttext ab.

Ubuntu 25.10 hat zuerst umgestellt. Ubuntu 26.04 LTS hat diese Umstellung beibehalten. Ubuntu 24.04 LTS ist nicht betroffen, da dort weiterhin das ursprüngliche sudo verwendet wird, sofern Sie sudo-rs nicht manuell installieren. Relevant wird die Änderung, sobald Sie von Ubuntu 24.04 auf 26.04 aktualisieren oder einen neuen Server mit der neueren Version einrichten. Wenn Sie außerdem Zwischenversionen einsetzen, erklärt wie sich LTS- und Zwischenversionen von Ubuntu auf einem Server unterscheiden, welcher Rechner von einer solchen Änderung zuerst betroffen ist.

Prüfen, welches sudo Ihr Server tatsächlich verwendet

Ermitteln Sie das nicht anhand der Release-Nummer. Fragen Sie den Rechner.

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

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

Während der Umstellung werden beide Implementierungen paketiert. Die Rust-Implementierung ist sudo-rs, in 26.04 mit Version 0.2.13 (Stand August 2026). Die ursprüngliche, von Todd C. Miller betreute Implementierung ist weiterhin das Paket sudo. Geändert hat sich nur, dass die zugehörigen Programme das Suffix .ws tragen, damit beide Varianten gleichzeitig installiert werden können: /usr/bin/sudo.ws und /usr/bin/visudo.ws sowie cvtsudoers.ws und sudoreplay.ws. Gegen das 26.04-Archiv im September 2026 geprüft: dpkg -L sudo listet die Binärdateien mit Suffix auf, und sudo-rs liefert /usr/bin/sudo-rs zusätzlich aus.

Warum Ubuntu zu sudo-rs gewechselt ist

sudo läuft mit dem setuid-Bit als root. Jeder Benutzer auf dem System kann es starten, und 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: Jeder lokale Benutzer konnte einen Heap-Pufferüberlauf auslösen, und der Fehler war etwa zehn Jahre lang im veröffentlichten Code enthalten. Rust erkennt diese Fehlerklasse bereits zur Kompilierzeit. Das ist der Hauptgrund für die Neuentwicklung.

Der zweite Grund ist der Funktionsumfang. Er wirkt sich auf Ihre Konfiguration aus. 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 absichtlich nur einen Teil davon. Die Entwickler haben Funktionen weggelassen, die sie als speziell oder aktiv schädlich bewertet haben. Deshalb kann ein sudoers-Konstrukt, das jahrelang funktioniert hat, schlicht fehlen. Ihre Wildcard-Regel gehört zu diesen Konstrukten.

Speichersicherheit beseitigt eine Fehlerklasse. Sie macht ein Programm jedoch nicht fehlerfrei. Auch sudo-rs hat seit der Umstellung zur Standardimplementierung eigene Sicherheitskorrekturen erhalten. Halten Sie es wie jede andere Software aktuell.

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 sowie 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 "", der den Befehl ausschließlich ohne Argumente erlaubt
• ein Befehl gefolgt von * als letztem Argument, der beliebige nachfolgende Argumente erlaubt
• ein Verzeichnispfad mit / am Ende, der jeden Befehl in diesem Verzeichnis erlaubt
• !, um einen Befehl aus einer Liste auszuschließen
• eine nützliche Teilmenge von Defaults, einschließlich 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 seinem 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 * Bestandteil 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 zulässig sind. Ein abschließendes * steht für beliebige nachfolgende Argumente. Jedes andere Argument wird als wörtlicher Text verglichen. Daher ist %ops ALL = /sbin/service ntp * zulässig, weil ntp wörtlich ist und * am Ende steht. Eine Regel wie diese gewährt Ihnen dagegen nicht die beabsichtigten Berechtigungen:

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

app-* ist ein Muster innerhalb eines Arguments. sudo-rs expandiert es nicht. Daher deckt die Regel systemctl restart app-api nicht ab, und sudo verweigert den Befehl. Mit zwei Befehlen können Sie für jede Regel auf Ihrem eigenen Server die tatsächliche Konfiguration prüfen: sudo -l -U deploy gibt, als root ausgeführt, aus, welche Befehle dieses Konto tatsächlich ausführen darf, und sudo visudo -c zeigt, ob die Datei überhaupt geparst werden kann. Führen Sie diese Befehle aus, bevor Sie planlos Änderungen vornehmen.

Die Wildcard-Regel war immer eine Sicherheitslücke

Beim ursprünglichen sudo werden die eingegebenen Argumente zu einer Zeichenkette verbunden und mit einem Glob gegen die Argumentzeichenkette der Regel abgeglichen. Ein Glob kann auch Leerraum erfassen. Genau das wird fast immer übersehen.

Die Dokumentation von sudo-rs zeigt dies am deutlichsten. Eine Regel mit /bin/rm *.txt erlaubt auch sudo rm -rf /home .txt, weil das eine * -rf /home verschluckt und die verbundene 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 verbundene Zeichenkette verglichen werden, passt ein nachgestelltes Muster auch auf alles, was danach angehängt wird. Daher deckt restart app-* auch restart app-api sowie alle weiteren Argumente ab, die der Aufrufer ergänzt. Ein Muster innerhalb eines Arguments gibt die Argumente davor und danach frei. In diesen Argumenten liegt die eigentliche Wirkung eines Befehls. sudo-rs lehnt diese Konstruktion ab, statt sie auf irgendeine Weise abzusichern, weil es dafür keine allgemein sichere Form gibt.

Ersetzen Sie den Wildcard-Eintrag durch eine explizite Befehlsliste

Die meisten Wildcard-Regeln gibt es, 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

Verwenden Sie den richtigen Pfad. Eine Regel, die /bin/systemctl auf einem System angibt, 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 und nicht in /etc/sudoers. Dadurch überschreibt ein Paketupgrade 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 Wirkung. Die Konvention einzuhalten, kostet nichts.

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

Wenn die Menge der zulässigen Befehle 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 zulässig, weil das Skript selbst und nicht sudo entscheidet, was erlaubt ist. Das gilt nur, solange das Skript root gehört und für keine 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 entfernte Wildcard-Regel. Prüfen Sie die Berechtigungen mit ls -l. Wenn die Ausgabe für Sie nicht eindeutig ist, lässt sich die Berechtigungszeichenfolge drwxr-xr-x lesen innerhalb von fünf Minuten lernen. Die gleiche Regel gilt für das Verzeichnis: Auch /usr/local/sbin darf für das Konto nicht beschreibbar sein, weil eine beschreibbare Verzeichnisberechtigung bedeutet, dass die Datei vollständig ersetzt werden kann.

Dem Job ein eigenes Konto statt einer sudo-Regel geben

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

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 das als /etc/polkit-1/rules.d/50-app-api.rules. Danach kann deploy systemctl restart app-api ganz ohne sudo ausführen. Testen Sie dies aus dem exakten Kontext, in dem der Befehl verwendet wird. Eine Regel, die in Ihrer SSH-Sitzung funktioniert, sollten Sie vor dem produktiven Einsatz zusätzlich über cron prüfen. Das Konto, das die Aufgabe ausführt, sollte ausschließlich für diese Aufgabe vorhanden sein. Das ist dasselbe Prinzip wie bei Benutzerkonten mit geringsten Berechtigungen auf einem VPS.

Was sudo-rs außerdem 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 gelöscht.

Eine zentrale sudoers-Speicherung in LDAP ist nicht verfügbar. 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 nur die Ablage der Richtlinien in einem Verzeichnisdienst.

INTERCEPT, das Shell-Escapes aus einem erlaubten Befehl verhindern sollte, ist nicht implementiert. Gegen einen entschlossenen Benutzer war es ohnehin nie zuverlässig. Wenn eine Regel jemandem erlaubt, einen Editor oder Interpreter als root auszuführen, verfügt diese Person über root-Rechte. 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 zurück zu sudo.ws wechseln?

Das können Sie tun. Während des 26.04-Zyklus bleibt das Original genau aus diesem Grund paketiert.

sudo apt install sudo
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. Diese Liste zeigt, welche Pfade Ihr eigenes System akzeptiert. Wenn Sie später wieder zu sudo-rs wechseln möchten, setzen Sie die Alternative auf den Pfad der sudo-rs-Binärdatei aus derselben Liste.

Lassen Sie eine zweite SSH-Sitzung geöffnet, angemeldet und untätig, bevor Sie Änderungen vornehmen, die sudo betreffen. 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 werden können. Diese Gewohnheit gehört zu allem, was Sie in den ersten zehn Minuten auf einem neuen VPS erledigen.

Betrachten Sie den Rückwechsel 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 hatte, als ihr Autor ihr zugeschrieben hatte.

FAQ

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

Ubuntu 26.04 LTS verwendet sudo-rs als standardmäßiges sudo. 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 und ein einzelnes * darf als letztes Argument verwendet werden. Eine Regel wie /usr/bin/systemctl restart app-* enthält ein Muster in der Mitte eines Arguments. Sie gewährt daher keine Berechtigung, und der Befehl wird abgelehnt. Führen Sie sudo -l -U deploy als root aus, um die tatsächlichen Berechtigungen des Kontos zu prüfen. Ersetzen Sie die Regel anschließend durch die exakten Befehle oder durch ein root-eigenes Wrapper-Skript.

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

Das ursprüngliche sudo ist im Paket sudo enthalten. Seine Binärdateien tragen das Suffix .ws. Installieren Sie es mit sudo apt install sudo. Setzen Sie anschließend mit sudo update-alternatives --set sudo /usr/bin/sudo.ws die entsprechende Alternative. Führen Sie zuerst update-alternatives --config sudo aus, um die von Ihrem System angebotenen exakten Pfade zu prüfen. Lassen Sie während der Änderung eine zweite SSH-Sitzung geöffnet. Dadurch wird sudo-ldap nicht wiederhergestellt. Diese Funktion 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 Syntaxelemente 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 durch fehlende Konstrukte und nicht durch abweichendes 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 beim ursprünglichen sudo wurde davon abgeraten, weil eine von der aufrufenden Person kontrollierte Umgebung an einen root-Prozess übergeben wird. Dadurch kann das Verhalten dieses Prozesses verändert werden. Geben Sie stattdessen in sudoers nur die tatsächlich benötigten Variablen an, 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.