Ubuntu 26.04 sudo-rs geçişi ve sudoers kuralları

Ubuntu üzerinde sudo-rs değişiklikleri

Ubuntu 26.04 LTS, varsayılan sudo olarak sudo-rs ile gelir; bu nedenle yeni kurulmuş bir sunucuda çalıştırılan sudo komutu, orijinal C programı yerine Rust ile yeniden yazılmış sürümü çalıştırır. Çoğu sudoers dosyası olduğu gibi çalışmaya devam eder. Komut argümanları içinde joker karakter (wildcard) içeren kurallar çalışmaz, çünkü sudo-rs argüman metni üzerinde glob desen eşleştirmesi yapmaz.

Ubuntu 25.10 bu değişikliği ilk yapan sürümdür ve 26.04 LTS bu yapıyı korumuştur. Ubuntu 24.04 LTS bu durumdan etkilenmez; sudo-rs elle kurulmadığı sürece orijinal sudo kullanılmaya devam edilir. Bu durum, Ubuntu 24.04 sürümünden 26.04 sürümüne yükseltme yaptığınızda veya daha yeni bir sürüm üzerinde yeni bir sunucu kurduğunuzda önem kazanır. Ara sürümleri de kullanıyorsanız, LTS ve ara Ubuntu sürümlerinin sunucu tarafındaki farkları başlıklı yazı, bu tür değişikliklerin hangi makineye ilk olarak yansıdığını açıklar.

Sunucunuzun hangi sudo sürümünü çalıştırdığını kontrol edin

Bunu sürüm numarasından yola çıkarak belirlemeyin. Makineye sorun.

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

Kendi sunucunuzdaki sudo --version çıktısına, bu sayfa dahil internetteki herhangi bir sürüm tablosundan daha fazla güvenin. update-alternatives --config sudo, cevabın diğer yarısıdır: yüklü olan tüm /usr/bin/sudo sağlayıcılarını listeler ve seçili olanı işaretler. Bir paketin yüklü olması, onun seçili olduğu anlamına gelmez; bu nedenle paket listesini değil, seçim durumunu okuyun.

Geçiş sürecinde her iki uygulama da paketlenmektedir. Rust tabanlı olan sudo-rs, Ağustos 2026 itibarıyla 26.04 sürümünde 0.2.13 versiyonundadır. Todd C. Miller tarafından sürdürülen orijinal sürüm ise sudo.ws olarak paketlenmiştir ve programları .ws sonekini taşır: sudo.ws ve visudo.ws.

Ubuntu neden sudo-rs'e geçti

sudo, setuid root olarak çalışır. Sunucudaki herhangi bir kullanıcı tarafından başlatılabilir ve tam yetkilerle çalışır; bu nedenle içindeki bir bellek hatası, yerel bir root istismarıdır. CVE-2021-3156 tam olarak buydu: herhangi bir yerel kullanıcı tarafından erişilebilen bir yığın (heap) arabellek taşmasıydı ve yaklaşık on yıl boyunca yayınlanmış kod içerisinde varlığını sürdürdü. Rust, bu tür hataları derleme zamanında yakalar; yeniden yazımın temel gerekçesi de budur.

İkinci neden kapsamdır ve bu durum yapılandırmanızı doğrudan etkiler. Orijinal sudo, otuz yıl boyunca geniş bir özellik seti topladı ve her özellik, root yetkisiyle çalışan daha fazla kod anlamına gelir. sudo-rs, bilinçli olarak bu özelliklerin bir alt kümesini uygular. Yazarlarının niş veya aktif olarak zararlı bulduğu her şey dışarıda bırakıldı; bu nedenle yıllardır çalışan bir sudoers yapısı artık mevcut olmayabilir. Joker karakter kuralınız da bunlardan biridir.

Bellek güvenliği, bir hata sınıfını ortadan kaldırır. Bu, bir programı hatasız yapmaz ve sudo-rs, varsayılan hale geldiğinden bu yana kendi güvenlik yamalarını yayınlamıştır. Diğer her şey gibi onu da yamalayın.

Hangi sudoers kuralları çalışmaya devam eder

Dosya aynı dosyadır. sudo-rs, /etc/sudoers dosyasını ve /etc/sudoers.d/ içindeki ek yapılandırma dosyalarını okur; bir sunucu operatörünün yazdığı olağan kurallar desteklenir:

• deploy ALL=(ALL:ALL) ALL ve %sudo ALL=(ALL:ALL) ALL gibi grup biçimleri
• NOPASSWD: ve PASSWD: etiketleri
• User_Alias, Runas_Alias, Host_Alias ve Cmnd_Alias
• tam argüman listesi içeren bir komut, örneğin /usr/bin/systemctl restart app-api
• komutu yalnızca hiçbir argüman olmadan çalıştıran, komutu takip eden ""
• son argüman olarak * ile biten ve takip eden tüm argümanlara izin veren bir komut
• o dizindeki tüm komutlara izin veren, / ile biten bir dizin yolu
• bir listeden komut çıkarmak için !
• secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw ve use_pty dahil olmak üzere Defaults öğesinin kullanışlı bir alt kümesi

İki varsayılan ayar farklı davranır ve kullanıcıları yanıltabilir. env_reset, sudo-rs içinde kapatılamaz: her zaman etkindir. use_pty varsayılan olarak açıktır, bu nedenle komut kendi sözde terminalinde (pseudo-terminal) çalışır.

Wildcard sudoers kuralınızın neden eşleşmeyi durdurduğu

Wildcard kullanımı yalnızca bir yerde hala izin verilen bir durumdur: komutun dosya adı. %ops ALL = /sbin/fsck* kuralı, * dosya sistemi üzerinde eşleştirilen yolun bir parçası olduğu için sudo fsck ve sudo fsck_exfat komutlarına hala izin verir.

Argüman listesi içinde sudo-rs yalnızca iki özel biçimi kabul eder ve bunların hiçbiri bir desen (pattern) değildir. "", argüman yok anlamına gelir. Sondaki bir * ise, takip eden tüm argümanlar anlamına gelir. Diğer tüm argümanlar düz metin olarak karşılaştırılır. Bu nedenle %ops ALL = /sbin/service ntp * sorunsuzdur; çünkü ntp düz metindir ve * en sondadır. Ancak aşağıdaki gibi bir kural, hedeflediğiniz hiçbir şeye izin vermez:

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

app-*, bir argümanın ortasında yer alan bir desendir. sudo-rs bunu genişletmez, bu nedenle kural systemctl restart app-api ifadesini kapsamaz ve sudo komutu reddeder. Kendi sunucunuzdaki herhangi bir kural hakkında size doğru bilgiyi iki komut verir: root olarak çalıştırılan sudo -l -U deploy, ilgili hesabın gerçekte neleri çalıştırabileceğini listeler; sudo visudo -c ise dosyanın ayrıştırılıp ayrıştırılamadığını söyler. Rastgele düzenlemeler yapmaya başlamadan önce bu komutları çalıştırın.

Wildcard kuralı her zaman bir güvenlik açığıydı

Orijinal sudo altında, yazdığınız argümanlar tek bir dizgi halinde birleştirilir ve kuralın argüman dizgisiyle bir glob (joker karakter) eşleşmesi üzerinden karşılaştırılır. Bir glob, boşluk karakterleriyle de eşleşir. Neredeyse herkesin gözden kaçırdığı nokta budur.

sudo-rs belgeleri bunun en net gösterimini sunar. /bin/rm *.txt kuralı, sudo rm -rf /home .txt komutuna da izin verir; çünkü tek bir * ifadesi -rf /home kısmını yutar ve birleştirilmiş dizgi hala .txt ile biter. Kural "yalnızca metin dosyaları" olarak okunur. Ancak gerçekte "satır .txt ile bittiği sürece herhangi bir argüman" anlamına gelir.

Aynı durum systemctl örneği için de geçerlidir. Argümanlar tek bir birleşik dizgi olarak karşılaştırıldığından, sondaki bir desen, sonuna eklediğiniz her şeyle de eşleşir; bu nedenle restart app-*, restart app-api ifadesini ve çağrıyı yapanın eklediği diğer tüm argümanları kapsar. Bir argümanın içindeki desen, çevresindeki argümanları açığa çıkarır ve bir komutun gücü argümanlarında saklıdır. sudo-rs, güvenli bir genel biçimi bulunmadığı için bu yapıyı güvenli hale getirmeye çalışmak yerine doğrudan reddeder.

Joker karakteri açık bir komut listesiyle değiştirin

Çoğu joker karakter kuralı, birilerinin dört satır yazmak istememesi nedeniyle var olur. Dört satırı da yazın.

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

Dosya yolunu doğru belirleyin. İkilik dosyanın /usr/bin/systemctl olduğu bir sistemde /bin/systemctl adını taşıyan bir kural asla eşleşmez ve bu durum bir izin sorunuyla aynı şekilde başarısız olur. command -v systemctl ile doğrulama yapın ve çıktısını buraya yapıştırın.

Kuralı /etc/sudoers dosyasına yazmak yerine kendi özel yapılandırma dosyanıza ekleyin; böylece paket yükseltmeleri sırasında yaptığınız değişiklikler geçersiz kalmaz:

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

Dosyayı isimlendirirken nokta kullanmayın ve sonuna tilde eklemeyin. Orijinal sudo, sudoers.d dizininde nokta içeren dosyaları görmezden gelir; bu nedenle 90-deploy.conf klasik bir sessiz başarısızlık örneğidir. Bu kurala uymanın size bir maliyeti yoktur.

Liste uzadığında root sahipli bir sarmalayıcı kullanın

İzin verilenler kümesi listelenemeyecek kadar büyük olduğunda, karar verme sürecini sudoers dosyasından çıkarıp root sahipli küçük bir programa taşıyın.

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

Sudoers tarafı bu durumda tek bir komutu tanımlar:

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

Buradaki sondaki * ifadesi kabul edilebilir, çünkü neye izin verileceğine sudo değil, betiğin kendisi karar verir. Bu durum yalnızca betiğin sahibi root olduğunda ve başka hiç kimse yazma yetkisine sahip olmadığında geçerlidir. Eğer deploy dosyaya yazabiliyorsa, deploy dosyanın içeriğini değiştirip root yetkileriyle herhangi bir komut çalıştırabilir; bu da kaldırdığınız joker karakter kuralından daha tehlikelidir. Dosya modunu ls -l ile kontrol edin; çıktı size açık gelmiyorsa, drwxr-xr-x izin dizgisini okumayı öğrenmek beş dakikanızı alır. Aynı kural dizin için de geçerlidir: /usr/local/sbin dizini de ilgili hesap tarafından yazılabilir olmamalıdır, çünkü yazılabilir bir dizin, dosyanın tamamen değiştirilebileceği anlamına gelir.

İşi sudo kuralı yerine kendi hesabına atayın

Daha iyi bir soru, komutun neden root yetkisine ihtiyaç duyduğudur. Kendi kullanıcısı altında çalışan bir servis, o kullanıcı tarafından yönetilebilir ve herhangi bir sudoers satırına gerek kalmaz. systemd birimleri için systemd bu kararı zaten polkit'e devreder; bu sayede bir kural, tek bir birimi ve tek bir operatörü tanımlayabilir:

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

Bunu /etc/polkit-1/rules.d/50-app-api.rules olarak kaydedin; böylece deploy, herhangi bir sudo komutuna ihtiyaç duymadan systemctl restart app-api çalıştırabilir. Testi, komutu kullanacak olan tam bağlamda gerçekleştirin; çünkü SSH oturumunuzda çalışan bir kuralın, ona güvenmeden önce cron üzerinden de çalıştığını doğrulamak gerekir. Her iki durumda da, işi yapan hesap yalnızca bu iş için var olmalıdır; bu, bir VPS üzerindeki en düşük ayrıcalıklı kullanıcı hesapları arkasındaki temel argümanla aynıdır.

sudo-rs kapsamı dışında kalan diğer özellikler

sudo -E uygulanmamıştır. İhtiyacınız olan değişkenleri bunun yerine Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" ile tanımlayın ve env_reset özelliğinin her zaman açık olduğunu unutmayın; bu nedenle saklanmayan her şey temizlenir.

LDAP üzerindeki merkezi sudoers depolaması kaldırılmıştır. sudoers.ldap ve cvtsudoers uygulanmamıştır ve sudo-ldap paketi 26.04 sürümünde çıkarılmıştır. PAM veya SSSD üzerinden LDAP kimlik doğrulaması çalışmaya devam eder. Kapsam dışında kalan kısım, dizin tabanlı ilke yönetimidir.

İzin verilen bir komuttan kabuk kaçışlarını (shell escape) engellemeye çalışan INTERCEPT uygulanmamıştır. Bu özellik zaten kararlı bir kullanıcıya karşı hiçbir zaman etkili olmamıştır. Eğer bir kural, bir kullanıcının root yetkisiyle bir düzenleyici veya yorumlayıcı çalıştırmasına izin veriyorsa, kullanıcı root yetkisine sahiptir ve hiçbir sudo seçeneği bunu değiştiremez.

Oturum kaydı uygulanmamıştır, bu nedenle I/O günlüğü ve sudoreplay özelliği bulunmamaktadır. Günlük kaydı yalnızca syslog sistemine yapılır ve bunu başka bir yere yönlendirmek için logfile seçeneği mevcut değildir; bu nedenle sudo mesajları, sisteminizin syslog kayıtlarını halihazırda gönderdiği yere ulaşır.

Tekrar sudo.ws adresine dönmeli misiniz?

Dönebilirsiniz; 26.04 döngüsü boyunca orijinal sürüm tam da bu nedenle paketlenmiş halde kalmaya devam eder.

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

--config çıktısındaki tam yolları bu sayfadan kopyalamak yerine doğrudan sisteminizden alın; çünkü sisteminizin kabul edeceği liste budur. Daha sonra tekrar sudo-rs sürümüne dönmek, alternatif ayarını aynı listedeki sudo-rs ikili dosya yoluna yönlendirmek anlamına gelir.

sudo komutunu etkileyen herhangi bir işlem yapmadan önce, oturumu açık ve boşta bekleyen ikinci bir SSH bağlantısını hazır tutun. Ayrıştırılamayan bir sudoers dosyası veya kurulu olmayan bir ikili dosyaya işaret eden bir alternatif, uzak bir sunucuda root yetkilerine erişiminizi tamamen kesebilir. Bu alışkanlık, yeni bir VPS üzerindeki ilk on dakika içinde yaptığınız diğer tüm işlemlerle birlikte uygulanmalıdır.

Geri dönüşü bir çözümden ziyade bir son tarih olarak değerlendirin. Bu işlem, kuralları düzgün bir şekilde yeniden yazmanız için size bir haftalık süre kazandırır. Bu yeniden yazma işlemi kendi başına değerlidir; çünkü sildiğiniz her joker karakterli kural, aslında yazarının farkında olduğundan daha fazla yetki tanımaktaydı.

FAQ

Ubuntu 26.04 üzerinde sudoers joker karakter kuralım neden çalışmayı durdurdu?

Ubuntu 26.04 LTS, varsayılan sudo olarak sudo-rs kullanmayı tercih eder ve sudo-rs, komut argümanları içindeki joker karakter desenlerini eşleştirmez. Sadece komutun dosya adında bir joker karaktere, argüman içermemesi için "" ifadesine ve son argüman olarak tek bir * ifadesine izin verir. /usr/bin/systemctl restart app-* gibi bir kural, desenin bir argümanın ortasında yer almasına neden olur; bu yüzden hiçbir yetki tanımlanmaz ve komut reddedilir. Hesabın gerçekte hangi yetkilere sahip olduğunu görmek için root olarak sudo -l -U deploy komutunu çalıştırın, ardından kuralı tam komutlarla veya root tarafından sahiplenilen bir sarmalayıcı (wrapper) betikle değiştirin.

Ubuntu 26.04 üzerinde orijinal sudo uygulamasına nasıl geri dönerim?

Orijinal uygulama sudo.ws paketi olarak sunulur. sudo apt install sudo.ws ile kurulumu yapın, ardından sudo update-alternatives --set sudo /usr/bin/sudo.ws ile alternatifleri bu pakete yönlendirin. Sisteminizin sunduğu tam yolları okumak için önce update-alternatives --config sudo komutunu çalıştırın ve değişiklik yaparken ikinci bir SSH oturumunu açık tutun. Bu işlem, hangi uygulamayı seçerseniz seçin 26.04 sürümünden kaldırılmış olan sudo-ldap özelliğini geri getirmez.

sudo-rs, /etc/sudoers dosyasını aynı şekilde mi okur?

Evet. sudo-rs, /etc/sudoers dosyasını ve /etc/sudoers.d/ altındaki ek yapılandırma dosyalarını; kullanıcılar, gruplar, takma adlar, çalıştırma yetkileri ve NOPASSWD etiketi için aynı sözdizimiyle okur. sudoers dilinin bir alt kümesini uyguladığı için, farklı davranan yapılardan ziyade eksik olan yapılarla karşılaşılır. Düzenleme için sudo visudo kullanın ve oturumunuzu kapatmadan önce sudo visudo -c ile doğrulama yapın.

sudo-rs içinde sudo -E yerine ne kullanılır?

sudo -E uygulanmamıştır ve orijinal sudo içinde de zaten önerilmemekteydi; çünkü root sürecine, çağıranın kontrol ettiği bir ortamı sunmak, sürecin davranışını değiştirmenin bilinen bir yoludur. Bunun yerine, sudoers içinde Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" gibi bir satırla gerçekten ihtiyaç duyduğunuz değişkenleri belirtin. env_reset özelliği sudo-rs içinde her zaman etkindir ve devre dışı bırakılamaz; bu nedenle korumadığınız her değişken temizlenir.