Windows वर Codex सक्षम करण्यासाठी सुरक्षित, प्रभावी सँडबॉक्स तयार करणे

मी सप्टेंबर 2025 मध्ये Codex अभियांत्रिकी संघात सामील झालो तेव्हा, Windows साठी Codex मध्ये सँडबॉक्स अंमलबजावणी नव्हती, त्यामुळे OpenAI च्या कोडिंग एजंट्सचा वापर करताना Windows युझर्सना दोन कमी दर्जाच्या पर्यायांपैकी एक निवडावा लागत होता:

1. कोडिंग एजंटला चालवायच्या असलेल्या जवळजवळ प्रत्येक कमांडला (अगदी रीड्सना सुद्धा) मंजुरी देणे, हे अकार्यक्षम आणि त्रासदायक आहे. Codex वापरण्याचा एक मोठा फायदा म्हणजे तुम्हाला सर्व किचकट काम स्वतः करावे लागत नाही.
2. पूर्ण अ‍ॅक्सेस मोड सक्षम करणे: Codex ला कोणत्याही मंजुरी किंवा निर्बंधांशिवाय सर्व कमांड चालवण्याची परवानगी देणे, ज्यामुळे देखरेखीच्या बदल्यात अडथळे दूर होतात.

Codex⁠, आमचा कोडिंग एजंट, डेव्हलपरच्या लॅपटॉपवर चालतो—मग तो CLI, IDE एक्सटेंशन किंवा डेस्कटॉप ॲपद्वारे असो. अनुमान हाताळण्यासाठी, हे कीबोर्ड वापरणारा मानव आणि क्लाउडमध्ये चालणारे मॉडेल यांच्यातील संभाषण व्यवस्थापित करते.

Codex डीफॉल्टनुसार एका खऱ्या युझरच्या परवानग्यांसह चालतो, म्हणजेच युझर जे काही करू शकतो ते सर्व तो करू शकतो. ही एक शक्तिशाली आणि संभाव्यतः धोकादायक गोष्ट आहे. कोडिंग मॉडेल हार्नेसला स्थानिक पातळीवर कमांड्स चालवण्यास सांगू शकते, जसे की टेस्ट्स चालवणे, फाईल वाचणे किंवा संपादित करणे आणि गिट ब्रांच तयार करणे. त्यामुळे, Codex चा डीफॉल्ट मोड परिणामकारकता आणि सुरक्षितता यांच्यात योग्य संतुलन साधण्याचा प्रयत्न करतो. हा डीफॉल्ट मोड Codex ला जवळजवळ कुठूनही फाईल्स वाचण्याची आणि तुमच्या वर्कस्पेसमध्ये (म्हणजे, ज्या डिरेक्टरीमध्ये तुम्ही Codex चालवत आहात) फाईल्स लिहिण्याची परवानगी देतो, मात्र तुम्ही इंटरनेट ॲक्सेस हवा आहे असे नमूद केल्याशिवाय त्याला इंटरनेट ॲक्सेस मिळत नाही. फाईल्स लिहिण्याचे आणि नेटवर्क ॲक्सेस करण्याचे हे स्वयंचलित बंधन सुरक्षित मर्यादेत साध्य करण्यासाठी, Codex ला एका सँडबॉक्स वातावरणाची आवश्यकता असते, जे प्रत्यक्षात या बंधनांची अंमलबजावणी करते.

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

प्रभावी सँडबॉक्स अंमलात आणण्यासाठी Codex ला संगणकाच्या ऑपरेटिंग सिस्टीमकडून एनफोर्स्ड आयसोलेशन फीचर्स आवश्यक असतात. काही ऑपरेटिंग सिस्टीम ही गरज चांगल्या प्रकारे पूर्ण करणारी utilities देतात, (जसे MacOs वर Seatbelt, Linux वर seccomp किंवा bubblewrap.) मात्र, Windows सध्या अशा प्रकारची क्षमता अंगभूत स्वरूपात देत नाही.

Codex ला Windows वरही इतर प्लॅटफॉर्मप्रमाणेच सुरक्षित आणि वापरण्यास आनंददायक बनवण्यासाठी, आम्हाला स्वतःचे सँडबॉक्स तयार करावे लागले.

Windows मध्येआयसोलेशनसाठी काही टूल्स आणि मूलभूत सुविधा उपलब्ध आहेत. त्यापैकी कोणतेही आमच्या गरजा पूर्णपणे पूर्ण करत नसले—तरी आम्ही AppContainer, Windows सँडबॉक्स आणि मॅन्डेटरी इंटेग्रिटी कंट्रोल लेबलिंग यांसारख्या अनेक संभाव्य उपायांचा विचार केला.

AppContainer

• काय: AppContainer हे Windows चे नेटिव्ह सँडबॉक्स आहे, जे कॅपेबिलिटी-बेस्ड आयसोलेशन मॉडेलवर आधारित असून, कोणत्या गोष्टींना ॲक्सेस आवश्यक आहे हे आधीच माहित असलेल्या ॲप्ससाठी तयार करण्यात आले आहे.
• का: आकर्षक आहे कारण ते अंदाजे लादलेल्या निर्बंधांऐवजी एक खरी OS सीमा प्रदान करते.
• का नाही: Codex हे मर्यादित व्याप्ती असलेले एकच अ‍ॅप नाही. हे मुक्त स्वरूपाचे डेव्हलपर वर्कफ्लो चालवते: शेल्स, Git, Python, पॅकेज मॅनेजर्स, बिल्ड टूल्स आणि एजंटला आवश्यक वाटणाऱ्या इतर कोणत्याही बायनरीज. प्रत्यक्ष व्यवहारात, त्यामुळे AppContainer या समस्येसाठी अयोग्य ठरले. ते सशक्त विलगीकरण होते, पण ते “एखाद्या एजंटला विकसकाप्रमाणे काम करू द्या” यापेक्षा खूपच मर्यादित वर्कलोड्सच्या वर्गासाठी होते.

Windows सँडबॉक्स

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

मँडेटरी इंटेग्रिटी कंट्रोल (MIC) इंटेग्रिटी लेबलिंग

• काय: Windows मध्ये “अखंडता पातळ्या” नावाची संकल्पना आहे, जसे की कमी, मध्यम आणि उच्च, जी सिस्टम ऑब्जेक्ट्स आणि प्रक्रियांवर किती विश्वास ठेवते हे निर्धारित करते. मूलभूत नियम असा आहे की कमी अखंडता असलेली प्रक्रिया उच्च अखंडता स्तर असलेल्या ऑब्जेक्टवर लेखन करू शकत नाही, जरी सामान्य ACL ने अन्यथा परवानगी दिली असती तरीही. उदाहरणार्थ, कमी-अखंडता प्रक्रिया कमी विश्वसनीय मानली जाते, त्यामुळे Windows तिला सामान्य मध्यम-अखंडता ऑब्जेक्ट्सवर लिहिण्यापासून अवरोधित करते, जोपर्यंत त्या ऑब्जेक्ट्सना तिला परवानगी देण्यासाठी स्पष्टपणे पुन्हा लेबल केलेले नसते.
• का: MIC कागदावर आकर्षक दिसत होते—Codex ला कमी इंटिग्रिटीवर चालवणे, राइटेबल रूट्सना कमी इंटिग्रिटी म्हणून पुन्हा लेबल लावणे, आणि Windows ला इतर सर्वत्र नो-राइट्स लागू करू देणे. त्यामुळे तुम्हाला अ‍ॅडमिन अधिकारांची गरज नसलेला, आणि ज्याच्या पाठीशी खरी OS-स्तरीय यंत्रणा असती असा मार्ग मिळाला असता.
• का नाही: ACLs प्रमाणे, अखंडता लेबले वास्तविक होस्ट फाइलसिस्टममध्ये बदल करतात, आणि या बाबतीत अर्थविषयक बदल विशेषतः व्यापक आहे. वर्कस्पेसला कमी इंटेग्रिटी म्हणून चिन्हांकित करणे म्हणजे फक्त “Codex येथे लिहू शकते” असे नाही. याचा अर्थ असा की कमी-इंटेग्रिटी प्रक्रिया सर्वसाधारणपणे तेथे लिहू शकतात. प्रत्यक्ष डेव्हलपर मशीनवर, त्यामुळे वापरकर्त्याचे वास्तविक checkout हे होस्टसाठी low-integrity sink मध्ये बदलते, जे एका sandbox design ला काळजीपूर्वक लक्ष्यित ACLs देण्यापेक्षा खूपच अधिक जोखमीचे आहे. मध्यम-इंटेग्रिटी डेव्हलपर टूल्स काम करणे सुरू ठेवले तरी, वर्कस्पेसचे अंतर्निहित विश्वास मॉडेल अशा प्रकारे बदलले आहे की ते नियंत्रित ठेवणे कठीण आणि त्याचे समर्थन करणे त्याहूनही कठीण आहे.

सर्व पर्याय अव्यवहार्य ठरल्याने, Windows युझर्सना एक चांगला Codex अनुभव देण्यासाठी आम्ही आमच्या स्वतःच्या उपायाची रचना करण्यास सुरुवात केली.

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

जर आम्ही फाईल राईट्सवर अजिबात मर्यादा घातली नसती, तर सुरक्षेची समस्या निर्माण झाली असती. जर आम्ही फाईल राईट्सवर खूप जास्त मर्यादा घातली असती, तर सतत परवानगी मागावी लागल्याने सँडबॉक्समुळे युझरच्या उत्पादकतेवर परिणाम झाला असता. ही समस्या सोडवण्यासाठी, आम्ही Windows च्या दोन महत्त्वाच्या मूलभूत घटकांवर अवलंबून राहिलो: SID आणि राईट-रिस्ट्रिक्टेड टोकन्स.

SID, किंवा सुरक्षा ओळखकर्ता, ही Windows परवानग्यांशी जोडत असलेली ओळख आहे. प्रत्येक वापरकर्त्याकडे SID असतो, गटांकडे SID असतात आणि अगदी एका लॉगिन सत्रालाही स्वतःचा SID मिळतो. उदाहरणार्थ, सध्या लॉग-इन असलेल्या सत्राचा SID S-1-5-5-X-Y सारखा असू शकतो. स्थानिक प्रशासक गटाला नियुक्त केलेला SID S-1-5-32-544 असू शकतो.

Windows तुम्हाला असे सिंथेटिक SID तयार करण्याची परवानगी देते, जे खऱ्या युझरशी संबंधित नसतात, परंतु तरीही ACL (ॲक्सेस कंट्रोल लिस्ट्स) मध्ये दिसू शकतात. या ACL मध्ये विशिष्ट फाईल्स किंवा डिरेक्टरीज कोण रीड/राइट/एक्झिक्युट करू शकतो, हे परिभाषित केलेले असते. यामुळे SID आमच्या सँडबॉक्ससाठी एक उपयुक्त मूलभूत घटक ठरतात: आम्ही मशीनवरील इतर कोणत्याही गोष्टीमध्ये हस्तक्षेप न करता, केवळ Codex सँडबॉक्सच्या वापरासाठी SID तयार करू शकतो.

प्रोसेस टोकन हे Windows मधील सुरक्षा ऑब्जेक्ट्स असतात, जे चालू असलेल्या प्रक्रियेची ओळख आणि विशेषाधिकार परिभाषित करतात. ते एखादी प्रक्रिया कोणत्या क्रिया करू शकते हे ठरवतात. लेखन-प्रतिबंधित टोकन हा प्रक्रिया टोकनचा एक विशिष्ट प्रकार आहे, जो Windows ला लेखन ऑपरेशन्सवर अतिरिक्त प्रवेश तपासणी करायला लावतो.

राईट यशस्वी होण्यासाठी, दोन तपासण्या यशस्वी होणे आवश्यक आहे:

1. सामान्य युझरच्या ओळखीला (टोकनच्या “मालकाला”) ते करण्याची परवानगी असली पाहिजे
2. टोकनच्या रिस्ट्रिक्टेड SID सूचीमधील किमान एका SID ला देखील ॲक्सेस मंजूर करणे आवश्यक आहे

प्रत्यक्षात, या तपासण्यांमुळे आम्हाला ACL वापरून सँडबॉक्स फाईल सिस्टममध्ये नेमके कुठे बदल करू शकतो हे निश्चित करता आले, ज्यामुळे आम्हाला राईट क्रियांबाबत आवश्यक असलेली सूक्ष्मता मिळाली.

SID आणि राईट-रिस्ट्रिक्टेड टोकन्सच्या साहाय्याने, आमचा अनएलिव्हेटेड सँडबॉक्स अशा प्रकारे काम करत होता:

1. सँडबॉक्स सेटअपने sandbox-write नावाचा एक सिंथेटिक SID तयार केला.
2. sandbox-write SID ला यावर लिहिण्याचा, कार्यान्वित करण्याचा आणि हटवण्याचा प्रवेश मंजूर करण्यात आला
   1. सध्याची कार्यरत निर्देशिका
   2. config.toml मध्ये कॉन्फिगर केलेले कोणतेही अतिरिक्त writable_roots.
3. सँडबॉक्स सेटअपने त्याच SID ला, “राइटेबलमध्ये रीड ओन्ली” असलेल्या ठिकाणी राइट अ‍ॅक्सेस स्पष्टपणे नाकारला आहे, जसे की:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex ने एका राईट-रिस्ट्रिक्टेड टोकन अंतर्गत कमांड्स लाँच केल्या, ज्याच्या रिस्ट्रिक्टेड SID सूचीमध्ये प्रत्येकजण, सध्या लॉग इन असलेल्या सेशनचा SID, आणि सँडबॉक्स-राइट सिंथेटिक SID यांचा समावेश आहे.

या कार्यप्रणालीमुळे फाईल राईट्सवर मर्यादा घालण्याची समस्या प्रभावीपणे सुटली आणि ती आशादायक वाटत होती. आता आम्हाला सँडबॉक्सच्या नेटवर्क ॲक्सेसवर मर्यादा घालण्यासाठी एका उपायाची गरज होती.

नेटवर्कचा वापर मर्यादित करणे हा सँडबॉक्सचा एक महत्त्वाचा भाग आहे; त्याशिवाय, दुर्भावनापूर्ण कोड मशीनमधून इंटरनेटवर डेटा पाठवू शकतो. आम्हाला प्रशासकीय अधिकारांची आवश्यकता टाळायची असल्यामुळे, नेटवर्क ट्रॅफिकला कठोरपणे रोखण्यासाठी आमच्याकडे मर्यादित पर्याय होते. आम्हाला वापरायची असलेली टूल्स, जसे की Windows Firewall, सामान्यतः प्रशासकीय परवानगीशिवाय इनस्टॉल केली जाऊ शकत नव्हती.

Windows Firewall हा पर्याय उपलब्ध नसल्यामुळे, आम्ही काय नियंत्रित करू शकतो यावर मर्यादा आल्या. डेव्हलपर प्रत्यक्षात वापरत असलेल्या नेटवर्क-आधारित साधनांच्या बाबतीत चाइल्ड एन्व्हायर्नमेंट ‘fail-closed’ राहील असे करण्याचा आम्ही प्रयत्न केला, जेणेकरून Git कमांड्स, पॅकेज इंस्टॉलर्स इ. सँडबॉक्समध्ये अयशस्वी ठरतील आणि इंटरनेटशी संपर्क साधणाऱ्या कोणत्याही ऑपरेशन्सना वापरकर्त्याची मंजुरी घ्यावी लागेल. कल्पना अशी होती की स्पष्ट सुटकेचे मार्ग निष्प्रभ करायचे: प्रॉक्सी-सुसंगत ट्रॅफिक निष्क्रिय एंडपॉइंटकडे पाठवायचे, Git च्या HTTP(S) ट्रान्सपोर्टकडूनही तेच करून घ्यायचे, आणि SSH वरून Git त्वरित अपयशी ठरवायचे. त्याव्यतिरिक्त, आम्ही PATH च्या सुरुवातीला एक छोटी denybin निर्देशिका जोडली आणि PATHEXT चा क्रम बदलला, जेणेकरून stub SSH आणि SCP स्क्रिप्ट्स खऱ्या बायनरींपूर्वी resolve होतील.

उदाहरणार्थ, नेटवर्क ॲक्सेस मर्यादित करण्यासाठी आम्ही वापरलेले काही विशिष्ट एन्व्हायर्नमेंट ओव्हरराइड्स खालीलप्रमाणे आहेत:

• 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 क्षमतांसह काम पूर्ण करत होते, अत्यंत स्पष्ट आणि सूक्ष्म फाईल सिस्टम राइट्सना परवानगी देत होते, आणि एलेव्हेट न करता चालत होते—ज्यामुळे युझर्सना अत्याधिक एलेव्हेशन प्रॉम्प्ट स्वीकारण्याची किंवा त्यांच्या स्थानिक मशीनवर प्रशासक असण्याची गरज कमी होत होती—तरीही त्यात काही खऱ्या उणिवा होत्या, ज्यांपैकी काहींमुळे ते आमचे अंतिम डिझाइन बनण्यास अपात्र ठरले:

• सेटअपचा वेग: वर्कस्पेस डिरेक्टरीच्या टोपोलॉजीनुसार, वर्कस्पेस ACL लागू करणे खर्चिक ठरू शकते.
• फुटप्रिंट: आम्ही डेव्हलपरच्या सिस्टीमवर वास्तविक ACLs लागू केले आहेत, तथापि त्याचा फुटप्रिंट विशेष इन्वेसिव्ह नाही कारण लागू केलेले सर्व ACLs एका खास तयार केलेल्या सिंथेटिक SID शी संबंधित आहेत, जे केवळ सँडबॉक्सद्वारे वापरले जाते.
• बदलणे कठीण असलेले सिमॅंटिक्स: फाइल-आधारित निर्बंधांसाठी ACLs वर अवलंबून राहिल्यामुळे सँडबॉक्स सिमॅंटिक्स बदलणे खर्चिक आणि गुंतागुंतीचे ठरते. याउलट, macOS वर, आम्ही .sbpl तयार करण्याची पद्धत डायनॅमिकरीत्या बदलू शकतो Seatbelt कॉन्फिगर करण्यासाठी वापरल्या जाणाऱ्या फाइलमुळे, Windows sandbox ला ACLs समायोजित करण्यासाठी संथ आणि तीव्र ऑपरेशनची आवश्यकता असू शकते.
• नेटवर्क संरक्षण कमकुवत आहे. आधी सांगितल्याप्रमाणे, ते “सल्लागार” स्वरूपाचे होते, स्वतःचा नेटवर्किंग स्टॅक वापरणाऱ्या काही प्रोग्राम्सद्वारे ते निश्चितपणे टाळले गेले असते, आणि ते ऍडव्हर्सरियल कोडचा सामना करण्यासाठी तयार केलेले नव्हते.

पहिले तीन मुद्दे हे एजंटिक फ्लोसाठी पुरेसे लवचिक असलेल्या कस्टम सँडबॉक्स अंमलबजावणीमध्ये अंतर्भूत आहेत. मात्र, नेटवर्क सप्रेशनची गोष्ट वेगळी होती.

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

नेटवर्कवर अधिक चांगले नियंत्रण मिळवण्यासाठी, आम्हाला Windows Firewall वापरायचा होता, जो आम्हाला युझर्स किंवा प्रोग्राम्ससाठी बाहेर जाणारी नेटवर्क ट्राफिक ब्लॉक करण्याची परवानगी देतो. दुर्दैवाने, काही कारणांमुळे, आम्ही केवळ Codex हार्नेसद्वारे सुरू केलेल्या कमांड्सना लागू होणारा एक प्रभावी फायरवॉल नियम तयार करू शकलो नाही:

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

आमच्या सँडबॉक्स केलेल्या कमांड्सवर विशेषतः फायरवॉल नियम लागू करण्यासाठी, आम्हाला त्या “खऱ्या” युझरऐवजी एका वेगळ्या प्रिन्सिपलद्वारे चालवण्याची गरज होती. या पद्धतीमुळे आम्ही एका नवीन मार्गावर आलो, ज्यामध्ये आम्ही आमचे “नो एलिव्हेशन” बंधन शिथिल केले.

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

• CodexSandboxOffline (फायरवॉल नियमांद्वारे लक्ष्यित केलेले)
• CodexSandboxOnline (ज्याला फायरवॉल नियम लक्ष्य करत नाहीत)

या वरवर पाहता लहान वाटणाऱ्या तपशिलाचे सँडबॉक्स, त्याचा वापर कोण करू शकतो, आणि त्याच्या सेटअप व रनटाइम एक्झिक्यूशनच्या गुंतागुंतीवर प्रत्यक्षात मोठे परिणाम होतात.

हे दिसायला अनएलिव्हेटेड प्रोटोटाइपसारखेच आहे, फक्त यात फायरवॉल नियम आणि एक स्वतंत्र Windows युझर समाविष्ट आहे, जो प्रत्यक्षात कमांड्स चालवतो. (तथापि, या नवीन संकल्पनांच्या समावेशामुळे, सँडबॉक्स कमांड्स चालवणे आणि त्यांचे संरक्षण करणे सुरू करण्यापूर्वी अधिक सेटअपचे काम करावे लागेल.)

अनएलिव्हेटेड सँडबॉक्स डिझाइनमध्ये सेटअपचा चरण सोपा होता, पण ते तुलनेने लहान होते:

• आवश्यक असल्यास सिंथेटिक SID तयार करा
• सँडबॉक्स-राइट सिंथेटिक SID साठी ACL लागू करा

मात्र, एलिव्हेटेड सँडबॉक्समध्ये करण्यासारखे बरेच काही आहे.

• सिंथेटिक SID तयार करा, जर आधीच तयार केलेला नसेल तर
• ऑनलाइन आणि ऑफलाइन सँडबॉक्स युझर्स तयार करा, जर ते आधीच तयार केलेले नसतील तर
• नवीन तयार केलेल्या युझर्सची क्रेडेन्शियल्स स्थानिक पातळीवर साठवा आणि Windows डेटा प्रोटेक्शन API (DPAPI) वापरून अशा ठिकाणी एन्क्रिप्ट करा, जिथे सँडबॉक्स युझर्स ती प्रत्यक्षात वाचू शकत नाहीत
• CodexSandboxOffline युझरसाठी सर्व बाह्य नेटवर्क अ‍ॅक्सेस ब्लॉक करणारे फायरवॉल नियम तयार करा किंवा, ते आधीच अस्तित्वात असल्यास, ते योग्य असल्याची पडताळणी करा

सेटअप टप्प्यात आणखी एक गुंतागुंत आहे. Codex च्या सँडबॉक्सला वास्तविक Windows वापरकर्त्याच्या समतुल्य वाचन प्रवेश असणे अपेक्षित आहे. उन्नत नसलेल्या सँडबॉक्समध्ये, जिथे प्रतिबंधित टोकनचा प्रिन्सिपल SID हा Windows वापरकर्ता होता, हे साध्य झाले. मात्र, प्रिन्सिपल नवीन CodexSandbox वापरकर्ता बनतो तेव्हा ते विनामूल्य मिळत नाही. Windows वरील अनेक संबंधित निर्देशिका “Authenticated Users” ला वाचन/कार्यान्वयन परवानग्या प्रदान करतील. एक उल्लेखनीय उदाहरण म्हणजे वापरकर्त्याची प्रोफाइल निर्देशिका. डीफॉल्टनुसार, Windows वापरकर्ते इतर Windows वापरकर्त्यांच्या प्रोफाइल निर्देशिका वाचू शकत नाहीत, त्यामुळे अनेक परिस्थितींमध्ये अगदी साध्या फाइल वाचन क्रियाही अयशस्वी ठरतील.

या समस्येचे निराकरण करण्यासाठी, आम्ही सँडबॉक्स सेटअप प्रक्रियेमध्ये आणखी एक स्तर जोडला आहे—तो म्हणजे सँडबॉक्स युझर्सना रीड ACL प्रदान करण्यासाठी, जिथे असे ACL कदाचित आधीपासून अस्तित्वात नसतील. उदाहरणार्थ, सामान्यपणे वापरल्या जाणाऱ्या काही Windows निर्देशिकांमध्ये:

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

ही डिरेक्टरींची यादी सर्वोत्तम प्रयत्नांवर आधारित असल्यामुळे आणि प्रत्येकावर ACL इनस्टॉल करणे खूप खर्चिक ठरू शकत असल्यामुळे, आम्ही हे लॉजिक असिंक्रोनसपणे चालवतो, जेणेकरून युझर्ससाठी ब्लॉक करणाऱ्या सँडबॉक्स सेटअपच्या चरणाला, ते पूर्ण होण्याची वाट पाहावी लागणार नाही.

आम्ही सेटअप लॉजिक त्याच्या स्वतःच्या स्वतंत्र बायनरीमध्ये समाविष्ट केले, अंशतः UAC सीमा फक्त गरज असतानाच ओलांडण्यासाठी. पण अधिक सखोल कारण आर्किटेक्चरशी संबंधित होते: सँडबॉक्स सेटअपचे कार्य codex.exe पेक्षा मूलतः वेगळे आहे. सँडबॉक्स सेटअप लॉजिक एका समर्पित बायनरीमध्ये ठेवल्यामुळे codex.exe एक सामान्य, अनएलिव्हेटेड हार्नेस म्हणून राहू शकले; केवळ Windows साठी असलेल्या सेटअप यंत्रणेला इतर प्लॅटफॉर्मवर codex.exe चा ब्लोट करण्यापासून रोखले; जास्त वेळ चालणाऱ्या सेटअपच्या कामाला मुख्य प्रोसेसच्या लाइफटाइमपासून वेगळे केले; आणि सँडबॉक्सला आवश्यक असलेल्या विविध सेटअप पाथ्सना हाताळण्यासाठी आम्हाला एकच जागा मिळाली.

Windows युझर आणि टोकन लॉगिनच्या मर्यादा ज्या प्रकारे काम करतात, त्यामुळे अनएलिव्हेटेड सँडबॉक्सप्रमाणे रिस्ट्रिक्टेड टोकन तयार करून त्याअंतर्गत प्रक्रिया सुरू करणे आम्हाला पुढे चालू ठेवता आले नाही. प्रत्यक्षात एका वेगळ्या Windows युझर म्हणून कमांड्स सुरू करण्यासाठी, आमची पहिली कल्पना खालीलप्रमाणे होती:

• codex.exe वास्तविक Windows वापरकर्ता म्हणून चालते. त्यानंतर, क्रमाने, Codex:
  • सँडबॉक्स वापरकर्त्यासाठी LogonUserW(...) कॉल करते.
  • त्या सँडबॉक्स-वापरकर्ता टोकनवर CreateRestrictedToken(...) कॉल करते.
  • त्या प्रतिबंधित sandbox-user टोकनचा वापर करून, अंतिम चाइल्ड प्रोसेस लाँच करण्यासाठी CreateProcessAsUserW(...) ला कॉल करते.

प्रत्यक्षात, तो अपेक्षित प्रवाह कार्य करू शकला नाही, कारण CreateProcessAsUserW(...) येथे विशेषाधिकारांच्या अडथळ्यामुळे तो थांबला. याचा अर्थ असा की codex.exe सँडबॉक्स वापरकर्त्यासाठी प्रतिबंधित टोकन तयार करू शकत होते, पण सीमारेषेच्या वास्तविक-वापरकर्ता बाजूवरून त्या टोकनसह चाइल्ड प्रोसेस विश्वसनीयपणे लाँच करू शकत नव्हते. आम्हाला अशी प्रक्रिया हवी होती जी सँडबॉक्स वापरकर्ता म्हणून आधीपासूनच चालू होती—यामुळे प्रतिबंध लागू करण्याचा टप्पा आणि अंतिम स्पॉन हे सीमारेषेच्या वास्तविक-वापरकर्ता बाजूऐवजी सँडबॉक्स-वापरकर्ता बाजूला होऊ शकले असते.

त्या आवश्यकतेमुळे codex-command-runner.exe ही एक नवीन बायनरी तयार झाली, ज्याचे एकमेव काम मर्यादित टोकन तयार करणे आणि विनंती केलेली कमांड सुरू करणे आहे. codex.exe ला संपूर्ण प्रक्रिया (वास्तविक युझर → सँडबॉक्स युझर → रिस्ट्रिक्टेड टोकन → चाइल्ड प्रोसेस) स्वतःच करायला लावण्याऐवजी, आम्ही ही प्रक्रिया दोन भागांमध्ये विभागली:

भाग 1

• codex.exe अद्याप रिस्ट्रिक्टेड टोकन न वापरता, सँडबॉक्स युझर म्हणून codex-command-runner.exe लाँच करण्यासाठी CreateProcessWithLogonW(...) ला कॉल करते.

भाग 2

• रनरच्या आत, OpenProcessToken(GetCurrentProcess(), ...) रनरचे स्वतःचे टोकन उघडते, जे आधीपासूनच सँडबॉक्स युझरचे असते.
• रनर सँडबॉक्स लॉगऑन SID काढण्यासाठी GetTokenInformation(...) ला कॉल करतो, त्यानंतर अंतिम रिस्ट्रिक्टेड टोकन तयार करण्यासाठी CreateRestrictedToken(...) ला कॉल करतो.
• रनरमध्येच असताना, ते खऱ्या चाइल्डला लाँच करण्यासाठी त्या रिस्ट्रिक्टेड टोकनसह CreateProcessAsUserW(...) ला कॉल करते.

Albert Einstein म्हणाले, “प्रत्येक गोष्ट शक्य तितकी सोपी केली पाहिजे, पण त्याहून सोपी नाही.” याच भावनेने, आमच्या डिझाइनने प्रत्येक समस्येचे समाधानकारकपणे निराकरण केले आहे. अंतिम आर्किटेक्चरमध्ये ते चार स्तर आहेत ज्यांची तुम्ही पूर्वी चर्चा केली आहे:

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

जेव्हा मी पहिल्यांदा हा प्रोजेक्ट हाती घेतला, तेव्हा तो अखेरीस कुठे पोहोचेल याची मला स्पष्ट कल्पना नव्हती. माझा दृष्टिकोन असा होता की, Codex आणि ऑपरेटिंग सिस्टीम यांच्या सीमेवर सँडबॉक्सिंगची क्षमता कार्यान्वित करण्यापासून सुरुवात करावी. हा दृष्टिकोन MacOs आणि Linux वर Codex चा सँडबॉक्स ज्या प्रकारे कार्यान्वित केला आहे, त्याच्याशी अगदी मिळताजुळता आहे.

Windows पुरवत असलेल्या विशिष्ट टूल्सबद्दल जसजसे मी अधिक शिकत गेलो, आणि सुरक्षा व वापरसुलभता यांचा समतोल साधणारे अनेक निर्णय घेत गेलो, तसतशी ही सिस्टीम तिच्या सध्याच्या स्वरूपात विकसित झाली—ज्यात अनेक बायनरी, कस्टम युझर्स, फायरवॉलचे नियम, एक एलिव्हेटेड सेटअप चरण, असिंक्रोनस प्रोसेस आणि बरेच काही समाविष्ट आहे.

ही काही विशेष सोपी सिस्टीम नाही, परंतु एक असा सँडबॉक्स तयार करण्यासाठी, जो सुरक्षित असेल आणि शक्यतोवर युझरच्या मार्गात येणार नाही, गरजेपोटी त्यात प्रत्येक गुंतागुंतीचा घटक जोडण्यात आला आहे.

Windows वरील Codex युझरना एक चांगला युझर अनुभव देण्यासाठी काम करत असताना, आमचे ध्येय असे काहीतरी सुरक्षित बनवणे होते जे उपयुक्ततेशी तडजोड करणार नाही—Codex वापरण्याचा मुख्य उद्देश हाच आहे की एजंट तुमच्या सततच्या देखरेखीशिवाय काम करू शकतील.

या प्रोजेक्टमधून मिळालेला सर्वात मोठा धडा हा होता की, Windows ने आम्हाला "सुरक्षित स्वायत्त कोडिंग एजंटशी" सुस्पष्टपणे जुळणारे एकही मूलभूत साधन दिले नाही. एक सुसंगत रचना तयार करण्यासाठी आम्ही अनेक टूल्स आणि संकल्पना एकत्र केल्या. सुरुवातीच्या काही कल्पना निष्फळ ठरल्या. अंतिम रचना ही पूर्वीच्या प्रोटोटाइप्सचे एक हायब्रीड रूप होते, ज्यातील प्रत्येकाने समस्येचा काही भाग सोडवला होता.

दुसरा धडा हा होता की, कोडिंग एजंटची सुरक्षा ही अधिक पारंपरिक ॲप्लिकेशन सुरक्षेपेक्षा एक वेगळीच बाब आहे. Codex ला प्रत्यक्ष डेव्हलपरच्या वर्कफ्लोनुसार काम करावे लागते. इंजिनिअरिंग काम हे एजंटच्या कार्यभारासोबतची सुसंगतता आणि प्रत्यक्ष अंमलबजावणी यांच्यात संतुलन साधण्याबद्दल होते. याच तणावाने अंतिम डिझाइनमधील तडजोडींना आकार दिला.

Codex सँडबॉक्स प्रत्यक्ष कार्यरत कसा दिसतो हे पाहण्यास उत्सुक आहात का? वापरून पहा⁠.