AI Code Sandboxes: A Comparative Security Study. Part 1 of 2 -- Engine-Level Properties (Attack Surface, Leakage, Stackability, CVE History, Patch Cadence, Fuzzing)

यहाँ एक शोध पत्र "AI Code Sandboxes: A Comparative Security Study" का सरल भाषा और रचनात्मक उपमाओं (analogies) के साथ हिंदी अनुवाद दिया गया है।

बड़ी तस्वीर: "प्लेपेन" (खेलने का घेरा) की समस्या

कल्पना कीजिए कि आपके पास एक बहुत ही बुद्धिमान, लेकिन संभावित रूप से खतरनाक बच्चा (एक AI एजेंट) है। आप चाहते हैं कि वह घर के काम करे (कोड लिखना, प्रोग्राम चलाना), लेकिन आप इस बात से डरे हुए हैं कि कहीं वह आपके घर (आपके कंप्यूटर सर्वर) को तोड़ न दे। इसलिए, आप उसे सुरक्षित रखने के लिए एक प्लेपेन (सैंडबॉक्स) बनाते हैं।

यह शोध पत्र एक सुरक्षा निरीक्षण रिपोर्ट है। लेखकों ने केवल बाड़ (fence) को नहीं देखा; उन्होंने पाँच अलग-अलग प्लेपेन ब्रांडों के आधार (foundation), ताले (locks), रखरखाव के रिकॉर्ड (maintenance records), और गुण नियंत्रण (quality control) का निरीक्षण किया:

1. arrakis (Cloud Hypervisor पर आधारित)
2. e2b (Firecracker पर आधारित)
3. microsandbox (libkrun पर आधारित)
4. gvisor (runsc पर आधारित)
5. daytona (Docker/runc पर आधारित)

लेखकों ने यह देखने के लिए कि कौन से प्लेपेन वास्तव में सुरक्षित हैं, इन पाँच प्लेपेन ब्रांडों का छह विशिष्ट "सुरक्षा अक्षों" (safety axes) पर परीक्षण किया।

---

छह सुरक्षा जाँच (The Axes)

यहाँ वे चीज़ें हैं जिन्हें लेखकों ने मापा है, जिन्हें सरल भाषा में अनुवादित किया गया है:

1. बाड़ की ऊँचाई (Attack Surface - हमला करने का दायरा)

• परीक्षण: बच्चा बाहर निकलने के कितने रास्ते खोज सकता है?
• उपमा: यदि प्लेपेन के सहारे एक सीढ़ी टिकी है, या यदि बाड़ केवल कमर तक ऊँची है, तो बच्चा आसानी से बाहर निकल सकता है।
• निष्कर्ष: कुछ प्लेपेन की दीवारें बहुत ऊँची और चिकनी हैं (बाहर निकलना कठिन है)। अन्य, जैसे daytona, मूल रूप से आपके घर में एक खुला कमरा है जिसमें कोई वास्तविक बाड़ नहीं है।

2. दूरबीन (Information Leakage - सूचना का रिसाव)

• परीक्षण: क्या बच्चा बाहर देख सकता है और देख सकता है कि घर के बाकी हिस्सों में क्या हो रहा है?
• उपमा: यदि बच्चा दरारों के माध्यम से झाँक सकता है और आपके बैंक स्टेटमेंट या पड़ोसी की लाइसेंस प्लेट देख सकता है, तो यह एक 'लीक' है।
• निष्कर्ष: daytona एक ऐसे प्लेपेन की तरह है जिसकी कोई दीवार नहीं है—बच्चा सब कुछ देख सकता है। e2b और microsandbox मोटे, अपारदर्शी पर्दों वाले प्लेपेन की तरह हैं—बच्चा कुछ भी नहीं देख सकता।

3. डबल-लॉक (Defense-in-Depth - गहराई में सुरक्षा)

• परीक्षण: यदि पहला ताला टूट जाए, तो क्या दूसरा ताला है? क्या आप अपने आप और ताले लगा सकते हैं?
• उपमा: एक अच्छा प्लेपेन एक लैच (latch), एक बोल्ट और शायद एक चेन के साथ आता है। एक बुरा प्लेपेन केवल एक कमजोर क्लिप वाला होता है।
• निष्कर्ष: gvisor के साथ चार भारी-भरकम ताले पहले से इंस्टॉल आते हैं। daytona में एक ताला आता है, लेकिन निर्माता ने उसे "खुली" स्थिति में चिपका दिया है, इसलिए आप उसका उपयोग भी नहीं कर सकते।

4. दुर्घटना रिपोर्ट (CVE History - सुरक्षा खामियों का इतिहास)

• परीक्षण: क्या पिछले दो वर्षों में इस प्लेपेन ब्रांड के साथ कोई दर्ज की गई चोरी या चोट की घटना हुई है?
• उपमा: यह देखना कि क्या इस ब्रांड के प्लेपेन के गिरने की खबरें आई हैं।
• निष्कर्ष: runc (जो daytona द्वारा उपयोग किया जाता है) में कई बार बाहर निकलने (escapes) की घटनाएं दर्ज की गई हैं। Firecracker (जो e2b द्वारा उपयोग किया जाता है) में पहली बार बाहर निकलने की घटनाएं हाल ही में देखी गईं। gvisor में मामूली समस्याएं (जैसे ढीला पेंच) देखी गईं, लेकिन कोई पूर्ण एस्केप नहीं।

5. रखरखाव का समय (Patch Cadence - पैच अपडेट की गति)

• परीक्षण: जब कोई सुरक्षा दोष पाया जाता है, तो कंपनी कितनी जल्दी उसे ठीक करती है और आपको पैच भेजती है?
• उपमा: यदि बाड़ में छेद हो जाए, तो क्या कंपनी कल ही मरम्मत करने वाला भेज देती है, या वे छह महीने तक इंतज़ार करते हैं?
• निष्कर्ष: यह मामला पेचीदा है। कुछ कंपनियाँ तुरंत ठीक करती हैं (gvisor, daytona)। अन्य, जैसे arrakis और e2b, एक पुराने बाड़ के संस्करण पर "अटक" गए हैं। उन्होंने एक साल से अधिक समय से अपने प्लेप्ले को अपडेट नहीं किया है, भले ही नए और सुरक्षित बाड़ मौजूद हों।

6. स्ट्रेस टेस्ट (Fuzzing - मजबूती की जाँच)

• परीक्षण: क्या निर्माता ने बेचने से पहले कमजोर बिंदुओं को खोजने के लिए यादृच्छिक (random) औजारों से प्लेपेन को ज़ोर से हिलाया या उस पर प्रहार किया?
• उपमा: एक कठोर निर्माता प्लेपेन को हथौड़ों, आरी और ड्रिल से पीटकर उसकी कमज़ोरियों को ढूंढता है। एक आलसी निर्माता बस उसे देखता है और कहता है, "दिखने में मज़बूत है।"
• निष्कर्ष: gvisor के पास लगातार बग्स खोजने के लिए एक समर्पित टीम है। Firecracker और libkrun के पास इस तरह के स्ट्रेस टेस्टिंग का कोई सार्वजनिक रिकॉर्ड नहीं है।

---

तीन बड़े आश्चर्य

लेखकों ने केवल रैंकिंग नहीं दी; उन्होंने तीन प्रमुख पैटर्न भी पाए जो सामान्य धारणाओं का खंडन करते हैं।

1. "ब्रांड" सुरक्षा की गारंटी नहीं देता
लोग मानते हैं कि यदि प्लेपेन किसी प्रसिद्ध कंपनी (जैसे Firecracker के लिए AWS या gvisor के लिए Google) द्वारा बनाया गया है, तो वह स्वतः ही सुरक्षित है।

• वास्तविकता: प्लेपेन का प्रकार ब्रांड से अधिक महत्वपूर्ण है।
  • MicroVMs (जैसे arrakis, e2b, microsandbox) एक बच्चे को एक अलग, छोटे घर में रखने जैसा है। वे आमतौर पर बाहर निकलने में कठिन होते हैं।
  • Containers (जैसे daytona) एक बच्चे को आपके लिविंग रूम में कार्डबोर्ड के डिब्बे में रखने जैसा है। उनसे बाहर निकलना बहुत आसान है।
  • Userspace Kernels (जैसे gvisor) एक ऐसे प्लेपेन की तरह हैं जिसमें एक बहुत ही सख्त नैनी (nanny) है जो हर हरकत पर नज़र रखती है।

2. "अपडेट" का जाल
आप दुनिया का सबसे सुरक्षित प्लेपेन खरीद सकते हैं, लेकिन यदि आप इसे कभी अपडेट नहीं करते हैं, तो यह खतरनाक हो जाता है।

• वास्तविकता: arrakis और e2b बहुत सुरक्षित इंजन का उपयोग करते हैं, लेकिन कंपनियों ने 400+ दिनों से उन्हें अपडेट नहीं किया है। वहीं, daytona एक कम सुरक्षित इंजन का उपयोग करता है, लेकिन यह हर बार नया सुरक्षा पैच आने पर स्वचालित रूप से अपडेट हो जाता है।
• सबक: एक "सुरक्षित" इंजन जो पुराना (outdated) है, वह अक्सर एक "कम सुरक्षित" इंजन से कम सुरक्षित होता है जो पूरी तरह से पैच किया गया हो।

3. "मौन" खतरा (The Silent Danger)

• वास्तविकता: microsandbox (libkrun) में शून्य रिपोर्ट की गई दुर्घटनाएं और शून्य स्ट्रेस टेस्ट हैं।
• सबक: इसका मतलब यह नहीं है कि यह सुरक्षित है; इसका मतलब है कि कोई देख नहीं रहा है। यह एक ऐसे पुल की तरह है जिसका दस साल से निरीक्षण नहीं हुआ है। बुरी खबरों का न होना अच्छी खबर नहीं है; यह केवल डेटा की कमी है। लेखक इसे "संरचनात्मक रूप से अपरिभाषित" (structurally unmeasured) कहते हैं।

---

अंतिम निर्णय: कोई एक विजेता नहीं

यह शोध पत्र किसी एक "सर्वश्रेष्ठ" प्लेपेन का नाम लेने से इनकार करता है क्योंकि यह इस पर निर्भर करता है कि आप किससे डरते हैं:

• यदि आप बच्चे के भाग जाने से डरते हैं: gvisor सबसे मजबूत है। इसमें सबसे कड़े नियंत्रण हैं, सबसे अधिक स्ट्रेस टेस्टिंग है, और कोई दर्ज की गई एस्केप नहीं है। हालाँकि, यह कुछ कार्यों के लिए बहुत प्रतिबंधात्मक हो सकता है (नैनी बहुत सख्त है)।
• यदि आप बच्चे के जासूसी करने से डरते हैं: e2b और microsandbox सबसे अच्छे हैं। वे घर के रहस्यों को पूरी तरह से छिपा देते हैं।
• यदि आप अपडेट करना भूल जाने से डरते हैं: daytona और gvisor सबसे अच्छे हैं। वे खुद को अपडेट रखते हैं।
• यदि आप "गोल्ड स्टैंडर्ड" (उच्च सुरक्षा + निरंतर परीक्षण) चाहते हैं: ऐसा अभी तक अस्तित्व में नहीं है। लेखकों ने पाया कि कोई भी एक उत्पाद सबसे मजबूत अलगाव (MicroVM) और सबसे मजबूत परीक्षण (Continuous Fuzzing) को एक साथ नहीं जोड़ता है। आपको एक या दूसरे को चुनना होगा।

ऑपरेटर के लिए सारांश

• लेबल पर भरोसा न करें: सिर्फ इसलिए कि एक सैंडबॉक्स को "सुरक्षित" कहा जाता है, इसका मतलब यह नहीं है कि वह अपडेटेड है।
• अपडेट की जाँच करें: यदि आपके सैंडबॉक्स को अपडेट हुए एक साल हो गया है, तो वह असुरक्षित हो सकता है, भले ही उसका इंजन अच्छा हो।
• अपने खतरे को पहचानें: यदि आप AI के भाग जाने से चिंतित हैं, तो gvisor चुनें। यदि आप अपने डेटा की चोरी से चिंतित हैं, तो e2b या microsandbox चुनें। यदि आप रखरखाव (maintenance) को लेकर चिंतित हैं, तो daytona चुनें (लेकिन स्वीकार करें कि इससे भागना आसान है)।
• "शून्य" के जाल से बचें: यदि किसी उत्पाद में शून्य रिपोर्ट की गई त्रुटियां और शून्य परीक्षण हैं, तो मान लें कि वह अन-टेस्टेड (untested) है, न कि परफेक्ट।