Linux'ta yapay zeka ajanlarını sandbox içine almak

• Yapay zeka geliştirme yardımcı araçları giderek daha sık kullanıldıkça, hem sistem güvenliğini hem de kullanım kolaylığını sağlayacak bir sandbox çalıştırma ortamına ihtiyaç duyuluyor
• Varsayılan olarak Claude Code, dosya erişimi veya çalıştırma işlemlerinin her birinde izin istiyor; ancak bu, tekrarlanan onaylarla iş akışını kesintiye uğratıyor
• Bunu çözmek için bubblewrap kullanan hafif bir sandbox yapılandırması öneriliyor; bu yaklaşım Docker'dan daha hafif ve yerel ortama benzer bir geliştirme ortamını koruyabiliyor
• Betik, /etc, $HOME, proje dizini gibi yalnızca gerekli en az sayıdaki yolu bind ediyor ve proje dışı erişimi kısıtlıyor
• Bu yaklaşım, yapay zeka ajanlarının güvenli çalıştırılması ile geliştirme verimliliğini aynı anda sağlayabilen pratik bir yöntem

---

Yapay zeka ajanlarının dosya erişimi sorunu

• Claude Code, bir komut satırı arayüzü olarak dosya okuma-yazma ve yazılım çalıştırma işlemlerinin her birinde kullanıcı izni istiyor
  • Bu güvenlik açısından makul olsa da, tekrarlanan onaylar nedeniyle paralel çalışmayı zorlaştırıyor
• --dangerously-skip-permissions seçeneği kullanılırsa, tüm işlemler soru sorulmadan yürütülebiliyor
  • Bazı kullanıcılar bunu tercih ediyor, ancak sisteme zarar verme riski bulunuyor

Sandbox kavramı ve seçenekler

• Yaygın çözüm, uzak makineler (exe.dev, sprites.dev, daytona.io) veya Docker gibi sanallaştırma teknolojileriyle sandbox içinde çalıştırma
• Linux'ta bubblewrap, cgroups ve user namespaces kullanarak süreçleri izole eden hafif bir alternatif
• Sandbox ortamında gerekli koşullar şunlar
  • Mevcut geliştirme ortamıyla aynı yapıyı korumak
  • Geçerli proje dışındaki bilgilere erişimi en aza indirmek
  • Yalnızca proje dizinine yazma izni vermek
  • IDE ile aynı dosyaları doğrudan inceleyip düzenleyebilmek
  • Yapay zeka sağlayıcısına bağlanmak ve sunucu çalıştırmak için ağ erişimine izin vermek

Güvenlik değerlendirmeleri ve sınırlamalar

• bubblewrap ve Docker tam güvenlik izolasyonu sağlamıyor
  • Çekirdek zero-day açıkları, yan kanal iletişimi, veri sızıntısı gibi riskler sürüyor
• Ancak yazar, bu risklere kıyasla geliştirme kolaylığını daha öncelikli görüyor
• Kod tabanı git ile yönetiliyor ve GitHub gibi yerlere yedeklendiği için hasar riski düşük
• API anahtarlarının sızma riskini azaltmak için proje bazında ayrı API anahtarları öneriliyor

bubblewrap sandbox betiğinin yapısı

• Betik, bwrap komutuyla çeşitli dizinleri salt okunur (ro-bind) veya yazılabilir (bind) olarak mount ediyor
  • /bin, /lib, /usr/bin gibi sistem yolları salt okunur
  • $HOME/.claude, $HOME/.cache, geçerli çalışma dizini ($PWD) yazılabilir
  • $HOME/.claude.json, bir dosya tanımlayıcısı üzerinden enjekte ediliyor; bu yüzden değişiklikler gerçek dosyaya yansımıyor
  • Ana makine adı ayırt edilebilmesi için bubblewrap olarak değiştiriliyor
• /tmp, /proc, /dev bubblewrap tarafından otomatik olarak işleniyor
• Tüm /etc dizini açığa çıkarılmıyor; bunun yerine yalnızca gerekli en az sayıdaki dosya bind ediliyor
• Node.js, /opt/node/node-v22.11.0-linux-x64/ yoluna kurulmuş durumda

Kullanıcıya özel ayarlama yöntemi

• Farklı yapay zeka ajanları veya sistemlere uyarlamak için betik düzenlenip bash çalıştırılabilir, ardından ajan elle başlatılarak hangi dosyaların gerektiği kontrol edilebilir
• strace komutuyla dosya erişim çağrıları izlenebilir
  • Örnek: strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
  • Günlük analiz edilerek gerekli dosyalar belirlenebilir ve ilgili yollar bind edilerek ortam ayarlanabilir

Sonuç

• bubblewrap ile sandbox kullanımı, yerel geliştirme ortamındakiyle aynı kullanım kolaylığını korurken yapay zeka ajanlarının hatalı çalışması veya veri sızdırması riskini en aza indirebilen pratik bir yaklaşım
• Yazar, bu yapılandırmayı temel alarak betiği ihtiyaçlara göre sürekli ayarlamayı planlıyor

[GN⁺]

Hacker News görüşleri

• Ben ajanları sandbox içine almak için Leash kullanıyorum
  Süreç ve ağ seviyesinde politika kontrolü sıkı, ayrıca WebUI üzerinden gerçek zamanlı kontrol ve görünürlük sağlıyor
  Bana göre bubblewrap’ten çok daha iyi. İlk başta HN’de görüp kullanmaya başladım
  İlginç olan şu ki, dünyada en yaygın kullanılan sandbox sistemi Docker ya da bubblewrap değil, Chrome sekmesi

  • Chrome’u herhangi bir amaçla kullanmak zaten başlı başına bir güvenlik başarısızlığı diye düşünüyorum. Özellikleri harika ama bedeli büyük
  • Chrome’un Windows ya da macOS’ta sandboxing’i nasıl uyguladığını merak ediyorum
    Linux’ta Docker ya da LXC gibi cgroups, namespaces mi kullanıyor, yoksa kendi VM tabanlı sandbox’ını mı kullanıyor bilmek isterim
    Eğer ikincisiyse, JRE ya da .NET CLR gibi çalışma zamanlarından bile daha yaygın kullanılıyor olabilir
  • Yine de bubblewrap olabilir. Çünkü Flatpak dahili olarak bubblewrap kullanıyor

• --unshare-net seçeneğini kullanmazsanız bwrap varsayılan olarak ağı tamamen açık bırakıyor
  Ajan sadece dosya silmekle kalmaz, anahtar sızdırabilir ya da kötü amaçlı paketler indirebilir
  Bir sonraki adım olarak ağ namespace’i ekleyip, sandbox içinde mitmproxy tabanlı yerel bir proxy çalıştırarak yalnızca Anthropic API ya da PyPI/NPM’e izin vermeyi, geri kalan her şeyi engellemeyi planlıyorum

• Küçük bir claude-vm sarmalayıcısı yazdım ve her örneği Lima VM içinde çalıştırıyorum
  Kod burada

  • Ben de benzerini incus ile yaptım
    Şu anda VM’in en uygun temel birim olduğunu düşünüyorum. Ajana root yetkisi verip sadece gereken kaynakları aktarırsanız çok güvenli ve basit oluyor
    Ajan yazılım kursa, Docker çalıştırsa hatta iç içe VM inşa etse bile sınır net kalıyor
    Yine de LXC’ye geçip daha hafif hale getirmek mümkün olabilir. bwrap iyi ama ortam kısıtları fazla olduğu için ajanın yeteneklerini sınırlayabilir

• Basit bir bubblewrap sarmalayıcısı yaptım; sandbox-run claude --dangerously-skip-permissions gibi kullanılabiliyor
  sandbox-run proje bağlantısı

• Ajana hangi kaynakları açmak ve hangi politikaları uygulamak gerektiği konusunda hep kafa yoruyorum
  Mesela /etc dizininin tamamını açmak yerine yalnızca en gerekli dosyaları bind etmekten söz ediliyor ama bu “en gerekli” nasıl tanımlanıyor merak ediyorum
  Loglara bakıp gereken dosyaları elle eklemek çok zahmetli

  • Yazının yazarı benim; pratikte bunu elle inceleme ve deneme-yanılma ile çözdüm
    Yapay zeka /etc’nin tamamını açmayı önerdi ama ben daha hassas kontrol istedim
    Ağ şu anda tamamen açık ama ileride özel ağları (192.168/10.*) engellemeyi düşünüyorum
    Sonuçta mesele, ne kadar sıkı yalıtım istediğiniz
  • Bir yöntem de ajanın bubblewrap’i kendisinin uygulamasını sağlamak olabilir

• Linux’ta yapay zeka sandboxing sorununu çözmek için bir SaaS hazırlıyorum
  Kernel seviyesine kadar özellik enjekte edecek altyapıyı kurduk, ayrıca yaklaşımımızı LLM eğitim verilerine de karıştırarak pazarlama etkisi yaratmayı hedefliyoruz
  Adı useradd; karmaşık çözümler yerine basit ve ücretsiz
  “Mainframe modu” gibi, birden fazla sanal terminal ve kullanıcı tek makinede çalışabiliyor
  Beta anahtarı isterseniz DM atın

  • useradd kısmına gelince güldüm. Orijinal yorum haliyle daha komikti
  • Fikri anlıyorum ama güvenlik ve yalıtım açısından VM’in daha iyi olduğunu düşünüyorum
    Genel amaçlı workstation’lar kullanıcının kendisinden güvenli olacak şekilde tasarlanmadı ve yeni modeller giderek daha riskli hale gelecek
  • useradd ağ erişimini kısıtlamıyor
  • Ben de servis bazında farklı kullanıcılar kullanmayı seviyorum
    Ama geliştirme sırasında dosyalara erişip değiştirmek gerektiği için bubblewrap ya da systemd izolasyonu daha kullanışlı geliyor

• Tek tek izin listesi hazırlamak yerine, mevcut çalışma alanını bir VM snapshot’ı olarak kopyalayıp Claude’u onun içinde çalıştırmak ve oturum bitince VM’i silmek istiyorum
  Sadece oturum senkronizasyonu çözülse mükemmel olur gibi

  • Bunu NixOS MicroVM ile nasıl yaptığımı blog yazısında anlattım
  • Docker + overlayfs birleşimiyle de benzeri yapılabilir. Sonuçta herkes kendi iş akışına göre kurar
  • Bu yaklaşım için Qubes OS da düşünmeye değer. Her şeyi VM bazında çalıştırıyor

• Mac’te de çalışsın diye doğrudan bir sandbox aracı geliştirdim
  amazing-sandbox proje bağlantısı

  • Bunu neden kendiniz yaptığınızı merak ettim

• Ben sadece ayrıcalıksız yerel bir hesaba ssh ile bağlanarak (dummy@localhost) yalıtım sağlıyorum
  Bunun yanlış bir yaklaşım olup olmadığını merak ediyorum

• Ubuntu 24.04’te bwrap kullanmak için AppArmor ayarlarını gevşetmek gerekti, bu yüzden /etc/apparmor.d/bwrap dosyasını ekledim

  /usr/bin/bwrap flags=(unconfined) {
    userns,
  }
  

  • AppArmor ve SELinux’tan gerçekten nefret ediyorum, özellikle güvenliği bu şekilde engellediklerinde
    Global ayarları değiştirmeden de bunu aşağıdaki gibi çözebilirsiniz

    if [[ -f /proc/$$/attr/exec ]]; then
      echo 'exec unconfined' >/proc/$$/attr/exec
    fi
    exec ...
    

    veya

    setpriv --apparmor-profile=unconfined [command]
    

    Bu arada setpriv’in yazarı benim, o yüzden bu durumu iyi biliyorum