Ubuntu 26.04 en sudo-rs: wijzigingen voor sudoers

Wat sudo-rs wijzigt in Ubuntu

Ubuntu 26.04 LTS levert sudo-rs als de standaard sudo, waardoor het sudo-commando op een nieuwe server de Rust-herimplementatie uitvoert in plaats van het oorspronkelijke C-programma. De meeste sudoers-bestanden blijven ongewijzigd functioneren. De regel die niet meer werkt, is de regel met een wildcard in de argumenten van een commando, omdat sudo-rs geen glob-patronen matcht tegen argumenttekst.

Ubuntu 25.10 voerde de wijziging als eerste door en 26.04 LTS heeft deze behouden. Ubuntu 24.04 LTS is niet getroffen, aangezien dit systeem de oorspronkelijke sudo blijft gebruiken tenzij u sudo-rs handmatig installeert. Dit is relevant op het moment dat u upgrade van Ubuntu 24.04 naar 26.04, of wanneer u een nieuwe server opzet met de nieuwere release. Als u ook de tussenliggende releases gebruikt, legt hoe LTS- en interim-Ubuntu-releases verschillen op een server uit welke machine als eerste met een dergelijke wijziging te maken krijgt.

Controleer welke sudo uw server daadwerkelijk gebruikt

Leid dit niet af uit het versienummer. Vraag het aan de machine.

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

Vertrouw op sudo --version op uw eigen systeem in plaats van op een versietabel op internet, inclusief deze pagina. update-alternatives --config sudo vormt de andere helft van het antwoord: het toont elke geïnstalleerde provider van /usr/bin/sudo en markeert de geselecteerde versie. Dat een pakket is geïnstalleerd, betekent niet dat het ook is geselecteerd. Lees daarom de selectie, niet de pakketlijst.

Beide implementaties worden tijdens de overgang meegeleverd. De Rust-versie is sudo-rs, met versie 0.2.13 in 26.04 per augustus 2026. Het origineel, onderhouden door Todd C. Miller, is nog steeds het sudo-pakket; het verschil is dat de programma's daarvan een .ws-achtervoegsel hebben, zodat beide tegelijkertijd geïnstalleerd kunnen zijn: /usr/bin/sudo.ws en /usr/bin/visudo.ws, naast cvtsudoers.ws en sudoreplay.ws. Geverifieerd tegen het 26.04-archief in september 2026: dpkg -L sudo toont de binaries met achtervoegsel, en sudo-rs levert /usr/bin/sudo-rs daarnaast.

Waarom Ubuntu is overgestapt op sudo-rs

sudo is setuid root. Elke gebruiker op de server kan het starten, waarna het met volledige privileges wordt uitgevoerd. Een geheugenfout in de code vormt daarom een lokaal root-lek. CVE-2021-3156 was precies zo'n geval: een heap buffer overflow die door elke lokale gebruiker kon worden geactiveerd en die ongeveer tien jaar lang in de uitgebrachte code aanwezig was. Rust voorkomt dit type fouten tijdens het compileren, wat het voornaamste argument is voor de herschrijving.

De tweede reden is de omvang, en dit is het punt dat uw configuratie beïnvloedt. De oorspronkelijke sudo heeft in drie decennia een uitgebreide set functies verzameld, waarbij elke functie extra code betekent die als root wordt uitgevoerd. sudo-rs implementeert bewust een subset. Alles wat de auteurs als niche of potentieel schadelijk beschouwden, is weggelaten. Een sudoers-constructie die jarenlang werkte, kan daarom simpelweg ontbreken. Uw wildcard-regel is daar een voorbeeld van.

Geheugenveiligheid elimineert één klasse van bugs. Het maakt een programma echter niet foutloos, en sudo-rs heeft sinds het de standaard werd zelf ook beveiligingsupdates uitgebracht. Patch het daarom zoals elk ander pakket.

Welke sudoers-regels werken nog

Het bestand is hetzelfde bestand. sudo-rs leest /etc/sudoers en de aanvullende bestanden in /etc/sudoers.d/, en de gebruikelijke regels die een systeembeheerder schrijft worden ondersteund:

• deploy ALL=(ALL:ALL) ALL, en groepsvormen zoals %sudo ALL=(ALL:ALL) ALL
• de tags NOPASSWD: en PASSWD:
• User_Alias, Runas_Alias, Host_Alias en Cmnd_Alias
• een commando met een exacte lijst argumenten, bijvoorbeeld /usr/bin/systemctl restart app-api
• een commando gevolgd door "", wat het commando alleen toestaat zonder enige argumenten
• een commando gevolgd door * als laatste argument, wat elk willekeurig volgend argument toestaat
• een mappad eindigend op /, wat elk commando in die map toestaat
• ! om een commando uit een lijst te verwijderen
• een bruikbare subset van Defaults, inclusief secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw en use_pty

Twee defaults gedragen zich anders en zorgen voor verwarring. env_reset kan niet worden uitgeschakeld in sudo-rs: deze staat altijd aan. use_pty staat standaard aan, waardoor het commando in zijn eigen pseudo-terminal wordt uitgevoerd.

Waarom uw wildcard sudoers-regel niet langer matcht

Wildcards zijn op één plek nog steeds toegestaan: in de bestandsnaam van het commando. Een regel als %ops ALL = /sbin/fsck* staat nog steeds sudo fsck en sudo fsck_exfat toe, omdat de * onderdeel is van het pad dat wordt vergeleken met het bestandssysteem.

Binnen de argumentenlijst accepteert sudo-rs slechts twee speciale vormen, en geen van beide is een patroon. "" betekent geen argumenten. Een afsluitende * betekent alle resterende argumenten. Elk ander argument wordt vergeleken als letterlijke tekst. Daarom is %ops ALL = /sbin/service ntp * in orde, omdat ntp letterlijk is en de * aan het einde staat. Een regel zoals deze verleent echter niet wat u beoogde:

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

app-* is een patroon in het midden van een argument. sudo-rs breidt dit niet uit, waardoor de regel systemctl restart app-api niet dekt en sudo het commando weigert. Twee commando's vertellen u de waarheid over elke regel op uw eigen server: sudo -l -U deploy, uitgevoerd als root, toont wat dat account daadwerkelijk mag uitvoeren, en sudo visudo -c vertelt u of het bestand überhaupt correct wordt geparseerd. Voer deze uit voordat u willekeurig wijzigingen aanbrengt.

De wildcard-regel was altijd een beveiligingslek

Onder de oorspronkelijke sudo worden de argumenten die u typt samengevoegd tot één tekenreeks en vergeleken met de argumentreeks van de regel via een glob. Een glob komt overeen met witruimte. Dat is het onderdeel dat bijna iedereen over het hoofd ziet.

De documentatie van sudo-rs geeft het duidelijkste voorbeeld. Een regel van /bin/rm *.txt staat ook sudo rm -rf /home .txt toe, omdat de ene * de -rf /home opslokt en de samengevoegde tekenreeks nog steeds eindigt op .txt. De regel wordt gelezen als "alleen tekstbestanden". Het betekent "alle argumenten, zolang de regel maar eindigt op .txt".

Hetzelfde geldt voor het systemctl-voorbeeld. Omdat de argumenten als één samengevoegde tekenreeks worden vergeleken, komt een afsluitend patroon ook overeen met alles wat u erachter plaatst; dus restart app-* dekt restart app-api plus alle verdere argumenten die de aanroeper toevoegt. Een patroon binnen een argument verraadt de argumenten eromheen, en argumenten bepalen de kracht van een commando. sudo-rs weigert deze constructie in plaats van te proberen deze veilig te maken, omdat er geen veilige algemene vorm van bestaat.

Vervang het wildcard-teken door een expliciete lijst met commando's

De meeste wildcard-regels bestaan omdat iemand geen vier regels wilde typen. Typ de vier regels.

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

Zorg voor het juiste pad. Een regel die /bin/systemctl benoemt op een systeem waar het binaire bestand /usr/bin/systemctl is, komt nooit overeen. De foutmelding lijkt identiek aan een rechtenprobleem. Bevestig dit met command -v systemctl en plak de uitvoer.

Plaats de regel in een eigen drop-in bestand in plaats van in /etc/sudoers, zodat een pakket-upgrade uw aanpassing niet overschrijft:

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

Geef het bestand een naam zonder punt en zonder afsluitende tilde. De originele sudo negeert bestanden in sudoers.d waarvan de naam een punt bevat. Daarom is 90-deploy.conf een klassieke stille no-op, en het volgen van de conventie kost niets.

Gebruik een wrapper die eigendom is van root wanneer de lijst lang wordt

Wanneer de toegestane set te groot is om op te sommen, verplaatst u de beslissing uit sudoers naar een klein programma waarvan root de eigenaar is.

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

De sudoers-kant benoemt vervolgens één commando:

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

De afsluitende * is hier acceptabel omdat het script, en niet sudo, bepaalt wat is toegestaan. Dat geldt alleen zolang het script eigendom is van root en door niemand anders kan worden gewijzigd. Als deploy naar het bestand kan schrijven, kan deploy de inhoud vervangen en alles als root uitvoeren, wat erger is dan de wildcard-regel die u heeft verwijderd. Controleer de modus met ls -l, en als de uitvoer niet direct duidelijk voor u is, kost het lezen van de drwxr-xr-x rechtenreeks vijf minuten om te leren. Dezelfde regel geldt voor de map: /usr/local/sbin mag ook niet schrijfbaar zijn voor het account, omdat een schrijfbare map betekent dat het bestand in zijn geheel kan worden vervangen.

Geef de taak een eigen account in plaats van een sudo-regel

De betere vraag is vaak waarom het commando überhaupt root-rechten nodig heeft. Een service die onder een eigen gebruiker draait, kan door die gebruiker worden beheerd zonder dat er een sudoers-regel aan te pas komt. Voor systemd-units delegeert systemd die beslissing al aan polkit, waardoor een regel één unit en één operator kan specificeren:

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;
    }
});

Sla dit op als /etc/polkit-1/rules.d/50-app-api.rules en deploy kan systemctl restart app-api uitvoeren zonder enige sudo-toegang. Test dit vanuit exact dezelfde context als waar het gebruikt zal worden; een regel die werkt in uw SSH-sessie moet ook vanuit cron worden bevestigd voordat u erop vertrouwt. Hoe dan ook, het account dat het werk uitvoert, moet uitsluitend voor dat doel bestaan. Dit is hetzelfde argument als achter gebruikersaccounts met minimale rechten op een VPS.

Wat sudo-rs nog meer weglaat

sudo -E is niet geïmplementeerd. Benoem de variabelen die u nodig heeft met Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY", en houd er rekening mee dat env_reset altijd is ingeschakeld, waardoor alles wat niet wordt behouden, wordt gewist.

Centrale opslag van sudoers in LDAP is verwijderd. sudoers.ldap en cvtsudoers zijn niet geïmplementeerd en het sudo-ldap-pakket is verwijderd in 26.04. LDAP-authenticatie via PAM of SSSD werkt nog steeds. Het is het beleid-in-een-directory-gedeelte dat buiten de scope valt.

INTERCEPT, dat probeerde shell-escapes vanuit een toegestaan commando te voorkomen, is niet geïmplementeerd. Het hield sowieso geen stand tegen een vastberaden gebruiker. Als een regel iemand toestaat een editor of interpreter als root uit te voeren, hebben zij root-rechten, en geen enkele sudo-optie verandert dat.

Sessie-opname is niet geïmplementeerd, dus er is geen I/O-logboek en geen sudoreplay. Logging gaat uitsluitend naar syslog, en er is geen logfile-optie om dit naar een andere locatie om te leiden, dus sudo-berichten komen terecht waar uw systeem syslog al naartoe stuurt.

Moet u terugschakelen naar sudo.ws?

Dat kan, en gedurende de 26.04-cyclus blijft het origineel om precies deze reden beschikbaar als pakket.

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

Kopieer de exacte paden uit de --config-output in plaats van vanaf deze pagina, aangezien dat de lijst is die uw eigen systeem accepteert. Teruggaan naar sudo-rs betekent later dat u de alternative instelt op het pad naar het sudo-rs-binary uit diezelfde lijst.

Houd een tweede SSH-sessie open, ingelogd en inactief, voordat u wijzigingen aanbrengt die sudo beïnvloeden. Een sudoers-bestand dat niet kan worden geparseerd, of een alternative die verwijst naar een binary die niet is geïnstalleerd, kan ertoe leiden dat u op een externe server geen root-rechten meer kunt verkrijgen. Deze gewoonte hoort bij alles wat u doet tijdens de eerste tien minuten op een nieuwe VPS.

Beschouw het terugschakelen als een tijdelijke maatregel, niet als een definitieve oplossing. Het geeft u een week de tijd om de regels correct te herschrijven, en die herschrijving is op zichzelf de moeite waard, omdat elke wildcard-regel die u verwijdert meer rechten verleende dan de auteur ervan had beoogd.

FAQ

Waarom werkt mijn sudoers-wildcardregel niet meer op Ubuntu 26.04?

Omdat Ubuntu 26.04 LTS sudo-rs als standaard sudo gebruikt, en sudo-rs ondersteunt geen wildcardpatronen binnen de argumenten van een commando. Het staat een wildcard toe in de bestandsnaam van het commando, "" om geen argumenten aan te duiden, en een enkele * als laatste argument. Een regel zoals /usr/bin/systemctl restart app-* plaatst een patroon midden in een argument; hierdoor wordt er niets toegestaan en wordt het commando geweigerd. Voer sudo -l -U deploy uit als root om te zien welke rechten het account daadwerkelijk heeft, en vervang de regel vervolgens door de exacte commando's of door een wrapper-script dat eigendom is van root.

Hoe schakel ik terug naar de originele sudo op Ubuntu 26.04?

De originele versie wordt geleverd in het sudo-pakket, waarvan de binaries het achtervoegsel .ws dragen. Installeer deze met sudo apt install sudo en wijs vervolgens de alternative ernaar met sudo update-alternatives --set sudo /usr/bin/sudo.ws. Voer eerst update-alternatives --config sudo uit om de exacte paden te zien die uw systeem aanbiedt, en houd een tweede SSH-sessie open terwijl u de wijziging doorvoert. Dit brengt sudo-ldap niet terug, aangezien dit uit 26.04 is verwijderd, ongeacht welke implementatie u kiest.

Leest sudo-rs hetzelfde /etc/sudoers bestand?

Ja. sudo-rs leest /etc/sudoers en de aanvullende bestanden in /etc/sudoers.d/, met dezelfde syntaxis voor gebruikers, groepen, aliassen, run-as-specificaties en de NOPASSWD-tag. Het implementeert een subset van de sudoers-taal; de verschillen uiten zich dus in constructies die ontbreken in plaats van constructies die afwijkend gedrag vertonen. Bewerk met sudo visudo en verifieer met sudo visudo -c voordat u uw sessie afsluit.

Wat vervangt sudo -E in sudo-rs?

sudo -E is niet geïmplementeerd en werd in de originele sudo al afgeraden, omdat het meegeven van een omgeving die de aanroeper beheert aan een root-proces een bekende methode is om het gedrag van dat proces te beïnvloeden. Benoem in plaats daarvan de variabelen die u daadwerkelijk nodig heeft in sudoers, met een regel zoals Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". env_reset staat altijd aan in sudo-rs en kan niet worden uitgeschakeld, dus elke variabele die u niet behoudt, wordt gewist.