docker grubu kullanıcılara neden root yetkisi verir ve rootless container'lar bunu nasıl önler

Yeni Linux dağıtımlarından birindeki yakında açıklanan bir güvenlik açığı, uzun süredir bilinen bir Docker zayıflığını yeniden gündeme getirdi. Blogunda yazan ve Hacker News'in ön sayfasına ulaşan bir denemede Miguel Grinberg, olayın — sessizce standart dışı, riskli bir Docker yapılandırması uygulayan bir kurulum programından kaynaklanmasının — insanları container'ları root olmadan çalıştırmaya yönlendirmesi gerektiğini savunuyor.

Grinberg'e göre açıklık, etkilenen bir makinedeki herhangi bir sürecin parola, sudo veya onay istemeden kendini root'a yükseltmesine imkân veriyordu. Kök neden container kodundaki bir hata değil, docker komutunun yükseltilmiş ayrıcalıklar olmadan kullanılabilir hale getiren bir varsayılan yapılandırmaydı.

Docker'ın root daemon'u neden bir risk

Grinberg'e göre Docker'ın güvenlik sorunları istemci-sunucu mimarisine dayanıyor. Daemon, arka planda root olarak çalışıyor ve Docker socket'i üzerinden bir API sunuyor; docker CLI gibi istemciler bu API ile konuşuyor. Daemon root olduğu için, ona erişebilen herkes tam sistem ayrıcalıklarıyla kod çalıştırabilir.

Bu noktayı Ubuntu 26.04 üzerinde bir makinede gösteriyor. Normal bir kullanıcı için /etc/sudoers.d içeriğini listelemek başarısız oluyor, ancak aynı listeleme, ana makinenin tüm dosya sistemini bind-mount eden bir container üzerinden yapıldığında başarılı oluyor. Container, daemon'un root ayrıcalıklarını devraldığı için komutu çalıştıran kullanıcının kendi kısıtlamaları uygulanmıyor — ve hiçbir parola sorulmuyor. Biraz daha geliştirilmiş bir betiğin, diye belirtiyor, sistem dosyalarını yeniden yazabileceğini, cron işleri yerleştirebileceğini veya verileri fark edilmeden dışarı sızdırabileceğini söylüyor.

Bir uyarı var: varsayılan bir Docker kurulumunda yalnızca root docker komutunu çalıştırabilir, yani hilenin işleyeceği bir yer yok. Risk, bu kısıtlama kolaylık olsun diye gevşetildiğinde ortaya çıkıyor — en yaygın biçimde, bir kullanıcıyı docker grubuna ekleyerek sudo gereksinimi ortadan kaldırıldığında. Bu adım Docker'ın kendi belgelerinde tarif edilir ve Grinberg çoğu Linux Docker kullanıcısının bunu yaptığından şüpheleniyor. Son güvenlik açığına yol açan dağıtım da kullanıcılarından habersiz özünde aynı şeyi yapmıştı.

macOS, Windows ve WSL

Docker yalnızca Linux üzerinde çalışır. macOS ve Windows'taki Docker Desktop gibi ürünlerin onu çalışır kılmak için bir Linux sanal makinesi barındırır ve bu kurulumlara derinlemesine aşina olmadığını söyleyen Grinberg, bu ek ayrım katmanının ana makineye yönelik tehlikeyi önemli ölçüde azaltmasını bekliyor. Windows'taki WSL farklıdır: Linux çekirdeği ana makinede doğrudan çalışır ve işletim sistemiyle sıkı bütünleşme vardır, bu yüzden Grinberg onu yerel bir Linux sistemine yakın riskler taşıyor olarak değerlendiriyor.

Rootless seçenekleri

Grinberg iki alternatife dikkat çekiyor:

• Docker'ın rootless modu daemon'u kullanıcı düzeyinde bir hizmet olarak çalıştırır. Kurulumu hantal buluyor: Docker'ı normal şekilde kurun, sistem daemon'unu elle devre dışı bırakın, ardından kullanıcı başına bir yedek ayaklandıran verilen bir betiği çalıştırın.
• Podman daemon'u tamamen kaldırır. Kurun ve çalışır; arka plan hizmeti gerekmez. Komut satırında docker yerine podman yazın — ya da birini diğerine alias olarak tanımlayın — ve onun deneyimine göre iş akışlarının büyük çoğunluğu aynı şekilde davranır; container'lar sizin kendi hesabınız altında çalışır ve suistimal edilecek root sahipliğinde bir daemon olmaz.

Podman'ın uyumluluğu bozduğu yerler

• Registry işlemleri: postgres gibi kısa adla bir image çekmek başarısız olabilir çünkü Podman yapılandırmaya bağlı olarak her zaman Docker Hub'a varsayılan davranmaz. Grinberg'ın tavsiyesi docker.io/library/postgres gibi tam nitelikli adresler kullanmaktır.
• Yeniden başlatmalar: daemon olmadığından container'lar yeniden başlatmadan sonra otomatik olarak tekrar başlatılmaz, dolayısıyla sürekli açık sunucular ek kurulum gerektirir — Podman'ın quadlet komutları aracılığıyla systemd bütünleşmesi, container'ları ayrı ayrı hizmetler olarak kaydedebilir.
• API kullanıcıları: Docker API'si üzerinden container yöneten uygulamalar Podman'ın podman system service ile başlatılan isteğe bağlı uyumluluk hizmetine güvenebilir.

Neden önemli

Denemeye yol açan güvenlik açığı egzotik bir istismardan değil, bir yapılandırma tercihinden kaynaklanıyordu — ve aynı tercih belgelenmiş durumda ve elle rutin biçimde uygulanıyor. docker grubuna üyelik işlevsel olarak root'a eşdeğerdir ve bu, onu geliştirici makinelerinde de CI sunucularında da sessiz bir risk hâline getirir. Rootless kurulumlar — ister Podman ister Docker'ın rootless modu — bu ayrıcalık yükseltme sorunlarının tamamını tek tek yamalamak yerine tüm sınıfını ortadan kaldırır. Grinberg'ın kapanış argümanı basit: Linux'ta container çalıştırıyorsanız, root olmadan çalıştırın.