Bellek güvenli sudo uygulaması sudo-rs’in ilk kararlı sürümü yayımlandı
(memorysafety.org)- Yetki sınırları arasında geçiş için kullanılan sudo’nun Rust ile yeniden uygulanmış hali olan sudo-rs, ilk kararlı sürümüyle yayımlandı
- Orijinal sudo’daki güvenlik hatalarının yaklaşık üçte birinin bellek yönetimi sorunları olduğu tahmini, Rust ile yeniden yazımın temel gerekçesi oldu
- sudo-rs, daha az kullanılan özellikleri dışarıda bırakarak saldırı yüzeyini azalttı; test paketi, orijinal sudo’daki hataları bulmak için de kullanıldı
- Wolfi Linux OS halihazırda sudo-rs’i içeriyor; Chainguard, güvenlik açısından kritik araçlardaki iyileştirmelerin sektör genelinde etki yaratabileceğini düşünüyor
- Dış güvenlik denetiminin Eylül 2023’te başlaması planlanıyor; sonraki çalışmalar, kurumsal özelliklere odaklanan Milestone 4 aşamasına geçecek
Rust ile yeniden uygulanmış sudo-rs
- Prossimo, sudo-rs’in ilk kararlı sürümünü yayımladı
- sudo-rs, Linux’ta kullanıcı hesabı ile yönetici hesabı arasındaki yetki sınırını aşmak için yaygın olarak kullanılan sudo yardımcı aracının Rust ile yeniden uygulanmış bir sürümüdür
- sudo-rs projesi, orijinal sudo’ya kıyasla güvenliği artırmaya odaklanıyor
- Rust kullanarak bellek güvenliğini sağlıyor
- Orijinal sudo’nun güvenlik hatalarının yaklaşık üçte birinin bellek yönetimi sorunları olduğu tahmini çıkış noktası oldu
- Daha az yaygın kullanılan özellikleri hariç tutarak saldırı yüzeyini azaltıyor
- Kapsamlı bir test paketi geliştirildi; bu testler orijinal sudo’daki hataları da buldu
Benimsenme durumu ve sonraki adımlar
- Wolfi Linux OS halihazırda sudo-rs’i içeriyor
- Chainguard CEO’su ve kurucu ortağı Dan Lorenc, Wolfi’yi oluştururken bellek güvenliğinin en öncelikli konu olduğunu; sudo gibi güvenlik açısından kritik araçlardaki iyileştirmelerin tüm sektör üzerinde büyük etki yaratabileceğini düşünüyor
- sudo-rs, Tweede Golf ve Ferrous Systems ortak ekibi tarafından Prossimo ile yapılan sözleşme kapsamında geliştirildi
- Proje Aralık 2022’de başlatıldı; sudo-rs koduna yönelik dış güvenlik denetiminin Eylül 2023’te başlaması planlanıyor
- Denetimin ardından ekip, çalışma planının Milestone 4 aşamasına geçecek; bu aşama kurumsal özelliklere odaklanıyor
- Orijinal C tabanlı sudo yardımcı aracı uzun süredir Todd C. Miller tarafından sürdürülüyor; Miller, sudo-rs uygulaması için de tavsiyelerde bulundu
- NLnet Foundation, sudo-rs denetimini finanse etti; Amazon Web Services ise bu çalışmayı ve bellek güvenli yazılıma geçişi destekledi
1 yorum
Hacker News yorumları
sudo’nun özgün geliştiricilerinden biri olarak (https://en.wikipedia.org/wiki/Sudo), son 43 yılda neredeyse tamamen yeniden yazılıp sürekli hata düzeltmelerinden geçtiğini gördüm
Güvenlik açıkları açısından en çok incelenmiş UNIX komutlarından biri olduğu söylenebilir; bulunan açıklar da düzeltilip durdu
Binlerce geliştirici ve güvenlik uzmanının incelediği bir aracı tek bir geliştirici ekibinin tamamen yeniden uygularken bir iki yeni hata bile üretmemesinin mümkün olup olmadığını merak ediyorum
Rust dilinde, hataların girme olasılığını sihirli biçimde tamamen ortadan kaldıran bir şey mi var diye düşünüyorum
sudo-rs’yi geliştirirken mevcut çalışmayı geçersiz kılmaya hiç çalışmadık; özellikle başlangıçta bizim uygulamamızın da hatasız olmayacağının gayet farkındayız
Kişisel olarak Rust sürümünü geliştirirken, görece güvenli C kodu yazabileceğime çok güvenmediğim için normalde dokunması zor olan alanlarla ilgilenebildim
En azından bu çalışma sayesinde mevcut sudo’da şimdiden birkaç hata bulduk; 43 yıldır düzeltiliyor olsa bile çevresel koşullar değiştiği sürece böyle bir yazılımın tamamen hatasız hâle gelmesi zor
Birbirimizle işbirliği yaptığımız ve birbirimizin çalışmalarından ve hatalarından öğrendiğimiz sürece, biraz alternatif olmasının zararı yok
RiiR yaparken bir geliştiricinin yapabileceği en iyi şey, iyi uygulamaları izlemek ve geçmiş hatalardan ders çıkarmaktır
43 yılda çok ilerleme kaydedildi; yalnızca C string işlemlerini bırakmak bile bellek güvenliğini tartışmadan önce sayısız hatayı ortadan kaldırır
Bugün güvenli bir sudo alternatifi yapmak isteyen biri, yalnızca C kullansa bile eskisinden çok daha iyi iş çıkarabilir; OpenBSD projesi bunu oldukça iyi gösteriyor
OpenBSD kodunun kaçındığı keskin kenarların çoğunu dil düzeyinde ortadan kaldırmak başlangıçta avantaj sağlar; ama hâlâ çok dikkat ve deneyim gerekir, programlama dili bunu sizin yerinize sağlayamaz
En azından ciddi biçimde incelenmeye değer, ancak bir süre daha varsayılan olarak dağıtılmaması gerektiğini düşünüyorum
Artık bunlar lise müfredatına girmiş durumda; bu müfredatı geçerseniz oldukça iyi yapabilirsiniz, biraz daha çabayla da onların bir ömür harcayarak başardığı şeyleri çok iyi kavrayabilirsiniz
Çünkü devlerin omuzları üzerinde durabiliyor, geçmişe bakışın ve daha iyi teknoloji ile öğrenme yöntemlerinin avantajını elde ediyoruz; onların tüm hatalarını tekrarlamamız gerekmiyor
Özgün geliştirici bugünkü deneyim ve bilgisiyle sudo’yu sıfırdan yeniden yazsa, çok daha kısa sürede daha temiz ve basit bir şey üretmesi muhtemel
Bu, mevcut emeği ve deneyimi küçümsemek değil; o deneyimi daha kısa sürede daha iyi bir şeye dönüştürmenin imkânsız olmadığı anlamına geliyor
Yine de C ile yazılmış sudo’nun ya da başka araçların yerine bir şey koyarken, null pointer veya buffer kötüye kullanımı gibi açıklar kolayca toplamın %50’sini oluşturur
Bu projenin öne çıkardığı iki unsurun Rust kullanımından bile daha sık gözden kaçırıldığını düşünüyorum
Daha az kullanılan özellikleri çıkararak saldırı yüzeyini azaltmak ve mevcut sudo’daki hataları bile bulan kapsamlı bir test kümesi geliştirmek
Güvenliğin kritik olduğu kod yazarken bunlar, Rust ile yeniden yazmaktan bile daha önemlidir
Coq adlı biçimsel kanıt yönetim sistemiyle kanıtlamak: https://coq.inria.fr/
Gerçek örnekler için https://aws.amazon.com/security/provable-security/ adresine bakılabilir; bilgisayar destekli doğrulama (CAV) da incelenmeye değer
Bu projenin hedefinin sudo’nun yerini almak olduğunu varsayarsak, “daha az kullanılan özellikleri hariç tutma” konusunu geçiştirmek biraz endişe verici
Bu özelliklerin ne olduğu, ne kadar az kullanıldığı ve bu özellikleri kullanan yapılandırmalarda nasıl başarısız olduğu önemli
Düzeltme: Görünüşe göre bazı sınırlamalar GitHub README’de özetlenmiş, https://github.com/memorysafety/sudo-rs#differences-from-ori...
sudoeditveyasudo -e/etc içindeki dosyaları ya da kullanıcımın yetkisi olmayan dosyaları düzenlerken sık kullanıyorum; bu bayrak önce dosyayı kullanıcımın düzenleyebileceği izinlere sahip geçici bir konuma kopyalıyor, ardından metin düzenleyiciyi sudo yetkisi olmadan kullanıcımın yetkileriyle çalıştırıyor
Düzenleyici
$SUDO_EDITORortam değişkeniyle belirleniyor ve kapatıldıktan sonra yalnızca değişiklik varsa dosyayı özgün yetkileriyle geri kopyalıyorİyi tarafı, düzenleyiciyi root kullanıcı olarak değil kendi kullanıcım olarak çalıştırması; böylece kullanıcı ayarlarımı ve eklentilerimi yüklüyor
make me a sandwichçalıştırma özelliği (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)Normal sudo’da, merkezi LDAP yapılandırmasından tüm ağın sudo yetkileri yönetilebiliyor; zaman, makine, kullanıcı ve komuta göre kısıtlanmış kurallar da merkezi olarak oluşturulabiliyor
Basit bir söz dizimi hatasının tüm yapılandırmayı uçurması ihtimali olmadan; bu durumda yalnızca ilgili kural yok sayılıyor
Muhakkak iyi teknik belgeler de olacaktır; bu bir tanıtım amaçlı sürüm duyurusu olduğundan eksik özellikler listesini aramak için doğru yer değil bence
Apache-2.0+MITileGPL-2.0arasındaki farka bakınca, bellek güvenli su/sudo-rs elde edebilirsiniz ama bunu ikili dosya biçiminde dağıtan tarafın derlemede kullandığı kaynak kodu ve olası değişiklikleri yayımlama yükümlülüğü yokGPL araçlarını MIT/Apache lisanslı Rust yeniden yazımlarıyla kenara itme eğiliminin bir gün tescilli Linuxa yol açmasından ciddi endişe duyuyorum; ancak özgün sudo GPL değil
ISC/MIT tarzı bir lisans [1]
Tam da yukarıda söylenen nedenle; bu soruna dikkat çekmek için yazıyorum
su ise gerçekten GPL gibi görünüyor
[0]: https://www.sudo.ws/about/license/
Böyle dağıtımları kullanmama özgürlüğünüz var
Güvenlik açısından, kötü niyetli bir aktör ikili dosya olarak dağıttığından farklı bir kaynak kod gösterebilir
GPL olsun ya da olmasın aynı şey geçerli
IoT için özgür ve açık kaynak UNIX benzeri işletim sistemleri alanında, Linux Foundation’ın desteklediği ZephyrOS dahil tüm adaylar Apache, MIT ve BSD lisanslarını karışık kullanıyor
GPL kuşağı ortadan kalktıktan sonra, büyük şirketlere daha cazip lisanslara sahip UNIX benzeri bir işletim sistemi, Linux çekirdeğinin başka bir yönetim alternatifi olarak çok geçmeden ortaya çıkacaktır
Bunu Rust uygulaması GNU Coreutils ile birleştiren bir Debian türevi görmek ilginç olurdu
Bellek güvenliği ve performans açısından büyük kazanım sağlayabilir
[1] https://github.com/uutils/coreutils
En azından bir C derleyicisi uygulamak gerekmez
Dışkıyı parlatmak mı bu?
Daha iyi bir yeniden uygulama elbette güzel, ama sudo’nun tuhaf özelliklerini okuyup şaşırmadınız mı?
Sıradan görünen kısımlar bile çok garip ve incelikli; bu yüzden de o kadar kırılgan
sudo’yu “derinlemesine” kullananların başka bir yol olup olmadığını düşünmesi iyi olur
Mevcut sudo yapılandırmasını deneme amaçlı çalıştırıp sudo-rs’nin desteklemediği kısımları çıktılayan bir doğrulama/kontrol bayrağı ya da aracı olsa iyi olurdu
Böyle projelerde geçişin sorunsuz olması için bir taşınabilirlik yardımcısı olmalı
Yanlış hatırlamıyorsam yakın zamandaki sudo açıklarının hepsi mantık hatasıydı, bellek güvenliği sorunu değildi
Yeniden yazmak iyi, ama bir şeyin nasıl çalıştığını yanlış anlama ya da sıradan bir hata yüzünden yeni hatalar giremeyecekmiş gibi davranmamak gerekir
2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634
Bellek güvenliği hakkında çok iddia görüyorum, ama bu projenin başka tür hataların kesin olarak ortadan kalkacağını söylediği izlenimini vermiyor
Statik denetimle saldırı yüzeyini azaltmak uzun vadede daha iyi bir alışveriş gibi görünüyor
doas aynı işi yapan çok daha basit bir araç
Neden daha yaygın kullanılmadığını pek bilmiyorum
doas 43184 bayt ve ihtiyacım olan her şeyi yapıyor
O sudo exploit’i bir uyarı niteliğindeydi
Henüz geçmediyseniz opendoas’ı (Debian paketi) denemeye değer
tty pushback saldırısına karşı korumalı değil: https://github.com/Duncaen/OpenDoas/issues/106
Oldukça ciddi, çözülmemiş bir güvenlik sorunu