sudo-rs op Ubuntu: wat verandert er voor sudoers?

Wat sudo-rs verandert op 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 exact zo werken als voorheen. 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 de tekst van argumenten.

Ubuntu 25.10 maakte als eerste de overstap en 26.04 LTS heeft dit behouden. Ubuntu 24.04 LTS is niet getroffen, aangezien dit nog steeds de oorspronkelijke sudo selecteert, 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 bouwt op de nieuwere release. Als u ook de tussenliggende releases draait, 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 is de andere helft van het antwoord: dit commando somt elke geïnstalleerde aanbieder van /usr/bin/sudo op en markeert de geselecteerde versie. Dat een pakket is geïnstalleerd, betekent niet dat het is geselecteerd; lees daarom de selectie, niet de pakketlijst.

Beide implementaties zijn tijdens de overgang als pakket beschikbaar. 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 verpakt als sudo.ws en de bijbehorende programma's hebben een .ws-achtervoegsel: sudo.ws en visudo.ws.

Waarom Ubuntu is overgestapt op sudo-rs

sudo is setuid root. Elke gebruiker op de server kan het starten, en het start met volledige rechten. Een geheugenfout in de code is daarom een lokaal root-lek. CVE-2021-3156 was precies dat: een heap buffer overflow die door elke lokale gebruiker kon worden aangeroepen, en deze zat ongeveer tien jaar in de uitgebrachte code. Rust voorkomt dit type fout tijdens het compileren, wat het voornaamste argument is voor de herschrijving.

De tweede reden is de scope, en dit is het punt dat uw configuratie beïnvloedt. De originele sudo heeft in drie decennia een uitgebreide set functies verzameld, en elke functie betekent meer code die als root draait. sudo-rs implementeert bewust een subset. Alles wat de auteurs als niche of 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 niet foutloos, en sudo-rs heeft sinds het de standaard werd zelf ook beveiligingsupdates uitgebracht. Patch het dus zoals elk ander pakket.

Welke sudoers-regels werken nog

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

• deploy ALL=(ALL:ALL) ALL, en groepsvormen zoals %sudo ALL=(ALL:ALL) ALL
• de NOPASSWD: en PASSWD: tags
• 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 alle volgende argumenten toestaat
• een mappad eindigend op /, wat elk commando in die map toestaat
• ! om een commando uit een lijst te verwijderen
• een nuttige 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 verrassen gebruikers. env_reset kan niet worden uitgeschakeld in sudo-rs: het staat altijd aan. use_pty staat standaard aan, waardoor het commando in zijn eigen pseudo-terminal wordt uitgevoerd.

Waarom uw wildcard-regel in sudoers niet meer matcht

Wildcards zijn op één plek nog steeds toegestaan: in de bestandsnaam van het commando. Een regel als %ops ALL = /sbin/fsck* staat sudo fsck en sudo fsck_exfat nog steeds toe, omdat de * deel uitmaakt 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 niets van 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 argumenttekenreeks 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 zijn waar de kracht van een commando schuilt. sudo-rs weigert de 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 dat het pad correct is. Een regel die /bin/systemctl benoemt op een systeem waar het binaire bestand /usr/bin/systemctl is, komt nooit overeen. De foutmelding lijkt dan identiek aan een probleem met toegangsrechten. Bevestig dit met command -v systemctl en plak de uitvoer daarvan.

Plaats de regel in een eigen drop-in bestand in plaats van in /etc/sudoers, zodat een pakket-upgrade uw wijziging 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, waardoor 90-deploy.conf een klassieke stille no-op is. Het aanhouden van deze 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, 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 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 schrijfbaar directory 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 en vereist geen sudoers-regel. 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 vorm van sudo. Test dit vanuit de exacte context waarin het gebruikt zal worden, omdat een regel die in uw SSH-sessie werkt, eerst vanuit cron moet worden bevestigd voordat u erop vertrouwt. Hoe dan ook, het account dat het werk uitvoert, moet uitsluitend voor dat werk bestaan; dit is hetzelfde argument als bij accounts met minimale rechten op een VPS.

Wat sudo-rs verder weglaat

sudo -E is niet geïmplementeerd. Benoem de variabelen die u nodig heeft in plaats daarvan met Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY", en onthoud 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 in 26.04 verwijderd. LDAP-authenticatie via PAM of SSSD werkt nog steeds. Het beleid-in-een-directory-gedeelte valt buiten de scope.

INTERCEPT, dat probeerde shell-escapes vanuit een toegestaan commando te voorkomen, is niet geïmplementeerd. Het bood sowieso geen bescherming tegen een vastberaden gebruiker. Als een regel iemand toestaat een editor of interpreter als root uit te voeren, dan heeft diegene 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. Logboekregistratie vindt uitsluitend plaats via syslog, en er is geen logfile-optie om dit naar een andere locatie om te leiden, waardoor sudo-berichten terechtkomen op de plek waar uw systeem syslog-berichten al naartoe stuurt.

Moet u terugschakelen naar sudo.ws?

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

sudo apt install sudo.ws
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 het alternatief instelt op het sudo-rs binaire pad 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 alternatief dat verwijst naar een binair bestand dat niet is geïnstalleerd, kan ertoe leiden dat u geen root-rechten meer kunt verkrijgen op een externe server. Die gewoonte hoort bij alles wat u doet in de eerste tien minuten op een nieuwe VPS.

Beschouw het terugschakelen als een deadline in plaats van als een oplossing. Het geeft u een week de tijd om de regels correct te herschrijven, en dat herschrijven is op zichzelf de moeite waard, omdat elke wildcard-regel die u verwijdert meer rechten verleende dan de auteur ervan vermoedde.

FAQ

Waarom werkt mijn sudoers wildcard-regel niet meer op Ubuntu 26.04?

Omdat Ubuntu 26.04 LTS sudo-rs als standaard sudo gebruikt, en sudo-rs ondersteunt geen wildcard-patronen 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?

Het origineel is verpakt als sudo.ws. Installeer dit met sudo apt install sudo.ws en wijs de alternative vervolgens daarnaar met sudo update-alternatives --set sudo /usr/bin/sudo.ws. Voer eerst update-alternatives --config sudo uit om de exacte paden te lezen 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 drop-in bestanden onder /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, dus de verschillen uiten zich in constructies die ontbreken in plaats van constructies die zich anders gedragen. Bewerk met sudo visudo en verifieer vervolgens met sudo visudo -c voordat u uw sessie sluit.

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 manier is om het gedrag van dat proces te wijzigen. 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, waardoor elke variabele die u niet behoudt, wordt gewist.