sudo-rs sa Ubuntu 26.04: Ano ang Nagbago sa sudoers

Mga pagbabago ng sudo-rs sa Ubuntu

Ang Ubuntu 26.04 LTS ay naglalabas ng sudo-rs bilang default na sudo, kaya sa isang bagong server, pinapatakbo ng sudo command ang Rust reimplementation sa halip na ang orihinal na C program. Patuloy na gagana nang eksakto tulad ng dati ang karamihan sa sudoers files. Ang nagdudulot ng problema ay ang rule na may wildcard sa loob ng mga argument ng command, dahil hindi tinutugma ng sudo-rs ang mga glob pattern sa text ng argument.

Unang ginawa ng Ubuntu 25.10 ang paglipat, at ipinagpatuloy ito ng 26.04 LTS. Hindi apektado ang Ubuntu 24.04 LTS dahil pinipili pa rin nito ang orihinal na sudo maliban kung mano-mano mong i-install ang sudo-rs. Mahalaga ito kapag nag-upgrade ka mula Ubuntu 24.04 papuntang 26.04, o kapag nag-set up ka ng bagong server gamit ang mas bagong release. Kung gumagamit ka rin ng interim releases, ipinapaliwanag ng pagkakaiba ng LTS at interim Ubuntu releases sa isang server kung aling machine ang unang makakatanggap ng ganitong pagbabago.

Tingnan kung aling sudo ang aktuwal na pinapatakbo ng server

Huwag itong tukuyin batay sa release number. Tanungin ang machine.

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

Mas pagkatiwalaan ang sudo --version sa sarili mong box kaysa sa anumang version table sa internet, kasama ang pahinang ito. Ang update-alternatives --config sudo ang kabilang bahagi ng sagot: inililista nito ang bawat naka-install na provider ng /usr/bin/sudo at minamarkahan kung alin ang napili. Hindi nangangahulugang napili ang isang package dahil naka-install ito, kaya basahin ang selection, hindi ang package list.

Parehong packaged ang dalawang implementation habang isinasagawa ang transition. Ang Rust implementation ay sudo-rs, na may version na 0.2.13 sa 26.04 noong August 2026. Ang orihinal, na pinananatili ni Todd C. Miller, ay packaged bilang sudo.ws, at may .ws suffix ang mga program nito: sudo.ws at visudo.ws.

Bakit lumipat ang Ubuntu sa sudo-rs

setuid root ang sudo. Maaaring simulan ito ng sinumang user sa server, at nagsisimula ito nang may buong privilege. Kaya ang memory bug sa loob nito ay maaaring maging local root exploit. Ganoon mismo ang CVE-2021-3156: isang heap buffer overflow na maaaring maabot ng sinumang local user. Nanatili ito sa released code nang humigit-kumulang sampung taon. Nahuhuli ng Rust ang ganitong uri ng bug sa compile time. Ito ang pangunahing dahilan ng rewrite.

Ang ikalawang dahilan ay ang scope, at ito ang may direktang epekto sa iyong config. Nakapagdagdag ang orihinal na sudo ng maraming feature sa loob ng tatlong dekada. Bawat feature ay dagdag na code na tumatakbo bilang root. Sadyang subset lamang ang ini-implement ng sudo-rs. Hindi isinama ang mga feature na itinuring ng mga author na niche o aktuwal na nakapipinsala. Kaya maaaring wala na lamang ang isang sudoers construct na maraming taon nang gumagana. Kabilang dito ang iyong wildcard rule.

Inaalis ng memory safety ang isang klase ng bug. Hindi nito ginagawang walang bug ang isang program. Naglabas din ang sudo-rs ng sarili nitong security fixes mula nang maging default ito. I-patch ito gaya ng iba pang software.

Aling sudoers rules ang gumagana pa rin

Pareho pa rin ang file. Binabasa ng sudo-rs ang /etc/sudoers at ang mga drop-in file sa /etc/sudoers.d/. Sinusuportahan nito ang karaniwang ginagamit ng server operator:

• deploy ALL=(ALL:ALL) ALL at mga anyong pang-group gaya ng %sudo ALL=(ALL:ALL) ALL
• ang mga tag na NOPASSWD: at PASSWD:
• User_Alias, Runas_Alias, Host_Alias, at Cmnd_Alias
• isang command na may eksaktong listahan ng argumento, halimbawa /usr/bin/systemctl restart app-api
• isang command na sinusundan ng "", na nagpapahintulot sa command lamang kapag walang anumang argumento
• isang command na sinusundan ng * bilang huling argumento nito, na nagpapahintulot sa anumang kasunod na argumento
• isang directory path na nagtatapos sa /, na nagpapahintulot sa anumang command sa directory na iyon
• ! upang mag-alis ng command mula sa isang listahan
• isang kapaki-pakinabang na subset ng Defaults, kabilang ang secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw, at use_pty

Magkaiba ang behavior ng dalawang default at maaari itong pagmulan ng kalituhan. Hindi maaaring i-off ang env_reset sa sudo-rs: palagi itong naka-on. Naka-on naman bilang default ang use_pty, kaya tumatakbo ang command sa sarili nitong pseudo-terminal.

Bakit hindi na tumugma ang wildcard sudoers rule mo

Pinapayagan pa rin ang wildcards sa isang bahagi: sa file name ng command. Ang rule na %ops ALL = /sbin/fsck* ay nagpapahintulot pa rin sa sudo fsck at sudo fsck_exfat, dahil bahagi ng path ang * na itinutugma sa filesystem.

Sa loob ng argument list, dalawang special form lamang ang tinatanggap ng sudo-rs, at pattern ang alinman sa mga ito. Ang "" ay nangangahulugang walang arguments. Ang * sa pinakahuli ay nangangahulugang anumang kasunod na arguments. Literal na text ang paghahambingan para sa lahat ng iba pang arguments. Kaya wasto ang %ops ALL = /sbin/service ntp *, dahil literal ang ntp at nasa hulihan ang *. Ngunit walang ibinibigay na access na nilalayon mo ang ganitong rule:

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

Pattern ang app-* na nasa gitna ng isang argument. Hindi ito ine-expand ng sudo-rs, kaya hindi saklaw ng rule ang systemctl restart app-api at nirereject ni sudo ang command. Dalawang command ang makapagsasabi sa iyo ng aktuwal na kalagayan ng anumang rule sa sarili mong server: ang sudo -l -U deploy, na pinapatakbo bilang root, ay nagpapakita kung ano talaga ang maaaring patakbuhin ng account na iyon, at ipinapaalam ng sudo visudo -c kung valid ang parsing ng file. Patakbuhin ang mga ito bago ka magsimulang mag-edit nang basta-basta.

Ang wildcard rule ay palaging may butas

Sa orihinal na sudo, pinagsasama ang mga argument na tina-type mo sa isang string at itinutugma ito sa argument string ng rule gamit ang glob. Tinutugma ng glob ang whitespace. Ito ang bahaging halos lahat ay hindi napapansin.

Nagbibigay ang documentation ng sudo-rs ng pinakamalinaw na demonstration. Pinapahintulutan din ng rule na /bin/rm *.txt ang sudo rm -rf /home .txt, dahil nilalamon ng nag-iisang * ang -rf /home at nagtatapos pa rin sa .txt ang pinagsamang string. Ang pagkakasulat ng rule ay “mga text file lang.” Ang aktuwal na ibig sabihin nito ay “anumang argument, basta nagtatapos sa .txt ang linya.”

Ganoon din sa halimbawa ng systemctl. Dahil inihahambing ang mga argument bilang isang pinagsamang string, tumutugma rin ang pattern sa hulihan sa anumang idinagdag mo pagkatapos nito. Kaya saklaw ng restart app-* ang restart app-api at ang anumang karagdagang argument na idinagdag ng caller. Kapag may pattern sa loob ng isang argument, nalalantad ang mga argument sa paligid nito, at nasa mga argument ang kapangyarihan ng command. Tinatanggihan ng sudo-rs ang ganitong construct sa halip na subukang gawing ligtas ito, dahil walang pangkalahatang anyo nito na ligtas.

Palitan ang wildcard ng tahasang listahan ng command

Umiiral ang karamihan sa wildcard rule dahil ayaw ng gumawa na mag-type ng apat na linya. I-type ang apat na linya.

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

Tiyaking tama ang path. Hindi kailanman magmamatch ang rule na tumutukoy sa /bin/systemctl sa system kung saan ang binary ay nasa /usr/bin/systemctl, at kapareho ng permissions problem ang lalabas na failure. Kumpirmahin ito gamit ang command -v systemctl at i-paste ang output nito.

Ilagay ang rule sa sarili nitong drop-in file sa halip na sa /etc/sudoers, para hindi sumalungat ang package upgrade sa iyong edit:

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

Pangalanan ang file nang walang tuldok at walang trailing tilde. Hindi pinapansin ng orihinal na sudo ang mga file sa sudoers.d na may tuldok sa pangalan, kaya ang 90-deploy.conf ay isang karaniwang tahimik na walang-epektong configuration, at walang gastos ang pagsunod sa convention.

Gumamit ng wrapper na pagmamay-ari ng root kapag mahaba ang listahan

Kapag masyadong malaki ang allowed set para ilista, ilipat ang decision mula sa sudoers papunta sa isang maliit na program na pagmamay-ari ng root.

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

Sa panig ng sudoers, isang command na lang ang ilista:

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

Katanggap-tanggap dito ang nakadugtong na * dahil ang script, hindi ang sudo, ang nagpapasya kung ano ang pinapayagan. Nalalapat lang ito habang pagmamay-ari ng root ang script at walang ibang account ang maaaring magsulat dito. Kung maaaring magsulat ang deploy sa file, maaaring palitan ng deploy ang laman nito at magpatakbo ng kahit ano bilang root. Mas masama ito kaysa sa wildcard rule na inalis mo. Suriin ang mode gamit ang ls -l. Kung hindi malinaw sa iyo ang output, limang minuto lang ang kailangan para matutong basahin ang permission string na drwxr-xr-x sa permission string na drwxr-xr-x. Saklaw din ng parehong rule ang directory: hindi rin dapat maaaring sulatan ng account ang /usr/local/sbin, dahil kapag writable ang directory, maaaring palitan nang buo ang file.

Bigyan ng sariling account ang job sa halip na sudo rule

Mas magandang itanong kung bakit kailangan pa ng command ang root. Ang service na tumatakbo gamit ang sarili nitong user ay maaaring i-manage ng user na iyon, kaya walang kailangang sudoers line. Para sa system units, ang systemd na ang nagde-delegate ng desisyong ito sa polkit, kaya maaaring tumukoy ang isang rule sa isang unit at isang operator:

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

I-save ito bilang /etc/polkit-1/rules.d/50-app-api.rules, at maaaring patakbuhin ng deploy ang systemctl restart app-api nang walang sudo. I-test ito mula sa eksaktong context na gagamit nito, dahil kailangang kumpirmahin sa cron ang isang rule na gumagana sa iyong SSH session bago ka umasa rito. Sa alinmang paraan, dapat umiiral ang account na gumagawa ng trabaho para sa trabahong iyon lamang. Ito ang parehong prinsipyo sa likod ng mga user account na may least privilege sa isang VPS.

Ano pa ang hindi kasama sa sudo-rs

Hindi na-implement ang sudo -E. Gamitin ang Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" upang pangalanan ang mga variable na kailangan mo, at tandaan na palaging naka-on ang env_reset, kaya nililinis ang anumang hindi pinapanatili.

Wala na ang central sudoers storage sa LDAP. Hindi na-implement ang sudoers.ldap at cvtsudoers, at inalis ang sudo-ldap package sa 26.04. Gumagana pa rin ang LDAP authentication sa pamamagitan ng PAM o SSSD. Ang hindi kasama ay ang pag-iimbak ng policy sa isang directory.

Hindi na-implement ang INTERCEPT, na nagtangkang pigilan ang shell escapes mula sa isang pinayagang command. Hindi rin ito sapat laban sa determinadong user. Kung pinapayagan ng rule ang isang tao na magpatakbo ng editor o interpreter bilang root, mayroon na siyang root access, at walang sudo option ang makakapagpabago nito.

Hindi na-implement ang session recording, kaya walang I/O log at walang sudoreplay. Sa syslog lamang ipinapadala ang logging, at walang logfile option para i-redirect ito sa ibang lokasyon. Dahil dito, napupunta ang sudo messages kung saan man ipinapadala ng system mo ang syslog.

Bumalik sa sudo.ws?

Maaari kang bumalik, at sa 26.04 cycle ay mananatiling naka-package ang orihinal na bersyon para mismo sa dahilang ito.

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

Kopyahin ang eksaktong paths mula sa output ng --config sa halip na mula sa page na ito, dahil iyon ang listahang tatanggapin ng sarili mong system. Kung babalik ka sa sudo-rs sa ibang pagkakataon, itakda ang alternative sa binary path ng sudo-rs mula sa parehong listahan.

Panatilihing bukas ang isang pangalawang SSH session, naka-login at idle, bago ka gumawa ng anumang makaaapekto sa sudo. Kapag hindi ma-parse ang sudoers file, o nakaturo ang isang alternative sa binary na hindi naka-install, maaari kang mawalan ng paraan para maging root sa remote box. Kasama ang kaugaliang ito sa lahat ng iba pang ginagawa mo sa unang sampung minuto sa isang bagong VPS.

Ituring ang pagbabalik bilang deadline, hindi bilang fix. Bibigyan ka nito ng isang linggo para maayos na i-rewrite ang mga rule, at sulit gawin ang rewrite kahit wala ang isyung ito, dahil bawat wildcard rule na dine-delete mo ay nagbibigay ng mas malawak na access kaysa sa ipinapalagay ng gumawa nito.

FAQ

Bakit hindi na gumagana ang sudoers wildcard rule ko sa Ubuntu 26.04?

Dahil ginagamit ng Ubuntu 26.04 LTS ang sudo-rs bilang default na sudo, at hindi tinutugma ng sudo-rs ang wildcard pattern sa loob ng mga argument ng command. Pinapayagan nito ang wildcard sa file name ng command, ang "" para mangahulugang walang argument, at isang * bilang huling argument. Ang rule na gaya ng /usr/bin/systemctl restart app-* ay naglalagay ng pattern sa gitna ng isang argument, kaya wala itong ibinibigay na pahintulot at tinatanggihan ang command. Patakbuhin ang sudo -l -U deploy bilang root upang makita ang aktuwal na access ng account, pagkatapos ay palitan ang rule ng mga eksaktong command o ng root-owned wrapper script.

Paano ako babalik sa orihinal na sudo sa Ubuntu 26.04?

Ang orihinal ay naka-package bilang sudo.ws. I-install ito gamit ang sudo apt install sudo.ws, pagkatapos ay ituro rito ang alternative gamit ang sudo update-alternatives --set sudo /usr/bin/sudo.ws. Patakbuhin muna ang update-alternatives --config sudo upang makita ang eksaktong path na iniaalok ng system, at panatilihing bukas ang ikalawang SSH session habang binabago mo ito. Hindi nito ibinabalik ang sudo-ldap, na inalis sa 26.04 anuman ang implementation na piliin mo.

Pareho bang /etc/sudoers file ang binabasa ng sudo-rs?

Oo. Binabasa ng sudo-rs ang /etc/sudoers at ang mga drop-in file sa ilalim ng /etc/sudoers.d/, gamit ang parehong syntax para sa users, groups, aliases, run-as specifications, at NOPASSWD tag. Subset lamang ng sudoers language ang ipinapatupad nito, kaya lumilitaw ang mga pagkakaiba bilang mga construct na wala, sa halip na mga construct na may ibang behavior. Mag-edit gamit ang sudo visudo, pagkatapos ay mag-verify gamit ang sudo visudo -c bago isara ang session.

Ano ang kapalit ng sudo -E sa sudo-rs?

Hindi ipinapatupad ang sudo -E. Hindi na rin ito hinihikayat sa orihinal na sudo dahil ang pagbibigay sa isang root process ng environment na kontrolado ng caller ay isang kilalang paraan upang baguhin ang behavior ng process na iyon. Tukuyin sa sudoers ang mga variable na talagang kailangan mo, gamit ang isang linya gaya ng Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". Palaging naka-enable ang env_reset sa sudo-rs at hindi ito maaaring i-disable, kaya nililinis ang bawat variable na hindi mo pinapanatili.