Podman Rootless Konteynerleri ve Copy Fail Exploit'i

 (garrido.io)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • CVE-2026-31431 Copy Fail, yerel ayrıcalıksız kullanıcıların root kabuğu elde etmesine olanak tanır ve Podman rootless konteynerlerinin içinde de konteyner içi root yetki yükseltmesi mümkündür
  • Podman rootless konteynerleri, konteyner içindeki root kullanıcısını host üzerindeki ayrıcalıksız kullanıcıya eşleyip host yetkilerini sınırlandırmak için kullanıcı ad alanları, UID ayrımı ve Linux capabilities kombinasyonunu kullanır
  • Testlerde, rootless non-root konteynerindeki foo kullanıcısı Copy Fail çalıştırdıktan sonra konteyner içinde root olabildi; ancak yetkileri hosttaki ayrıcalıksız kullanıcı barın sahip olabileceği kapsamla sınırlı kaldı ve hostta root sahibi dosyaları okuyamadı
  • --security-opt=no-new-privileges veya --cap-drop=all uygulanırsa, Copy Fail çalıştırıldıktan sonra da kabuk foo ve capabilities none durumunda kalır; bu da anında root kabuğu elde edilmesini ve capability yükseltmesini engelleyebilir
  • Copy Fail'in etkisi konteyner yaşam döngüsünün ötesine taşabileceğinden çekirdek yaması ve yeniden başlatma gerekir; ayrıca salt okunur root dosya sistemi, cgroups kaynak sınırları, ince runtime imajları ve güvenlik duvarı gibi katmanlı savunma önlemleri birlikte uygulanmalıdır

Copy Fail ve Podman rootless konteynerlerinin maruziyet kapsamı

  • CVE-2026-31431, 29 Nisan'da copy.fail üzerinde açıklandı ve yayımlanan Python betiği çalıştırıldığında yerel ayrıcalıksız kullanıcılar root kabuğu elde edebiliyor
  • Copy Fail, Linux konteynerleri içinde de istismar edilebilir ve Podman rootless konteynerlerinde de konteyner içi root kabuğu elde etmek mümkündür
  • Testlerde, konteyner root yetkilerinin host düzeyinde konteyneri çalıştıran ayrıcalıksız kullanıcı barın yetki kapsamıyla sınırlı kaldığı görüldü
  • Podman'ın rootless uygulaması, konteyner süreçlerinin host yetkilerini sınırlamak için kullanıcı ad alanları, UID ayrımı ve Linux capabilities kombinasyonunu kullanır
  • Copy Fail, rootless konteynerlerin de zafiyete karşı bağışık olmadığını; ancak Podman yapılandırmasıyla ihlal sonrası saldırı kapsamının azaltılabileceğini gösteriyor

Rootless konteynerler nasıl çalışır

  • Temel örnek: ayrıcalıksız kullanıcı bar bir HTTP sunucusu çalıştırıyor

    • Örnek ortamda UID 1001 olan ayrıcalıksız kullanıcı bar, Podman ile ubuntu:latest tabanlı bir imaj oluşturur ve python3 -m http.server çalıştırır
    • Hostta ps çıktısına bakıldığında python3 sürecinin bar kullanıcısına ait olarak çalıştığı görülür
    • Podman fork/exec modelini kullandığı için konteyner süreci podman run sürecinin alt süreci olur; bu da normal UID ayrımıyla konteyner sürecinin host rootundan veya diğer kullanıcılardan ayrılmasını sağlar
    • Yaygın Docker yapılandırmalarında ise ayrıcalıksız kullanıcı docker run çalıştırsa bile Docker istemcisi root yetkili daemon ile iletişim kurar ve daemon nihayetinde konteyner sürecini oluşturur; bu yüzden hostta konteyner süreci root olarak görünebilir

  • Rootless rootful

    • Konteyner imajlarında açık bir USER yönergesi veya --user bayrağı yoksa, konteyner komutu genellikle konteyner içinde root olarak çalışır
    • podman top çıktısında HTTP sunucusu süreci host kullanıcısı 1001e eşlenmiş görünür; ancak konteyner içi kullanıcı olarak root şeklinde çalışır
    • Bu yapılandırma, host üzerinde ayrıcalıksız kullanıcı olarak çalışırken konteyner içinde root olan bir rootless rootful durumudur

  • Kullanıcı ad alanları

    • Podman rootless konteynerleri, konteynerin içi ve dışındaki UID/GID değerlerini farklı eşlemek için kullanıcı ad alanları kullanır
    • Örnekte, konteyner içindeki UID 0 olan root, hosttaki UID 1001 olan bar kullanıcısına eşlenir
    • /etc/subuid içindeki bar:165536:65536 ayarı, barın ad alanı süreçlerine atanabilecek UID aralığını belirler
    • Örnekte, barın UID 1001i dışında 165536 ile 231072 arasındaki UID'ler de bar süreçlerine atanabilir
    • Konteyner içindeki www-data kullanıcısıyla sleep çalıştırıldığında, içeride www-data olarak görünürken hostta 165568 olarak görünür
    • podman unshare ile kullanıcı ad alanına girildiğinde, hostta bar:bar sahibi olan home dizini ad alanı içinde root:root olarak görünür
    • Docker da kullanıcı ad alanlarını destekler; ancak ayrı yapılandırma gerekir ve yalnızca tek bir kullanıcı ad alanına izin verir. Buna karşılık Podman, her UNIX kullanıcısının rootless konteynerlerini o kullanıcının ad alanında çalıştırır

  • Ayrıcalıklı işlemler ve Linux capabilities

    • Podman, konteyner süreçlerine ayrıntılı root yetkileri vermek için Linux capabilities kullanır
    • İmaj oluşturma sırasında apt install gibi işlemler, chown, dac_override, fowner, setgid, setuid, net_bind_service, sys_chroot gibi capability kombinasyonları sayesinde mümkün olur
    • podman build --cap-drop=all ile tüm capability'ler kaldırılırsa, apt; setgroups, setegid, seteuid, chown gibi işlemlerde başarısız olur ve imaj oluşturma süreci başarısız olur
    • Yalnızca gerekli capability'leri ekleme yaklaşımı da mümkündür; örnekte CAP_SETUID,CAP_SETGID,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER eklenerek paket kurulumu yapılır
    • Varsayılan çalıştırma durumundaki HTTP sunucusu, konteyner içinde root olarak çalışır ve CHOWN,DAC_OVERRIDE,FOWNER,FSETID,KILL,NET_BIND_SERVICE,SETFCAP,SETGID,SETPCAP,SETUID,SYS_CHROOT gibi çok sayıda effective capability'ye sahiptir
    • HTTP sunucusunun bu yetkilere ihtiyacı olmadığından, podman run --cap-drop=all ile tüm capability'ler kaldırılabilir; bu durumda podman top çıktısında effective capabilities none olarak görünür

  • Rootless non-root

    • HTTP sunucusunu konteyner içinde de ayrıcalıksız bir kullanıcı olarak çalıştırmak için mevcut /etc/passwd kullanıcılarından biri, örneğin www-data, kullanılabilir ya da imaj oluşturma sırasında özel bir kullanıcı oluşturulabilir
    • Örnekte UID 1002 olan foo kullanıcısı ve grubu oluşturulur, /var/www/html için okuma izni verilir ve ardından USER foo:foo ayarlanır
    • Bu imaj --cap-drop=all ile çalıştırıldığında süreç, konteyner içinde foo, hostta UID 166537 ve effective capabilities none durumunda olur
    • Konteyner süreçleri gereken en düşük yetkiyle çalıştırılmalıdır; örneğin foo ayrıcalıklı port 80e bağlanmak zorundaysa --cap-add=CAP_NET_BIND_SERVICE eklenmelidir
    • Konteyner çalıştırma biçimleri dört kategoriye ayrılır
      • host kullanıcısı root + konteyner root: root rootful
      • host kullanıcısı root + konteyner ayrıcalıksız kullanıcı: root non-root
      • ayrıcalıksız host kullanıcısı + konteyner root: rootless rootful
      • ayrıcalıksız host kullanıcısı + konteyner ayrıcalıksız kullanıcı: rootless non-root
    • Podman, rootless rootful konteyner çalıştırmayı kolaylaştırır; ayrıca konteyner süreci ayrıcalıksız kullanıcı olarak çalıştırılabiliyorsa rootless non-root yapılandırması da nispeten kolay kurulabilir

Bind mount ve UID izolasyonu

  • Host dizini konteynere mount edildiğinde, host root, host bar ve namespace foo tarafından sahip olunan dosyalara erişilip erişilemeyeceği UID eşlemesine göre değişir
  • Örnekte /var/lib/bar/test dizininde host root sahipli root.txt ve host bar sahipli bar.txt oluşturuluyor; ardından bunlar konteyner içinde /test olarak okuma/yazma izniyle mount ediliyor
  • Konteyner foo olarak çalıştırıldığında, host bar sahipli dosya konteyner içinde root:root olarak görünürken, host root sahipli dosya namespace'e eşlenmediği için nobody:nogroup olarak görünür
  • Konteyner içindeki foo, bar.txt ve root.txt dosyalarını okuyamaz; rootless non-root, rootless rootful'a kıyasla ek izolasyon sağlar
  • foo tarafından mount edilmiş dizinde oluşturulan foo.txt, hostta UID 166537 sahipli görünür ve host kullanıcısı bar bu dosyanın içeriğini okuyamaz
  • Konteyner iç root ile çalıştırıldığında, namespace root host bar sahipli dosyaları ve foo sahipli dosyaları okuyabilir, ancak host root sahipli dosyaları okuyamaz
  • İç root ile çalıştırırken --cap-drop=all uygulanırsa foo dosyası da okunamaz ve yalnızca host bar sahipli dosyalar okunabilir

Copy Fail testi

  • Test koşulları

    • Copy Fail testinde, başlangıçta yayımlanan commit 8e918b5 içindeki exploit sürümü kullanıldı
    • Örnek konteyner imajı, konteyner içinden exploit betiğinin indirilebilmesi için mevcut HTTP sunucusu imajına curl eklenerek hazırlandı
    • İmaj adı copyfail olarak build edildi
    • Test çekirdeği Debian'ın 6.12.74+deb13+1-amd64 sürümü; Debian ölçütüne göre son sürümler içinde 6.12.85 altı sürümlerin hâlâ yamalanmamış çekirdek olarak kullanılabildiği kabul ediliyor
    • Normalde ayrıcalıksız kullanıcı foo, su çağırdığında root parolası istenir
    • Her testte konteyner kullanıcısı Copy Fail betiğini /tmp altına indirip çalıştırdıktan sonra root shell elde ederse sleep çağırır
    • Copy Fail, konteyner yaşam döngüsünü aştığı için her testten önce VM yeniden başlatılır

  • Rootless rootful'daki sonuçlar

    • Konteyner --user=root ile çalıştırıldığında, konteyner içindeki süreç zaten root olur
    • Bu durumda Copy Fail betiği çalıştırılıp su çağrıldığında uid=0(root) shell elde edilir; ancak root kullanıcısı zaten parola olmadan su ile başka bir root shell açabildiği için Copy Fail'in pratikte eklediği bir şey yoktur
    • podman top çıktısında /bin/bash, python3 copy_fail_exp.py, su ve sleep süreçlerinin tümü konteyner içinde root, host kullanıcısında ise 1001 olarak görünür
    • Aynı capability kümesi korunur ve CHOWN,DAC_OVERRIDE,FOWNER,FSETID,KILL,NET_BIND_SERVICE,SETFCAP,SETGID,SETPCAP,SETUID,SYS_CHROOT görünür
    • İç root, mount edilen /test içinde bar.txt ve foo.txt dosyalarını okuyabilir; ancak host root sahipli root.txt dosyasını okuyamaz

  • Rootless non-root'taki sonuçlar

    • Konteyner foo olarak çalıştırıldıktan sonra Copy Fail betiği çalıştırılıp su çağrıldığında yetkiler konteyner içi root seviyesine yükselir
    • Elde edilen shell'in id çıktısı uid=0(root) gid=1002(foo) groups=1002(foo) olarak görünür
    • podman top çıktısında başlangıçtaki /bin/bash, exploit çalıştırma süreci ve su çağrısı host UID 166537, konteyner kullanıcısı foo, capabilities none olarak görünür
    • Yetki yükseltme sonrası [sh] ve sleep, host kullanıcısı 1001, konteyner kullanıcısı root olarak görünür ve rootless rootful ile aynı capability kümesini elde eder
    • Yetkisi yükseltilmiş konteyner root kullanıcısı da host root sahipli root.txt dosyasını okuyamaz
    • Bu durumda konteyner ele geçirilmiş olsa da saldırı kapsamı, konteynerin ve host üzerindeki ayrıcalıksız kullanıcı barın erişebildiği alanla sınırlı kalır

  • no-new-privileges uygulandığındaki sonuçlar

    • Podman, --security-opt=no-new-privileges ile konteyner süreçlerinin başlangıç anındakinden daha fazla yetki kazanmasını engelleyebilir
    • Bu seçenek rootless non-root konteynere uygulandığında ve Copy Fail çalıştırıldığında bir shell açılır ama durum hâlâ uid=1002(foo) olarak kalır
    • podman top çıktısında da tüm süreçler host UID 166537, konteyner kullanıcısı foo, capabilities none olarak kalır
    • Mount edilen /test içinde de foo yalnızca kendi dosyasını okuyabilir; bar.txt ve root.txt dosyalarını okuyamaz
    • Konteyner ele geçirilmiş olsa da durum, içerideki ayrıcalıksız kullanıcı foo ve capability'siz bir durumla sınırlı kalır

  • --cap-drop=all uygulandığındaki sonuçlar

    • Rootless non-root konteyner --cap-drop=all ile çalıştırılsa da foo zaten başlangıçta capability sahibi değildir
    • Bu durumda Copy Fail çalıştırılıp su çağrıldığında açılan shell uid=1002(foo) olarak kalır
    • podman top çıktısında /bin/bash, exploit çalıştırma, su, shell ve sleep süreçlerinin tümü foo ve capabilities none durumunda görünür
    • Exploit, root shell elde etmeyi başaramaz ve foo, /test içinde yalnızca kendi dosyasını okuyabilir
    • Bu sonuç no-new-privileges testiyle benzerdir; iki önlem birlikte kullanıldığında capability maruziyeti etkili biçimde azaltılabilir

  • Exploit'in kalıcılığı

    • Anlık root shell ve capability kazanımı no-new-privileges veya --cap-drop=all ile engellenebilse de exploit'in kendisinin etkisi sürer
    • Sonrasında capability kısıtlaması olmadan yeni bir konteyner çalıştırılırsa ayrıcalıksız konteyner kullanıcısı foo, yalnızca su çağırarak bile konteyner root olabilir
    • Bu nedenle çekirdek yaması ve yeniden başlatma hâlâ gereklidir

Derinlemesine savunma stratejileri

  • Salt okunur imajlar

    • podman run komutuna --read-only eklendiğinde konteyner kök dosya sistemi salt okunur olarak mount edilir
    • Podman varsayılan olarak /tmp, /run, /var/tmp gibi bazı dizinleri yazılabilir olarak mount ettiğinden, tamamen salt okunur hale getirmek için --read-only-tmpfs=false da eklenmelidir
    • Salt okunur bir konteyner ele geçirilirse sisteme yazma işlemlerine izin verilmez; bu da exploit sonrası bazı saldırıları sınırlayabilir
    • Ancak curl çıktısı python3'e pipe edilebildiği için yalnızca salt okunur ayar, exploit'in çalıştırılmasını tek başına engellemez
    • Örnekteki python3 HTTP sunucusu dosya sistemine yazma gerektirmediğinden bu seçenek güvenle kullanılabilir
    • Önceden derlenmiş birçok imaj, belirli dizinlere yazma erişimini varsaydığı için salt okunur kök dosya sisteminde düzgün çalışmayabilir
    • Salt okunur kök dosya sistemi, konteynere bağlı yazılabilir volume'lerden bağımsızdır; ele geçirilme durumunda bu mount dizinlerine yine de yazılabilir

  • Kaynak sınırları

    • Docker ve Podman, konteynere sağlanan kaynakları sınırlamak için cgroups kullanabilir
    • Konteynerlerin sınırsız bellek, CPU ve PID'e ihtiyacı yoktur
    • podman stats ile konteyner kaynak kullanımını kontrol ettikten sonra buna uygun sınırlar uygulanabilir

  • Kullanılabilir binary'leri sınırlama

    • Örnek, basitlik adına ubuntu imajını kullansa da ubuntu imajı ele geçirilme durumunda saldırganın kullanabileceği çok sayıda binary içerir
    • HTTP sunucusunu çalıştırmak için bu binary'lerin çoğuna gerek yoktur
    • Runtime imajı mümkün olduğunca ince tutulmalıdır
    • Multi-stage build kullanılarak build-time ortamı ile runtime ortamı ayrılabilir
    • python3 gibi amaca özel imajlar, Debian'ın -slim varyantları veya alpine gibi daha küçük dağıtımlar temel alınabilir
    • Konteyner süreciyle uyumluysa distroless images ya da scratch kullanılarak shell, paket yöneticisi ve sistem yardımcı programları olmayan bir runtime oluşturulabilir

  • Güvenlik duvarı

    • iptables veya nftables kullanılarak konteyner süreçleri güvenlik duvarıyla sınırlandırılabilir
    • Konteyner sürecine yalnızca kesinlikle gerekli gelen ve giden bağlantılara izin verilmelidir
    • HTTP sunucusu örneğinde DNS'ye ya da yerel/uzak sunuculara bağlantı gerekmediğinden, yalnızca kurulmuş gelen bağlantılardan gelen tcp paketlerine izin verecek şekilde sınırlandırılabilir

Operasyonel anlamı

  • Standart Podman rootless konteynerleri, varsayılan olarak standart Docker konteyner yapılandırmasına kıyasla daha iyi izolasyon sağlar
  • Docker da rootless çalışma ve ayrıcalıksız user namespace kullanımı sunar; ancak Podman'a göre daha fazla yapılandırma çabası gerektirir ve mimari farklar da etkili olur
  • Docker hâlâ yaygın olarak kullanılmaktadır ve Dokku, Kamal, Coolify, Dokploy gibi self-hosting araçları da varsayılan olarak Docker kullanır
  • Docker Hub imajları yeterince incelenmeden çalıştırılırsa veya sıkılaştırma önlemleri uygulanmazsa, hizmetler gerekenden daha geniş bir saldırı yüzeyiyle çalışabilir
  • Konteyner imajlarının uygulama ayrıntıları anlaşılmalıdır
    • Konteyner sürecini hangi kullanıcı veya kullanıcıların çalıştırdığını bilmek gerekir
    • Konteyner sürecinin kök dosya sisteminde hangi dizinlere bağımlı olduğunu bilmek gerekir
    • Gerekli Linux capabilities ile gereksiz capabilities ayırt edilmelidir
  • Podman ve konteynerlerin sunduğu çeşitli mekanizmalar birlikte kullanılarak konteynerler güçlendirilebilir ve ele geçirilme durumunda etki alanı azaltılabilir
  • İş yüküne bağlı olarak konteynerlere tek güvenlik sınırı olarak güvenilmemelidir
  • Konteynerlerle birlikte ayrı fiziksel veya sanal makineler kullanmak etkili bir ayrım sağlayabilir
  • Podman, aynı host üzerinde bile her iş yükünü ayrı bir ayrıcalıksız kullanıcı ve kendi user namespace'i ile çalıştırarak izole etme yöntemi sunar

Ek kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Lobste.rs görüşleri

  • Yayımlanan exploit'ten ziyade, güvenlik açığının mümkün kıldığı ham davranışa odaklanmak gerekir
    Bu açık, salt okunur olup olmadığına bakılmaksızın page cache'e yazmayı mümkün kıldığı için, kötü niyetli bir container overlayfs'in base image dosyalarına ait sayfaları değiştirebilir ve container dağıtım biçimine bağlı olarak etki başka container'lara da sıçrayabilir
    Buradaki rootless yapılandırmada hedef, host sistemde aynı kullanıcı olarak çalışan diğer container'lardır
    Başka bir exploit yöntemi olarak, hâlihazırda kullanımda olduğu bilinen bir base image tabanlı container'ı çalıştırıp ya da bulup, o container içindeki page cache'i değiştirdikten sonra aynı runtime ve overlayfs verisini paylaşan başka container'ların o kodu çalıştırması sağlanabilir
    Rootless ve user namespace önemli, ancak burada pek yardımcı olmuyor; copy.fail sitesinin de söylediği gibi container'larda socket(AF_ALG, ...) sistem çağrısının seccomp ile engellenmesi değerlendirilmeli

    • Temeldeki ham davranış üzerine bu kadar derin düşünmemiştim; daha çok rootless container'ın sağladığı namespace ve capability'leri toparlayıp ele geçirilmiş bir container'ın maruz bırakacağı etki alanını değerlendirmeye odaklanmıştım
      “Container dağıtım biçimine bağlı olarak” ifadesiyle tam olarak ne kastedildiğini biraz daha açmanız iyi olurdu
      Rootless Podman'ın avantajı, iş yüküne bağlı olarak host'ta aynı kullanıcıyla container çalıştırma zorunluluğu olmamasıdır
      Eğer ana workstation kullanıcısı olarak birden fazla rootless container çalıştırma durumundan söz ediyorsanız katılıyorum; ancak sunucularda her birini ayrı kullanıcılarla ayırmak mümkün ve aynı container image'ı farklı yetkisiz kullanıcılarla da çalıştırabilirsiniz
      Bu, çoğunu root olarak çalıştıran Docker varsayılanından oldukça farklı; ama bunun nihai güvenlik sınırı olmadığına yazının sonunda ben de değindim ve rootless container'ları birden çok yetkisiz kullanıcı arasında paylaştırmanın uygun olup olmadığı kullanım amacına göre değişir
      Bazı iş yüklerini VM ile ayırarak kullanıyorum
      Rootless ve user namespace'in burada yardımcı olmadığı sözüyle exploit'i engellemenin mi kastedildiğini merak ediyorum
      Seccomp için henüz container'lara açık bir politika yazmış değilim, bu yüzden ele almadım; ama daha fazla incelemek için iyi bir vesile

  • Podman ve rootless container'ları seviyorum, ama CopyFail'i görünce kardeş yorumdakiyle aynı sonuca vardım
    podman+rootless ek erişim kontrolü avantajları sunsa da sonuçta klasik öğüdü yeniden doğruluyor: container bir güvenlik sınırı değildir; tek bir kernel exploit'i her şeyi delebilir
    Sistem yönetimini hobi düzeyinde yapan biri olarak, bu alandaki yeni yönelimlerden biri olarak libkrun backend for crun with podman'a baktım
    Vaat şu: container'laştırılmış iş yüklerinin çoğunu olduğu gibi ele alırken, bunları perde arkasında kendi ayrı guest kernel'ine sahip bir MicroVM içinde çalıştırmak; ancak olgunluk, sahada doğrulanma ve güvenlik denetimi seviyesi hakkında pek bilgim yok, bazı kısımlar oldukça bleeding-edge görünüyor
    MicroVM'ler LLM kodlama araçlarında aktif biçimde benimsendiği için bu durum uzun sürmeyebilir
    podman machine de umut verici görünmüştü, ama ne yazık ki yalnızca geliştirici workstation kullanımını hedefliyordu ve host sistem başına container çalıştırmak için tek bir VM modeli üzerine kuruluydu
    Yine de “container bir güvenlik sınırı değildir” sözünün fazla basit olduğunu düşünüyorum. Container'lar kesinlikle bir güvenlik sınırıdır; sadece olmasını umduğumuz kadar güçlü değiller

    • Çoğu bulut container dağıtımının VM kullanmasının nedeni de bu. VM savunulabilir bir sınırdır
      Yerel dağıtımlarda bu çizgi biraz daha bulanıklaşıyor
      Donanım açısından VM'ler süreçlerden özünde daha güvenli değil, ama üç nedenle sınır daha savunulabilir oluyor
      VM escape, sistem çağrılarına göre daha seyrek olduğundan performansı bozmadan daha fazla yan kanal azaltımı uygulamak için alan bırakıyor
      VM'nin host arayüzü çok daha basittir. Blok aygıtları blok düzeyinde okuma-yazma arayüzü sunar, ağ aygıtları ise frame gönderip alır
      Linux ya da *BSD'nin socket'ler için sunduğu setsockopt çağrısı, çoğu emülasyon ya da paravirtualization sürücüsünden çok daha büyük bir saldırı yüzeyidir; üstelik bu bile toplam kernel saldırı yüzeyinin yalnızca çok küçük bir parçasıdır
      VM arayüzü durum açısından da çok daha sınırlıdır. İstek-yanıt modelindeki ring içinde devam eden transaction'lar vardır, ama onun dışında neredeyse hiçbir şey yoktur
      Kimlik bilgileri, UID, GID, file descriptor tabloları gibi şeyler kernel'e duruma dayalı karmaşıklık ekler ve hata varsa süreç bunu suistimal edebilir
      Workstation varyantlarının zorluğu, bu karmaşıklığın yeniden içeri alınmasıdır
      Örneğin container base layer'ı değişmez bir dosya sistemini taşıyan bir blok aygıtı olarak sunulabilir, ama volume'lar ve paylaşılan klasörler muhtemelen 9pfs ya da VirtIO-FS, yani VirtIO üzerinde 9p veya FUSE olarak mount edilecektir
      Bu da saldırı yüzeyini yeniden büyütür
      Şanslıysanız bir exploit chain gerekir
      FreeBSD tarafına daha aşinayım; orada genelde paravirtualization ve emülasyon aygıtları sağlayan bileşenler Capsicum ile sandbox'a alınır, bu yüzden önce bir host sürecinin ele geçirilmesi, ardından da VM'nin erişim yetkisi olmayan şeylere erişmek için kernel'in aşılması gerekir
      Ama bu ek sandboxing yapılmazsa container escape, kullanıcının yapabildiği her şeyi yapabilen bir dünyaya geri döner ve masaüstünde root'un ele geçirilmesinden çok da iyi sayılmaz
    • Kata Containers ve Firecracker aslında epey eski teknolojiler ve araştırmacılar bunları inceleyegeldiği için makul ölçüde olgun olduklarını düşünüyorum
      Kişisel olarak gVisor'ı daha çok tercih ediyorum. VMM runtime değil, ama yıllardır var ve Tencent gibi şirketlerde de kullanılıyor; tüm container'ları zaten bir Proxmox VM içinde çalıştırdığım ortamıma da iyi uyuyor
      Test ettiğim bir diğer şey de syd-oci; sanki varsayılan öneri olan MicroVM ya da gVisor'a kıyasla biraz daha az ilgi görmüş gibi
    • Bu ifade benim deneyimimle de örtüşüyor ve bu yazıyı yazma süreci de bir bakıma bu gerçeği kabullenme alıştırması gibiydi
      libkrun referansı için de teşekkürler, umut verici bir olasılık gibi görünüyor
    • LLM kodlama araçları tarafındaki aktif benimseme, MicroVM'leri daha olgun hale getirme ve sahada doğrulanma ile güçlendirmeye götürme potansiyeline sahip
      Bunun güvenlik denetimlerine de yol açma ihtimali yüksek görünüyor