Windows पर Codex सक्षम करने के लिए एक सुरक्षित, प्रभावी सैंडबॉक्स बनाना

जब मैं सितंबर 2025 में Codex इंजीनियरिंग टीम में शामिल हुआ, तब Windows के लिए Codex में सैंडबॉक्स इम्प्लीमेंटेशन नहीं था. इसका मतलब यह था कि OpenAI के कोडिंग एजेंट इस्तेमाल करते समय Windows उपयोगकर्ताओं को दो कमतर विकल्पों में से चुनना पड़ता था:

1. कोडिंग एजेंट द्वारा चलाए जाने वाले लगभग हर कमांड (यहां तक कि रीड कमांड) को मंजूरी देना, जो कि अक्षम और कष्टदायक है. Codex का उपयोग करने का एक बड़ा फ़ायदा यह है कि आपको सारा थकाऊ काम खुद नहीं करना पड़ता.
2. फुल एक्सेस मोड सक्षम करना: Codex को बिना मंजूरी या प्रतिबंधों के सभी कमांड चलाने देना, जिससे निगरानी की कीमत पर रुकावट कम हो जाती है.

Codex⁠, हमारा कोडिंग एजेंट, डेवलपर लैपटॉप पर चलता है, चाहे वह CLI, IDE एक्सटेंशन, या डेस्कटॉप ऐप के जरिए हो. यह इन्फ़रेंस को संभालने के लिए क्लाउड में चल रहे मॉडल और कीबोर्ड पर मौजूद मानव के बीच बातचीत को प्रबंधित करता है.

डिफ़ॉल्ट रूप से Codex वास्तविक उपयोगकर्ता की अनुमतियों के साथ चलता है, यानी वह वह सब कर सकता है जो उपयोगकर्ता कर सकता है. यह शक्तिशाली है और संभावित रूप से खतरनाक भी. कोडिंग मॉडल हार्नेस को स्थानीय रूप से कमांड चलाने के लिए कह सकता है, जैसे टेस्ट चलाना, कोई फ़ाइल पढ़ना या संपादित करना, या Git ब्रांच बनाना. इसलिए Codex का डिफ़ॉल्ट मोड प्रभावशीलता और सुरक्षा के बीच सही संतुलन खोजने की कोशिश करता है. यह डिफ़ॉल्ट मोड Codex को लगभग कहीं भी फ़ाइलें पढ़ने और आपके वर्कस्पेस, यानी जिस डायरेक्टरी में आप Codex चला रहे हैं, के भीतर फ़ाइलें लिखने देता है, और इंटरनेट एक्सेस तब तक नहीं देता जब तक आप विशेष रूप से यह न चाहें. फ़ाइलें लिखने और सुरक्षित सीमाओं के भीतर नेटवर्क एक्सेस को स्वचालित रूप से सीमित करने के लिए Codex को ऐसे सैंडबॉक्स वातावरण की ज़रूरत होती है जो वास्तव में इन सीमाओं को लागू करे.

एक सैंडबॉक्स एक प्रतिबंधित निष्पादन वातावरण होता है. जब कोई डेवलपर Codex का उपयोग करता है, तो उसके कंप्यूटर का ऑपरेटिंग सिस्टम कम अनुमतियों के साथ एक कमांड लॉन्च करता है, और ये सीमाएं आगे प्रोसेस ट्री में फैल जाती हैं. हर Codex कमांड शुरू से ही सैंडबॉक्स्ड होती है, और हर डीसेंडेंट प्रोसेस उसी सीमा के अंदर रहती है.

एक प्रभावी सैंडबॉक्स लागू करने के लिए Codex को कंप्यूटर के ऑपरेटिंग सिस्टम द्वारा लागू की गई आइसोलेशन सुविधाओं की ज़रूरत होती है. कुछ ऑपरेटिंग सिस्टम इसके लिए अच्छी उपयोगिताएं देते हैं, (जैसे MacOs पर Seatbelt और Linux पर seccomp या bubblewrap); हालांकि, Windows अभी इस प्रकार की क्षमता बॉक्स से बाहर उपलब्ध नहीं कराता.

Windows पर Codex को उतना ही सुरक्षित और उपयोग में आनंददायक बनाने के लिए, जितना वह पहले से अन्य जगहों पर है, हमें अपना खुद का सैंडबॉक्स लागू करना पड़ा.

Windows आइसोलेशन के लिए कुछ टूल और प्रिमिटिव देता है. हालांकि इनमें से कोई भी हमारी आवश्यकताओं को पूरी तरह पूरा नहीं करता था, हमने कई संभावित समाधानों पर विचार किया, यानी AppContainer, Windows Sandbox, और Mandatory Integrity Control लेबलिंग.

AppContainer

• क्या: AppContainer मूल Windows सैंडबॉक्स है, एक क्षमता-आधारित आइसोलेशन मॉडल जो उन ऐप्स के लिए बनाया गया है जिन्हें पहले से ठीक-ठीक पता हो कि उन्हें किस चीज़ तक पहुंच चाहिए.
• क्यों: आकर्षक इसलिए क्योंकि यह बेस्ट-एफर्ट प्रतिबंधों के बजाय वास्तविक OS सीमा देता है.
• क्यों नहीं: Codex कोई एक बहुत सीमित दायरे वाला ऐप नहीं है. यह ओपन-एंडेड डेवलपर वर्कफ़्लो को संचालित करता है: शेल्स, Git, Python, पैकेज मैनेजर्स, बिल्ड टूल्स, और ऐसी कोई भी अन्य बाइनरीज़ जिनकी ज़रूरत एजेंट तय करता है. व्यवहार में, इससे AppContainer इस समस्या के लिए अनुपयुक्त साबित हुआ. यह मजबूत आइसोलेशन था, लेकिन “किसी एजेंट को डेवलपर की तरह काम करने देना” की तुलना में वर्कलोड के कहीं अधिक सीमित वर्ग के लिए था.

Windows Sandbox

• क्या: Windows Sandbox Microsoft की डिस्पोज़ेबल हल्की VM है. आपको मजबूत आइसोलेशन सीमा के साथ एक नया Windows डेस्कटॉप मिलता है, और सत्र समाप्त होने पर उसके भीतर किया गया सब कुछ गायब हो जाता है.
• क्यों: स्पष्ट कारणों से दिलचस्प. यह AppContainer की तुलना में मनमाने सॉफ़्टवेयर के साथ कहीं अधिक संगत है, और सुरक्षा के नज़रिए से यह बहुत अधिक मजबूत ढांचा है.
• क्यों नहीं: Codex को उपयोगकर्ता के वास्तविक चेकआउट, टूल और वातावरण पर सीधे काम करना होता है, न कि किसी अलग अस्थायी डेस्कटॉप के भीतर, जिसे सेटअप और होस्ट/गेस्ट ब्रिजिंग की ज़रूरत पड़े. इसमें एक मूलभूत उत्पाद समस्या भी थी: Windows Sandbox, Windows Home SKUs पर उपलब्ध ही नहीं है.

Mandatory Integrity Control (MIC) इंटेग्रिटी लेबलिंग

• क्या: Windows में “अखंडता स्तर” नामक एक अवधारणा होती है, जैसे निम्न, मध्यम और उच्च, जो यह निर्धारित करती है कि सिस्टम ऑब्जेक्ट्स और प्रक्रियाओं पर कितना भरोसा करता है. मूल नियम यह है कि कोई निम्न-अखंडता प्रक्रिया उच्च अखंडता स्तर वाले ऑब्जेक्ट में लिख नहीं सकती, भले ही सामान्य ACL अन्यथा इसकी अनुमति देती हो. उदाहरण के लिए, किसी निम्न-अखंडता प्रक्रिया को कम विश्वसनीय माना जाता है, इसलिए Windows उसे सामान्य मध्यम-अखंडता ऑब्जेक्ट्स में लिखने से रोकता है, जब तक कि उन ऑब्जेक्ट्स को इसकी अनुमति देने के लिए स्पष्ट रूप से फिर से लेबल न किया गया हो.
• क्यों: कागज़ पर MIC सुंदर लगा—Codex को लो-इंटेग्रिटी पर चलाएं, राइटेबल रूट्स को लो-इंटेग्रिटी के रूप में रीलेबल करें, और बाकी हर जगह नो-राइट्स को Windows से लागू करवाएं. इससे हमें एक गैर-एडमिन तरीका मिल जाता, जिसे एक वास्तविक OS तंत्र का समर्थन प्राप्त होता.
• क्यों नहीं: ACLs की तरह, अखंडता लेबल वास्तविक होस्ट फ़ाइल सिस्टम को संशोधित करते हैं, और इस मामले में अर्थगत बदलाव विशेष रूप से व्यापक है. किसी वर्कस्पेस को कम इंटेग्रिटी वाला मार्क करने का मतलब सिर्फ़ यह नहीं है कि “Codex यहाँ लिख सकता है.” इसका मतलब है कि सामान्य तौर पर कम अखंडता वाली प्रक्रियाएं वहां लिख सकती हैं. किसी वास्तविक डेवलपर मशीन पर, यह उपयोगकर्ता के वास्तविक चेकआउट को होस्ट के लिए एक निम्न-अखंडता सिंक में बदल देता है, जो किसी एक सैंडबॉक्स डिज़ाइन को सावधानीपूर्वक लक्षित ACLs देने की तुलना में कहीं अधिक जोखिमपूर्ण है. भले ही मध्यम-इंटीग्रिटी डेवलपर टूल्स काम करना जारी रखें, वर्कस्पेस का अंतर्निहित ट्रस्ट मॉडल ऐसे तरीके से बदल गया है जिसे नियंत्रित करना कठिन और उचित ठहराना उससे भी कठिन है.

सभी विकल्पों को अनुपयुक्त मानने के बाद, हमने Windows उपयोगकर्ताओं के लिए अच्छा Codex अनुभव लाने हेतु अपना समाधान डिज़ाइन करना शुरू किया.

हमारे पहले कार्यशील प्रोटोटाइप ने हमें जिस आइसोलेशन की आवश्यकता थी, उसे लागू करने के लिए Windows की अवधारणाओं और टूल्स के संयोजन का उपयोग किया. शुरुआत से ही, एक लक्ष्य यह था कि यह elevation की ज़रूरत के बिना काम करे, यानी Codex को सिर्फ़ सैंडबॉक्स सेट अप करने या चलाने के लिए यूज़र से एडमिनिस्ट्रेटर विशेषाधिकारों के लिए प्रॉम्प्ट करने की ज़रूरत न पड़े. इसका मतलब था यह तय करना कि दो चीज़ों पर उचित सीमाएँ कैसे लगाई जाएँ: फ़ाइल लिखने की कार्रवाइयाँ और नेटवर्क ऐक्सेस.

अगर हम फ़ाइल राइट्स को बिल्कुल सीमित न करते, तो सुरक्षा समस्या होती. अगर हम फ़ाइल राइट्स को बहुत अधिक सीमित कर देते, तो सैंडबॉक्स उपयोगकर्ता उत्पादकता को नुकसान पहुंचाता और लगातार मंजूरी मांगता. इस समस्या को हल करने के लिए हमने Windows के दो महत्वपूर्ण बिल्डिंग ब्लॉक्स पर भरोसा किया: SIDs और राइट-रिस्ट्रिक्टेड टोकन्स.

SID, या सुरक्षा पहचानकर्ता, वह पहचान है जिसे Windows अनुमतियों से संबद्ध करता है. हर उपयोगकर्ता के पास एक SID होता है, समूहों के पास SID होते हैं, और यहाँ तक कि एकल लॉगिन सत्र को भी अपना अलग SID मिलता है. उदाहरण के लिए, किसी वर्तमान लॉग-इन सत्र में S-1-5-5-X-Y जैसा SID हो सकता है. स्थानीय प्रशासक समूह को असाइन किया गया SID S-1-5-32-544 हो सकता है.

Windows आपको सिंथेटिक SIDs बनाने की भी अनुमति देता है, जो किसी वास्तविक उपयोगकर्ता से संबंधित नहीं होते, लेकिन फिर भी ACLs, यानी एक्सेस कंट्रोल लिस्ट्स, में दिख सकते हैं, जो यह परिभाषित करती हैं कि कौन विशेष फ़ाइलों या डायरेक्टरीज़ को पढ़, लिख या एक्ज़िक्यूट कर सकता है. इससे SIDs हमारे सैंडबॉक्स के लिए उपयोगी प्रिमिटिव बन जाते हैं: हम Codex सैंडबॉक्स के उपयोग के लिए विशेष रूप से SIDs बना सकते हैं, बिना मशीन की किसी अन्य चीज़ में हस्तक्षेप किए.

प्रोसेस टोकन Windows में सुरक्षा ऑब्जेक्ट होते हैं, जो किसी चल रही प्रोसेस के लिए पहचान और विशेषाधिकार परिभाषित करते हैं. वे निर्धारित करते हैं कि कोई प्रक्रिया कौन-सी कार्रवाइयाँ कर सकती है. राइट-प्रतिबंधित टोकन एक विशेष प्रकार का प्रोसेस टोकन है, जिसके कारण Windows राइट ऑपरेशनों पर एक अतिरिक्त एक्सेस जाँच करता है.

किसी राइट के सफल होने के लिए दो चेक्स पास होने चाहिए:

1. सामान्य उपयोगकर्ता पहचान, यानी टोकन “owner”, को ऐसा करने की अनुमति होनी चाहिए
2. टोकन की रिस्ट्रिक्टेड SID सूची में कम से कम एक SID को भी एक्सेस दिया गया होना चाहिए

व्यवहार में, इन चेक्स ने हमें ACLs का उपयोग करके ठीक-ठीक यह परिभाषित करने दिया कि सैंडबॉक्स फ़ाइलसिस्टम में कहां बदलाव कर सकता है, जिससे राइट ऑपरेशन्स के लिए हमें आवश्यक सूक्ष्मता मिली.

SIDs और राइट-रिस्ट्रिक्टेड टोकन्स के साथ, हमारा अनएलेवेटेड सैंडबॉक्स इस तरह काम करता था:

1. सैंडबॉक्स सेटअप ने sandbox-write नाम का एक सिंथेटिक SID बनाया.
2. sandbox-write SID को लिखने, निष्पादित करने और हटाने की पहुँच दी गई
   1. वर्तमान कार्यशील निर्देशिका
   2. config.toml में कॉन्फ़िगर किए गए कोई भी अतिरिक्त writable_roots.
3. सैंडबॉक्स सेटअप ने उसी SID को “writable के भीतर read-only” स्थानों पर write एक्सेस से स्पष्ट रूप से वंचित किया, जैसे:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex ने कमांड्स को ऐसे राइट-रिस्ट्रिक्टेड टोकन के अंतर्गत लॉन्च किया जिसकी रिस्ट्रिक्टेड SID सूची में Everyone, वर्तमान लॉग्ड-इन सेशन SID, और sandbox-write सिंथेटिक SID शामिल थे.

इस प्रवाह ने फ़ाइल राइट्स को सीमित करने की समस्या को प्रभावी रूप से हल किया और आशाजनक लगा. अब हमें सैंडबॉक्स की नेटवर्क एक्सेस सीमित करने के लिए समाधान चाहिए था.

नेटवर्क एक्सेस को सीमित करना सैंडबॉक्स का एक महत्वपूर्ण हिस्सा है. इसके बिना, दुर्भावनापूर्ण कोड मशीन से डेटा इंटरनेट पर बाहर भेज सकता है. क्योंकि हम एलेवेशन की आवश्यकता से बचना चाहते थे, हमारे पास नेटवर्क ट्रैफ़िक को मज़बूती से रोकने के सीमित विकल्प थे. जिन टूल्स का हम उपयोग करना चाहते थे, जैसे Windows Firewall, उन्हें आम तौर पर एडमिन परमिशन्स के बिना इंस्टॉल नहीं किया जा सकता था.

Windows फ़ायरवॉल विकल्प उपलब्ध न होने के कारण, हमने अपने नियंत्रण के दायरे को सीमित कर दिया. हमने चाइल्ड एनवायरनमेंट को उन प्रकार के नेटवर्क-आधारित टूल्स के लिए fail-closed बनाने की कोशिश की, जिनका डेवलपर वास्तव में उपयोग करते हैं, ताकि Git कमांड, पैकेज इंस्टॉलर आदि सैंडबॉक्स में विफल हो जाएँ और उपयोगकर्ता को इंटरनेट-फेसिंग किसी भी ऑपरेशन को स्वीकृति देनी पड़े. विचार यह था कि बच निकलने के स्पष्ट रास्तों को जानबूझकर निष्प्रभावी कर दिया जाए: प्रॉक्सी-सक्षम ट्रैफ़िक को किसी बंद एंडपॉइंट पर भेजना, Git के HTTP(S) ट्रांसपोर्ट से भी यही करवाना, और SSH पर Git को तुरंत विफल कर देना. इसके अलावा, हमने PATH की शुरुआत में एक छोटी denybin डायरेक्टरी जोड़ दी और PATHEXT का क्रम बदल दिया, ताकि स्टब SSH और SCP स्क्रिप्ट वास्तविक बाइनरीज़ से पहले रिज़ॉल्व हों.

उदाहरण के लिए, नेटवर्क एक्सेस सीमित करने के लिए हमने कुछ विशिष्ट एनवायरनमेंट ओवरराइड्स का उपयोग किया:

• HTTPS_PROXY=http://127.0.0.1:9
• ALL_PROXY=http://127.0.0.1:9
• GIT_HTTPS_PROXY=http://127.0.0.1:9
• NO_PROXY=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

इससे सामान्य टूल-चालित ट्रैफ़िक का बड़ा हिस्सा पकड़ा गया, लेकिन यह फिर भी केवल सलाहकारी था. कोई प्रोसेस एनवायरनमेंट को अनदेखा कर सकता था, PATH को बायपास कर सकता था, या सीधे सॉकेट्स खोल सकता था. यह बहुत जोखिमभरा था.

जैसा कि किसी भी रोचक सॉफ़्टवेयर कार्यान्वयन के साथ होता है, पहले प्रोटोटाइप के कुछ फायदे और कुछ नुकसान थे. हालांकि यह केवल कुछ मानक Windows क्षमताओं के साथ काम कर गया, बहुत स्पष्ट और सूक्ष्म फ़ाइलसिस्टम राइट्स की अनुमति देता था, और अनएलेवेटेड चलता था—जिससे उपयोगकर्ताओं को अत्यधिक एलेवेशन प्रॉम्प्ट्स स्वीकार करने या अपनी स्थानीय मशीन पर एडमिन होने की आवश्यकता कम हुई—लेकिन इसमें कुछ वास्तविक कमियां थीं, जिनमें से कुछ ने इसे हमारा अंतिम डिज़ाइन बनने से अयोग्य कर दिया:

• सेटअप की गति: वर्कस्पेस ACLs लागू करना वर्कस्पेस डायरेक्टरी की संरचना पर निर्भर करते हुए महंगा हो सकता है.
• फुटप्रिंट: हमने डेवलपर के सिस्टम पर वास्तविक ACLs लागू किए, हालांकि यह फुटप्रिंट खास तौर पर हस्तक्षेपकारी नहीं है क्योंकि सभी लागू ACLs एक कस्टम-निर्मित synthetic SID से संबंधित हैं जिसका उपयोग केवल सैंडबॉक्स करता है.
• बदलने में कठिन सेमांटिक्स: फ़ाइल-आधारित प्रतिबंधों के लिए ACLs पर निर्भरता का मतलब है कि सैंडबॉक्स सेमांटिक्स को बदलना महंगा और जटिल है. जबकि macOS पर, हम यह गतिशील रूप से बदल सकते हैं कि हम .sbpl कैसे जनरेट करते हैं Seatbelt को कॉन्फ़िगर करने के लिए उपयोग की जाने वाली फ़ाइल के कारण, Windows sandbox को ACLs समायोजित करने के लिए धीमे और संसाधन-गहन ऑपरेशन की आवश्यकता हो सकती है.
• नेटवर्क सुरक्षा कमज़ोर है. जैसा पहले बताया गया, यह “advisory” थी, कुछ प्रोग्राम जो अपना नेटवर्किंग स्टैक लागू करते थे, उसे निश्चित रूप से दरकिनार कर देते, और इसे प्रतिकूल कोड के सामने टिकने के लिए डिज़ाइन नहीं किया गया था.

पहली तीन समस्याएं ऐसे कस्टम सैंडबॉक्स इम्प्लीमेंटेशन में निहित हैं जो एजेंटिक फ्लोज़ के लिए पर्याप्त लचीला हो. हालांकि नेटवर्क सप्रेशन की कहानी अलग थी.

दुर्भावनापूर्ण एजेंट द्वारा एनवायरनमेंट-आधारित नेटवर्क सप्रेशन को आसानी से दरकिनार किए जाने के अलावा, बहुत-सा नेक इरादे वाला कोड या बाइनरीज़ भी इसे केवल इसलिए दरकिनार कर देते क्योंकि वे एनवायरनमेंट प्रॉक्सी वेरिएबल्स का सम्मान नहीं करते, या अपना सॉकेट-आधारित नेटवर्क कोड लागू करते. हमें लगा कि यह पहलू ही बेहतर सैंडबॉक्स मोड में निवेश करने के लिए पर्याप्त है.

बेहतर नेटवर्क सप्रेशन पाने के लिए हम Windows Firewall का उपयोग करना चाहते थे, जो हमें उपयोगकर्ताओं या प्रोग्रामों के लिए आउटबाउंड नेटवर्क ट्रैफ़िक ब्लॉक करने देता है. दुर्भाग्य से, कुछ कारणों से हम ऐसा कार्यक्षम फ़ायरवॉल रूल प्रभावी रूप से नहीं बना सके जो केवल Codex हार्नेस द्वारा spawn किए गए कमांड्स पर लागू हो:

• Windows किसी प्रतिबंधित टोकन की गैर-प्रिंसिपल पहचान से फ़ायरवॉल नियम का मिलान करने की अनुमति नहीं देता. इसका मतलब था कि हम ऐसा फ़ायरवॉल रूल लागू नहीं कर सकते थे जो “किसी भी टोकन पर लागू हो जिसकी रिस्ट्रिक्टेड SID सूची में हमारा सिंथेटिक SID शामिल हो.”
• हालांकि हम ऐसा फ़ायरवॉल रूल बना सकते थे जो किसी विशिष्ट बाइनरी से मैच करे, इससे हम केवल codex.exe की नेटवर्किंग सीमित कर सकते थे. यह उन प्रोसेस पर लागू नहीं होगा जिन्हें एजेंट उपयोगकर्ता की ओर से शुरू करता है, जैसे Git या Python प्रोसेस.
• अन्य फ़ायरवॉल मिलान आयामों की संरचना भी गलत थी. उपयोगकर्ता-स्कोप वाले नियम, बिना उन्नत विशेषाधिकार वाले डिज़ाइन में, अब भी वास्तविक Windows उपयोगकर्ता से मेल खाते थे, केवल प्रतिबंधित चाइल्ड से नहीं. प्रोग्राम-पाथ नियम बहुत व्यापक थे: वे सामान्य रूप से codex.exe या python.exe को ब्लॉक कर सकते थे, लेकिन python.exe के इस एक सैंडबॉक्स्ड आह्वान को नहीं. पोर्ट- या पते-आधारित नियम भी पूरी तरह गलत नीति थे. उदाहरण के लिए, हम पोर्ट 443 को ब्लॉक नहीं करना चाहते थे; हम इस विशिष्ट प्रतिबंधित प्रोसेस ट्री के लिए मनमानी आउटबाउंड एक्सेस को ब्लॉक करना चाहते थे.

हमारे सैंडबॉक्स्ड कमांड्स पर विशेष रूप से फ़ायरवॉल रूल लागू करने के लिए, हमें उन्हें “वास्तविक” उपयोगकर्ता के रूप में नहीं, बल्कि एक अलग प्रिंसिपल के रूप में चलाना था. इस तरीके ने हमें एक नए रास्ते पर ला दिया, जिसमें हमने अपने “no elevation” प्रतिबंध को कुछ ढीला किया.

सैंडबॉक्स के अगले संस्करण, जो हमारा वर्तमान कार्यान्वयन है, को सेटअप के समय उच्च-स्तरीय व्यवस्थापक अनुमतियों की आवश्यकता होती है. इसलिए, मैं इसे “एलिवेटेड सैंडबॉक्स” कहता हूँ. उस सीमा पर जहाँ Codex सिस्टम पर कोई कमांड स्पॉन करता है, अधिक विशेषाधिकार वाला सैंडबॉक्स बिना अधिक विशेषाधिकार वाले सैंडबॉक्स जैसा दिखता है. यह अब भी चाइल्ड प्रोसेस को एक प्रतिबंधित टोकन के तहत चलाता है—इसी तरह एक write_restricted टोकन, जिसमें [Everyone, Logon, Synthetic]की वही प्रतिबंधित SID सूची होती है—हालाँकि, इस टोकन का प्रिंसिपल अब वास्तविक Windows यूज़र नहीं होता, बल्कि Codex द्वारा स्वयं बनाए गए दो लोकल यूज़र्स में से एक होता है:

• CodexSandboxOffline (जिसे firewall rules लक्षित करते हैं)
• CodexSandboxOnline (जिसे firewall rules लक्षित नहीं करते)

यह देखने में छोटा विवरण वास्तव में सैंडबॉक्स, कौन इसका उपयोग कर सकता है, और उसके setup तथा runtime execution की जटिलता पर बड़े प्रभाव डालता है.

यह देखने में अनएलेवेटेड प्रोटोटाइप से मिलता-जुलता है, लेकिन इसमें फ़ायरवॉल रूल्स और एक समर्पित Windows उपयोगकर्ता शामिल हैं, जो वास्तव में कमांड्स चलाता है. हालांकि, इन नई अवधारणाओं के शामिल होने का मतलब है कि कमांड्स चलाने और सुरक्षा देने से पहले सेटअप में अधिक काम करना पड़ता है.

अनएलेवेटेड सैंडबॉक्स डिज़ाइन में सेटअप स्टेप सरल था, लेकिन अपेक्षाकृत छोटा:

• ज़रूरत होने पर एक synthetic SID बनाएं
• sandbox-write सिंथेटिक SID के लिए ACLs लागू करें

हालांकि elevated sandbox को इससे अधिक काम करना होता है.

• यदि पहले से नहीं बनाया गया है, तो एक synthetic SID बनाएं
• यदि पहले से नहीं बनाए गए हैं, तो ऑनलाइन और ऑफ़लाइन सैंडबॉक्स यूज़र्स बनाएं
• नए बनाए गए यूज़र्स की क्रेडेंशियल्स को स्थानीय रूप से संग्रहित करें और Windows Data Protection API, यानी DPAPI, का उपयोग करके उन्हें ऐसे स्थान पर एन्क्रिप्ट करें जिसे सैंडबॉक्स यूज़र्स वास्तव में पढ़ न सकें
• ऐसे फ़ायरवॉल नियम बनाएं जो CodexSandboxOffline उपयोगकर्ता के लिए सभी आउटबाउंड नेटवर्क एक्सेस को ब्लॉक करें, या यदि वे पहले से मौजूद हों तो सत्यापित करें कि वे सही हैं.

सेटअप चरण में एक अतिरिक्त पेच है. Codex के सैंडबॉक्स में वास्तविक Windows यूज़र के समान रीड ऐक्सेस होना अपेक्षित है. गैर-एलिवेटेड सैंडबॉक्स में, जहाँ प्रतिबंधित टोकन का प्रिंसिपल SID Windows उपयोगकर्ता था, यह हासिल किया गया. हालाँकि, जब प्रिंसिपल एक नया CodexSandbox उपयोगकर्ता बनता है, तो यह मुफ़्त में नहीं मिलता. Windows पर कई प्रासंगिक निर्देशिकाएँ “प्रमाणित उपयोगकर्ता” को पढ़ने/निष्पादित करने की अनुमतियाँ प्रदान करेंगी. एक उल्लेखनीय उदाहरण उपयोगकर्ता की प्रोफ़ाइल डायरेक्टरी है. डिफ़ॉल्ट रूप से, Windows उपयोगकर्ता अन्य Windows उपयोगकर्ताओं की प्रोफ़ाइल डायरेक्टरियाँ नहीं पढ़ सकते, इसलिए कई परिदृश्यों में साधारण फ़ाइल पढ़ने की प्रक्रियाएँ भी विफल हो जाएँगी.

इसे संबोधित करने के लिए, हमने सैंडबॉक्स सेटअप प्रक्रिया में एक और परत जोड़ी—ऐसी परत जो सैंडबॉक्स यूज़र्स को वहां रीड ACLs देने के लिए है जहां ऐसी ACLs पहले से मौजूद नहीं हो सकतीं. उदाहरण के लिए, आमतौर पर उपयोग की जाने वाली कुछ Windows निर्देशिकाओं में:

• C:\Users\<real-user>
• C:\Windows\
• C:\Program Files\
• C:\Program Files (x86)\
• C:\ProgramData\

क्योंकि डायरेक्टरीज़ की यह सूची बेस्ट-एफर्ट है और हर एक पर ACLs इंस्टॉल करना काफी महंगा हो सकता है, हम इस लॉजिक को एसिंक्रोनस रूप से चलाते हैं ताकि सैंडबॉक्स सेटअप स्टेप, जो उपयोगकर्ताओं के लिए ब्लॉकिंग है, इनके पूरा होने की प्रतीक्षा न करे.

हमने सेटअप लॉजिक को उसकी अपनी अलग बाइनरी में समाहित किया, आंशिक रूप से इसलिए ताकि UAC सीमा को केवल आवश्यकता पड़ने पर ही पार किया जाए. लेकिन गहरा कारण आर्किटेक्चरल था: सैंडबॉक्स सेटअप का काम codex.exe से मूल रूप से अलग है. सेटअप लॉजिक को एक समर्पित बाइनरी में रखने से codex.exe एक सामान्य, अनएलेवेटेड हार्नेस बना रह सका; Windows-only सेटअप मशीनरी को अन्य प्लेटफ़ॉर्म्स पर codex.exe को फुलाने से रोका जा सका; लंबे समय तक चलने वाले सेटअप वर्क को मुख्य प्रोसेस के जीवनकाल से अलग किया जा सका; और हमें सैंडबॉक्स के विभिन्न सेटअप पाथ्स संभालने के लिए एक ही स्थान मिला.

Windows उपयोगकर्ता और टोकन लॉगिन बाउंड्रीज़ के काम करने के तरीके के कारण, हम रिस्ट्रिक्टेड टोकन बनाकर उसके अंतर्गत प्रोसेस spawn करने का वही तरीका जारी नहीं रख सके जो अनएलेवेटेड सैंडबॉक्स में संभव था. किसी अलग Windows उपयोगकर्ता के रूप में वास्तव में कमांड्स spawn करने के लिए, हमारी पहली कल्पना निम्नलिखित प्रवाह थी:

• codex.exe वास्तविक Windows उपयोगकर्ता के रूप में चलता है. फिर, क्रम में, Codex:
  • सैंडबॉक्स उपयोगकर्ता के लिए LogonUserW(...) को कॉल करता है.
  • उस sandbox-user टोकन पर CreateRestrictedToken(...) को कॉल करता है.
  • उस restricted sandbox-user टोकन का उपयोग करके, अंतिम child launch करने के लिए CreateProcessAsUserW(...) को call करता है.

व्यवहार में, वह वांछित फ़्लो काम नहीं कर पाया क्योंकि CreateProcessAsUserW(...) पर एक विशेषाधिकार संबंधी बाधा थी. इसका मतलब है कि codex.exe सैंडबॉक्स यूज़र के लिए एक प्रतिबंधित टोकन बना सकता था, लेकिन वह सीमा के वास्तविक-यूज़र वाले पक्ष से उस टोकन के साथ किसी चाइल्ड प्रोसेस को भरोसेमंद तरीके से लॉन्च नहीं कर सकता था. हमें एक ऐसी प्रक्रिया की आवश्यकता थी जो पहले से ही सैंडबॉक्स उपयोगकर्ता के रूप में चल रही हो—इससे प्रतिबंध चरण और अंतिम स्पॉन सीमा के वास्तविक-उपयोगकर्ता पक्ष के बजाय सैंडबॉक्स-उपयोगकर्ता पक्ष पर हो पाते.

उस आवश्यकता के चलते codex-command-runner.exe बना, एक नई बाइनरी जिसका एकमात्र काम एक प्रतिबंधित टोकन जारी करना और अनुरोधित कमांड को शुरू करना है. codex.exe से पूरा प्रवाह खुद कराने के बजाय, यानी वास्तविक उपयोगकर्ता → सैंडबॉक्स उपयोगकर्ता → रिस्ट्रिक्टेड टोकन → चाइल्ड प्रोसेस, हमने इस प्रवाह को दो भागों में बांट दिया:

भाग 1

• codex.exe बिना रिस्ट्रिक्टेड टोकन का उपयोग किए, सैंडबॉक्स उपयोगकर्ता के रूप में codex-command-runner.exe लॉन्च करने के लिए CreateProcessWithLogonW(...) कॉल करता है.

भाग 2

• रनर के भीतर, OpenProcessToken(GetCurrentProcess(), ...) रनर का अपना टोकन खोलता है, जो पहले से सैंडबॉक्स उपयोगकर्ता का होता है.
• रनर सैंडबॉक्स लॉगऑन SID निकालने के लिए GetTokenInformation(...) कॉल करता है, फिर अंतिम रिस्ट्रिक्टेड टोकन बनाने के लिए CreateRestrictedToken(...) कॉल करता है.
• अभी भी रनर के भीतर, वह वास्तविक चाइल्ड लॉन्च करने के लिए उस रिस्ट्रिक्टेड टोकन के साथ CreateProcessAsUserW(...) कॉल करता है.

अल्बर्ट आइंस्टीन ने कहा था, “Everything should be made as simple as possible, but no simpler.” इसी भावना में, हमारे डिज़ाइन ने हर समस्या का पर्याप्त समाधान किया. अंतिम आर्किटेक्चर में वे चार परतें हैं जिन्हें हम पहले कवर कर चुके हैं:

• codex.exe स्वयं
• codex-windows-sandbox-setup.exe सभी एलेवेटेड सेटअप-संबंधित कार्य संभालने के लिए
• codex-command-runner.exe रिस्ट्रिक्टेड टोकन कमांड्स चलाने के लिए
• चाइल्ड प्रोसेस

जब मैंने पहली बार इस प्रोजेक्ट पर काम शुरू किया, तब मुझे इस बात का मजबूत अंदाज़ा नहीं था कि यह अंततः कहां पहुंचेगा. मेरा तरीका यह था कि Codex और ऑपरेटिंग सिस्टम के बीच की सीमा पर सैंडबॉक्सिंग कैपेबिलिटी को इंस्ट्रूमेंट करने से शुरुआत की जाए. यह तरीका MacOS और Linux पर Codex के सैंडबॉक्स के इम्प्लीमेंटेशन से काफ़ी मेल खाता है.

जैसे-जैसे मैंने Windows द्वारा दिए जाने वाले विशिष्ट टूल्स के बारे में अधिक सीखा, और सुरक्षा तथा उपयोग में आसानी के बीच संतुलन बनाने वाले दर्जनों निर्णय लिए, सिस्टम अपने वर्तमान रूप तक बढ़ता गया: कई बाइनरीज़, कस्टम यूज़र्स, फ़ायरवॉल रूल्स, एक एलेवेटेड सेटअप स्टेप, एसिंक्रोनस प्रोसेसेस, और बहुत कुछ.

यह विशेष रूप से सरल सिस्टम नहीं है, लेकिन जटिलता का हर हिस्सा आवश्यकता के कारण जोड़ा गया, ताकि ऐसा सैंडबॉक्स बनाया जा सके जो सुरक्षित भी हो और जहां तक संभव हो, उपयोगकर्ता के रास्ते में न आए.

Windows पर Codex उपयोगकर्ताओं के लिए अच्छा उपयोगकर्ता अनुभव देने की दिशा में काम करते हुए, हमारा लक्ष्य कुछ ऐसा बनाना था जो सुरक्षित हो और उपयोगिता से समझौता न करे. Codex का पूरा उद्देश्य यह है कि एजेंट आपके निरंतर ध्यान के बिना काम कर सकें.

इस प्रोजेक्ट से मिली सबसे बड़ी सीखों में से एक यह थी कि Windows ने हमें ऐसा कोई एक प्रिमिटिव नहीं दिया जो साफ़ तौर पर “सुरक्षित स्वायत्त कोडिंग एजेंट” पर मैप हो. हमने कई टूल्स और अवधारणाओं को जोड़कर कुछ सुसंगत बनाया. कुछ शुरुआती विचार डेड एंड्स साबित हुए. अंतिम डिज़ाइन पहले के प्रोटोटाइप्स का एक हाइब्रिड था, जिनमें से हर एक ने समस्या का कोई हिस्सा हल किया था.

दूसरी सीख यह थी कि कोडिंग एजेंट की सुरक्षा, अधिक पारंपरिक एप्लिकेशन सिक्योरिटी से अलग किस्म की चीज़ है. Codex को वास्तविक डेवलपर वर्कफ़्लो के लिए काम करना होता है. इंजीनियरिंग कार्य एजेंटिक वर्कलोड्स के साथ संगतता और वास्तविक एन्फोर्समेंट के बीच संतुलन बनाने का था. इसी तनाव ने अंतिम डिज़ाइन में समझौतों को आकार दिया.

Codex सैंडबॉक्स को काम करते हुए देखने के लिए उत्सुक हैं? इसे आज़माएँ⁠.