gVisor ve Firecracker: AI Aracı Sandboxlama Testlerinden Çıkan 5 Kritik Ders

MCP (Model Context Protocol) sunucuları için güvenlik standartları belirlemek hiç kolay değil. Her sunucu farklı bir kod tabanına sahipken, kötü niyetli kullanıcıların sisteme sızmasını engellemek için katmanlı bir savunma mimarisi gerekiyor.

Bu alanda öne çıkan iki teknoloji, Google’ın gVisor’ı ve Amazon’un Firecracker’ı arasındaki farkları ele alan bir makaleyi inceledikten sonra, MarketNow adlı platformda gVisor’ı üretim ortamında kullanmaya karar verdik. Makalede bahsedilenlerden yola çıkarak yaptığımız testler, sandbox sistemlerinin gerçek dünya performansını ve sınırlarını gözler önüne serdi.

Makalenin Doğru Tespitleri: Temel Farklar

gVisor ve Firecracker arasındaki en önemli fark, sistem çağrılarını (syscall) nasıl ele aldıklarıyla ilgili. gVisor, kullanıcı alanında çalışan bir çekirdek olarak tüm sistem çağrılarını yakalayıp inceleyebiliyor. Bu yaklaşım yaklaşık %5-10 performans kaybına yol açsa da, saldırı yüzeyini önemli ölçüde daraltıyor.

Firecracker ise KVM tabanlı mikro sanal makineler (microVM) kullanıyor. Bu teknoloji, yaklaşık 125 milisaniyelik başlatma süresiyle neredeyse sıfır performans kaybı sağlıyor. Ancak Firecracker’ın çalışması için KVM erişimine ihtiyaç duyulması, bazı bulut sağlayıcılarıyla uyumlu olmasını zorlaştırıyor.

gVisor’u GitHub Actions Üzerinde Kullanmanın 5 Kritik Dersi

MarketNow olarak, gVisor’ı CI/CD hattında kullanmaya karar verdik. Ancak bu süreçte karşılaştığımız engeller, sandbox sistemlerinin gerçek dünya uygulamada ne kadar hassas olduğunu gösterdi.

1. Kurulumda sudo İhtiyacı

gVisor’u Docker’a entegre etmek için /etc/docker/daemon.json dosyasına yazma izni gerekiyor. Bu dosyaya erişmek için sudo yetkisi olmadan değişiklik yapmak mümkün değil.

sudo wget -q  -O /usr/local/bin/runsc
sudo chmod +x /usr/local/bin/runsc
echo '{"runtimes":{"runsc":{"path":"/usr/local/bin/runsc"}}}' | sudo tee /etc/docker/daemon.json
sudo systemctl restart docker

2. Derleme Zamanı Ağ Bağlantısı Gereği

Docker imajı oluştururken --network none parametresini kullanmak, bağımlılıkların indirilmesini engelliyor. Örneğin, npm install komutu registry.npmjs.org adresine ulaşamaz hale geliyor. Bu nedenle derleme sırasında ağa izin vermek, izolasyonun yalnızca çalışma zamanında uygulanması gerektiğini gösteriyor.

3. gVisor’un seccomp’dan Daha Fazlasını Yakaladığı Durumlar

gVisor, standart seccomp profillerinin ötesinde bazı sistem çağrılarını engelleyebiliyor. Üretim ortamında karşılaştığımız durumlar şunlardı:

• Bir sunucu, ptrace() sistem çağrısını kullanmaya çalıştı — gVisor bunu EPERM hatasıyla engelledi.
• Başka bir sunucu, bpf() sistem çağrısını kullanmaya çalıştı — gVisor bu çağrıyı desteklemediği için ENOSYS hatasıyla yanıtladı.
• Hiçbir sunucunun çekirdek açığını hedef alan saldırı girişiminde bulunmadığını gördük, ancak gVisor’un bunu yakalayabileceğini de doğrulamış olduk.

4. gVisor’un Uyumluluk Sorunları: Gerçek Bir Güvenlik Kazancı

gVisor’un %50’ye varan oranda MCP sunucusunun çalışmasını engellediğini gördük. Bunun nedeni, sunucuların gVisor tarafından desteklenmeyen sistem çağrılarını kullanmasıydı. Bu durum ilk bakışta bir dezavantaj gibi görünse de, aslında sistemin güvenliği için önemli bir kazanç.

Eğer bir sunucu gVisor altında çalışamıyorsa, büyük olasılıkla güvenlik açıkları barındırıyordur. Bu nedenle uyumluluk sorunları, erken bir güvenlik uyarısı olarak değerlendirilebilir.

5. Yedekleme Olarak Geliştirilmiş seccomp’un Önemi

gVisor’un çalışmadığı durumlarda, MarketNow olarak geliştirilmiş bir seccomp profili kullanıyoruz. Bu profil, aşağıdaki tehlikeli sistem çağrılarını engelliyor:

• ptrace, bpf, mount, umount2, reboot
• kexec_load, kexec_file_load
• clone3, unshare, setns
• init_module, finit_module, delete_module
• perf_event_open
• name_to_handle_at, open_by_handle_at
• process_vm_readv, process_vm_writev

Bu çağrıların engellenmesi, çekirdek modül yükleme, hata ayıklama araçlarının kullanımı ve diğer saldırı yöntemlerini büyük ölçüde zorlaştırıyor.

Gelecek Planları: Firecracker’a Geçiş Zamanı

Makalede önerildiği gibi, biz de gVisor’u şimdilik kullanmaya devam edecek, ardından Firecracker’a geçeceğiz. Bu geçişin ana nedeni, Firecracker’ın KVM erişimine ihtiyaç duyması. GitHub Actions üzerinde KVM erişimi olmadığı için, Firecracker’ı AWS üzerinde kendi barındırdığımız runner’larda kullanmayı planlıyoruz. Firecracker’ın AWS Lambda ve Fargate gibi hizmetlerde kullanılması da bu tercihi destekliyor.

6 Katmanlı Denetim Sistemi: MarketNow’un Yaklaşımı

MarketNow’da MCP sunucularını değerlendirmek için çok katmanlı bir denetim sistemi kullanıyoruz. Her katmanın amacı farklı bir güvenlik açığını hedefliyor:

• L1.5: Statik analiz (bağımlılıklar, gizli anahtarlar, lisanslar)
• L1.6: Davranışsal analiz (şablon tabanlı inceleme)
• L2 v2.0: Aktif prob (60’dan fazla saldırgan girişim)
• L2.5: gVisor sandbox (bu aşamada)
• L3 (Q1 2027): Firecracker microVM
• L4 (Q4 2026): Tedarik zinciri doğrulaması (SLSA Seviye 3)
• L5 (Q3 2027): Üçüncü taraf denetimleri (Trail of Bits, Cure53)

Bugüne Kadar Elde Edilen Sonuçlar

8.764 MCP sunucusu üzerinde yapılan denetimler sonucunda, 206 sunucu gVisor sandbox aşamasından geçti. Bu sunucuların değerlendirme sonuçları şu şekildeydi:

• 69 sunucu 10/10 puan aldı (temiz)
• 103 sunucu 0/10 puan aldı (gVisor uyumluluk sorunları nedeniyle çalışmadı)
• 6 sunucu 2/10 puan aldı (yüksek riskli — kritik bulgular)
• 3 sunucu ortam değişkenlerini sızdırdığı için platformdan kaldırıldı

Sistemi Test Etmek İster misiniz?

MarketNow’un güvenlik metodolojisi hakkında detaylı bilgi almak için marketnow.site/security adresini ziyaret edebilirsiniz.

Örneğin, Anthropic’in dosya sistemi MCP sunucusu 10/10 puan aldı. Bu sunucunun denetim raporuna GitHub üzerinden ulaşabilirsiniz.

Eğer kendi MCP sunucunuzu denetlettirmek istiyorsanız, GitHub Issues üzerinden bir talep oluşturabilirsiniz.

Makalenin orijinal analizini paylaşan @chunxiaoxx’a teşekkürlerimizi sunarız — sandboxlama teknolojilerinin geleceği hakkında önemli bir rehber niteliğindeydi.