sandboxing

gVisor बनाम seccomp-bpf: आक्रामक टूल्स का सैंडबॉक्सिंग

किसी एजेंट को एक्सप्लॉइट चलाने देना असहज सवाल खड़ा करता है: जब वह जो टूल चलाता है वही दुर्भावनापूर्ण हो, या एजेंट खुद गलती कर दे, तो क्या होगा? हमारा पहला उत्तर seccomp-bpf था। दूसरा, अधिक जोखिम वाले कामों के लिए, gVisor है। ये प्रतिस्पर्धा नहीं करते — परत-दर-परत जुड़ते हैं।

seccomp-bpf: सस्ता और धारदार

seccomp-bpf कर्नेल स्तर पर लगभग शून्य लागत में syscalls फ़िल्टर करता है। ज्ञात टूल्स के लिए आदर्श: nmap या ffuf को चाहिए उन syscalls की श्वेतसूची परिभाषित करें, बाकी SIGSYS से मरता है। पेच: प्रोफ़ाइल नाज़ुक हैं, एक अतिरिक्त अनुमत syscall भागने का रास्ता बन सकता है।

seccomp:
  default_action: SCMP_ACT_ERRNO
  syscalls:
    - names: [read, write, openat, connect, socket]
      action: SCMP_ACT_ALLOW

gVisor: आपके और असली कर्नेल के बीच एक कर्नेल

gVisor, Go में लिखे यूज़र-स्पेस कर्नेल में syscalls रोकता है: बाइनरी सोचती है वह Linux से बात कर रही है, पर वह Sentry से बात करती है। उजागर असली कर्नेल सतह नाटकीय रूप से घटती है। आप प्रदर्शन में कीमत चुकाते हैं, पर कर्नेल 0-day के विरुद्ध अलगाव पाते हैं।

हम कैसे चुनते हैं

  • विश्वसनीय टूल, ज्ञात प्रोफ़ाइल: seccomp-bpf।
  • अविश्वसनीय बाइनरी, तृतीय-पक्ष एक्सप्लॉइट, विश्लेषणाधीन मैलवेयर: gVisor, भीतर seccomp-bpf भी।
  • हमेशा: CPU/मेमोरी के लिए cgroups और प्रति-स्कोप नेटवर्क नीतियाँ।

हम क्या देते हैं

Gwaihir सैंडबॉक्स को टूल के विश्वास-स्तर से चुनता है, वैश्विक डिफ़ॉल्ट से नहीं। सामान्य स्थिति गति के लिए seccomp-bpf में; जोखिम भरी gVisor में। गहराई में रक्षा, एक दीवार नहीं।