Windows પર Codex ને સક્ષમ કરવા માટે સુરક્ષિત, અસરકારક સેન્ડબોક્સ બનાવવું

જ્યારે હું સપ્ટેમ્બર 2025માં Codex એન્જિનિયરિંગ ટીમમાં જોડાયો, ત્યારે Windows માટે Codexમાં સેન્ડબોક્સની સુવિધા નહોતી, એટલે કે OpenAI ના કોડિંગ એજન્ટ્સનો ઉપયોગ કરતી વખતે Windows વપરાશકર્તાઓને બે નબળા વિકલ્પો વચ્ચે પસંદગી કરવી પડતી હતી:

1. કોડિંગ એજન્ટ ચલાવવા માંગતો હોય તેવી લગભગ દરેક કમાન્ડને (વાંચન કમાન્ડ્સને પણ) મંજૂરી આપવી, જે અકાર્યક્ષમ અને ઝંઝટભર્યું છે. Codex નો ઉપયોગ કરવાનો એક મોટો ફાયદો એ છે કે તમારે હવે કંટાળાભર્યું કે એકધારું કામ જાતે કરવાની જરૂર નથી.
2. Full Access મોડ સક્ષમ કરવું: Codex ને મંજૂરી અથવા પ્રતિબંધો વિના બધા કમાન્ડ્સ ચલાવવા દેવું, જે દેખરેખના ભોગે અવરોધ દૂર કરે છે.

Codex⁠, અમારો AI કોડિંગ એજન્ટ, ડેવલપરના લેપટોપ પર ચાલે છે—ચાહે તે CLI, IDE એક્સ્ટેન્શન અથવા ડેસ્કટોપ એપ દ્વારા હોય. તે ઇન્ફરન્સ સંભાળવા માટે કીબોર્ડ પર બેઠેલા માનવ અને ક્લાઉડમાં ચાલી રહેલા મોડલ વચ્ચેની વાતચીતનું સંચાલન કરે છે.

Codex ડિફૉલ્ટ રૂપે વાસ્તવિક વપરાશકર્તાની પરવાનગીઓ સાથે ચાલે છે, એટલે કે તે વપરાશકર્તા કરી શકે તે બધું કરી શકે છે. આ શક્તિશાળી અને સંભવિત રીતે જોખમી છે. કોડિંગ મોડલ હાર્નેસને સ્થાનિક રીતે કમાન્ડ્સ ચલાવવા માટે કહી શકે છે—ટેસ્ટ્સ ચલાવવાથી લઈને ફાઇલ વાંચવા અથવા સંપાદિત કરવા, Git બ્રાન્ચ બનાવવા સુધી—તેથી Codex નો ડિફૉલ્ટ મોડ અસરકારકતા અને સલામતી વચ્ચે યોગ્ય સંતુલન શોધવાનો પ્રયાસ કરે છે. આ ડિફૉલ્ટ મોડ Codex ને લગભગ ગમે ત્યાં ફાઇલો વાંચવાની અને તમારી વર્કસ્પેસમાં (એટલે કે, તમે જ્યાં Codex ચલાવી રહ્યા છો તે ડિરેક્ટરીમાં) ફાઇલો લખવાની મંજૂરી આપે છે, અને જ્યાં સુધી તમે ઇન્ટરનેટ ઍક્સેસ જોઈએ છે તે સ્પષ્ટ ન કરો ત્યાં સુધી ઇન્ટરનેટ ઍક્સેસ આપતું નથી. સુરક્ષિત સીમાઓની અંદર ફાઇલો લખવા અને નેટવર્ક ઍક્સેસ કરવાની આ આપમેળે મર્યાદા હાંસલ કરવા માટે, Codex ને એવા સેન્ડબોક્સ પર્યાવરણની જરૂર છે જે ખરેખર આ મર્યાદાઓનો અમલ કરે.

એક સેન્ડબોક્સ મર્યાદિત એક્ઝિક્યુશન પર્યાવરણ છે. જ્યારે કોઈ ડેવલપર Codex નો ઉપયોગ કરે છે, ત્યારે તેમના કમ્પ્યુટરની ઓપરેટિંગ સિસ્ટમ ઘટાડેલી પરવાનગીઓ સાથે એક કમાન્ડ શરૂ કરે છે, અને તે મર્યાદાઓ પ્રોસેસ ટ્રીમાં નીચે સુધી આગળ પ્રસરિત થાય છે. દરેક Codex કમાન્ડ શરૂઆતથી જ સેન્ડબોક્સમાં રાખવામાં આવે છે, અને દરેક અનુગામી પ્રોસેસ એ જ સીમાની અંદર રહે છે.

અસરકારક સેન્ડબોક્સ અમલમાં મૂકવા માટે Codex ને કમ્પ્યુટરની ઓપરેટિંગ સિસ્ટમ દ્વારા લાગુ કરાતી આઇસોલેશન સુવિધાઓની જરૂર છે. કેટલીક ઓપરેટિંગ સિસ્ટમ્સ એવી યુટિલિટીઝ પ્રદાન કરે છે જે આ કામ સારી રીતે કરે છે (જેમ કે macOS પર Seatbelt, Linux પર seccomp અથવા bubblewrap); જોકે, Windows હાલમાં ડિફૉલ્ટ રૂપે આ પ્રકારની ક્ષમતા પ્રદાન કરતું નથી.

Codex ને Windows પર વાપરવામાં બીજે બધે જેટલું સુરક્ષિત અને આનંદદાયક છે એટલું જ બનાવવા માટે, અમારે અમારું પોતાનું સેન્ડબોક્સ અમલમાં મૂકવું પડ્યું.

Windows આઇસોલેશન માટે કેટલાક ટૂલ્સ અને મૂળભૂત તત્વો પ્રદાન કરે છે. તેમાથી કોઈ પણ અમારી આવશ્યકતાઓને સંપૂર્ણપણે પૂર્ણ કરતું ન હોવા છતાં, અમે કેટલાક સંભવિત ઉકેલો પર વિચાર કર્યો—ખાસ કરીને, AppContainer, Windows Sandbox અને Mandatory Integrity Control લેબલિંગ.

AppContainer

• શું: AppContainer એ નેટિવ Windows સૅન્ડબોક્સ છે, જે એપ્સ માટે બનાવાયેલું ક્ષમતા-આધારિત આઇસોલેશન મોડલ છે, જેમને અગાઉથી જ બરાબર ખબર હોય છે કે તેમને શેની ઍક્સેસની જરૂર છે.
• શા માટે: આકર્ષક છે કારણ કે તે શ્રેષ્ઠ-પ્રયાસ આધારિત પ્રતિબંધોને બદલે વાસ્તવિક OS સીમા પ્રદાન કરે છે.
• શા માટે નહીં: Codex એ મર્યાદિત વ્યાપવાળી એપ નથી. તે ઓપન-એન્ડેડ ડેવલપર વર્કફ્લોઝને સંચાલિત કરે છે: શેલ્સ, Git, Python, પેકેજ મેનેજર્સ, બિલ્ડ ટૂલ્સ અને એજન્ટ જે અન્ય બાઇનરીઝની જરૂર છે તે નક્કી કરે છે. વ્યવહારમાં, તેના કારણે AppContainer આ સમસ્યા માટે યોગ્ય રીતે બંધબેસતું નહોતું. તે એક મજબૂત આઇસોલેશન હતું, પરંતુ તે 'એક એજન્ટને ડેવલપરની જેમ કામ કરવા દેવા' ની સરખામણીએ વર્કલોડ્સના ખૂબ જ મર્યાદિત વર્ગ માટે હતું.

વિન્ડોઝ સેન્ડબોક્સ

• શું: Windows Sandbox એ Microsoft નું નિકાલ કરી શકાય એવું લાઇટવેઇટ VM છે. તમને અલગીકરણની મજબૂત સીમા સાથેનું એક નવું Windows ડેસ્કટોપ મળે છે, અને તેની અંદર તમે જે કંઈ કરો છો તે સત્ર સમાપ્ત થાય ત્યારે અદૃશ્ય થઈ જાય છે.
• શા માટે: સ્પષ્ટ કારણોસર રસપ્રદ—AppContainer કરતાં કોઈપણ પ્રકારના સોફ્ટવેર સાથે ઘણું વધુ સુસંગત છે, અને સુરક્ષા દૃષ્ટિકોણથી તે વધુ મજબૂત અને વિશ્વસનીય છે.
• શા માટે નહીં: Codex ને વપરાશકર્તાના વાસ્તવિક ચેકઆઉટ, ટૂલ્સ અને પર્યાવરણ પર સીધું કાર્ય કરવાની જરૂર છે, કોઈ અલગ કામચલાઉ ડેસ્કટોપની અંદર નહીં, જેને સેટઅપ અને હોસ્ટ/ગેસ્ટ બ્રિજિંગની જરૂર પડે. તેમાં એક મૂળભૂત ઉત્પાદન સંબંધિત સમસ્યા પણ હતી: Windows Sandbox Windows Home SKUs પર ઉપલબ્ધ પણ નથી.

ફરજિયાત અખંડિતતા નિયંત્રણ (MIC) અખંડિતતા લેબલિંગ

• શું: Windows માં “અખંડિતતા સ્તરો” નામની એક પરિકલ્પના છે, જેમ કે નીચા, મધ્યમ અને ઊંચા, જે નક્કી કરે છે કે સિસ્ટમ ઑબ્જેક્ટ્સ અને પ્રોસેસિસ પર કેટલો વિશ્વાસ કરે છે. મૂળભૂત નિયમ એ છે કે નીચી અખંડિતતા ધરાવતી પ્રક્રિયા ઊંચા અખંડિતતા સ્તર ધરાવતા ઑબ્જેક્ટ પર લખી શકતી નથી, ભલે સામાન્ય ACL અન્યથા તેની મંજૂરી આપતી હોય. ઉદાહરણ તરીકે, ઓછી-અખંડિતતા ધરાવતી પ્રક્રિયાને ઓછી વિશ્વસનીય માનવામાં આવે છે, તેથી Windows તેને સામાન્ય મધ્યમ-અખંડિતતા ધરાવતા ઑબ્જેક્ટ્સમાં લખવાથી અવરોધે છે, જ્યાં સુધી તે ઑબ્જેક્ટ્સને તેની મંજૂરી આપવા માટે સ્પષ્ટપણે ફરીથી લેબલ કરવામાં ન આવ્યા હોય.
• શા માટે: MIC કાગળ પર સુંદર લાગતું હતું—Codex ને low integrity પર ચલાવો, લખી શકાય તેવા roots ને low integrity તરીકે ફરીથી લેબલ કરો, અને બાકી બધે Windows ને લખાણ (writes) પર પ્રતિબંધ લાગુ કરવા દો. એથી અમને તેની પાછળ વાસ્તવિક OS mechanism ધરાવતો non-admin પાથ મળ્યો હોત.
• શા માટે નહીં: ACLs ની જેમ, અખંડિતતા લેબલ્સ વાસ્તવિક હોસ્ટ ફાઇલ સિસ્ટમમાં ફેરફાર કરે છે, અને આ કિસ્સામાં અર્થાત્મક ફેરફાર ખાસ કરીને વ્યાપક છે. વર્કસ્પેસને low integrity તરીકે ચિહ્નિત કરવાનો અર્થ માત્ર “Codex અહીં લખી શકે છે” એટલો જ નથી. તેનો અર્થ એ છે કે ઓછી-અખંડિતતા પ્રક્રિયાઓ સામાન્ય રીતે ત્યાં લખી શકે છે. વાસ્તવિક ડેવલપર મશીન પર, તે યુઝરના વાસ્તવિક કોડ ચેકઆઉટને હોસ્ટ માટે low-integrity sink માં ફેરવે છે, જે એક સેન્ડબોક્સ ડિઝાઇનને કાળજીપૂર્વક લક્ષિત ACLs આપવાની સરખામણીમાં ઘણું વધુ જોખમી છે. ભલે મિડિયમ-ઇન્ટિગ્રિટી ડેવલપર ટૂલ્સ કામ કરવાનું ચાલુ રાખે, વર્કસ્પેસનું અંતર્ગત ટ્રસ્ટ મોડલ એવી રીતે બદલાઈ ગયું છે કે તેને નિયંત્રિત રાખવું મુશ્કેલ અને ન્યાયસંગત ઠેરવવું વધુ મુશ્કેલ છે.

બધા વિકલ્પોનું મૂલ્યાંકન કરીને તેઓ કારગર ન હોવાનું નક્કી કર્યા પછી, અમે Windows વપરાશકર્તાઓ સુધી સારો Codex અનુભવ પહોંચાડવા માટે અમારું પોતાનું ઉકેલ ડિઝાઇન કરવાનું શરૂ કર્યું.

અમારા પ્રથમ કાર્યરત પ્રોટોટાઇપે અમને જરૂરી આઇસોલેશન અમલમાં મૂકવા માટે Windows સંકલ્પનાઓ અને ટૂલ્સના સંયોજનનો ઉપયોગ કર્યો. શરૂઆતથી જ, એક લક્ષ્ય એ હતું કે આને એલિવેશન ની જરૂરિયાત વિના કાર્યરત કરવું, એટલે કે માત્ર સેન્ડબોક્સ સેટ અપ કરવા અથવા ચલાવવા માટે Codex ને વપરાશકર્તાને એડમિનિસ્ટ્રેટર વિશેષાધિકારો માટે પ્રોમ્પ્ટ કરવાની જરૂર ન પડે. તેનો અર્થ એ હતો કે બે બાબતો પર વ્યાજબી મર્યાદાઓ કેવી રીતે મૂકવી તે નક્કી કરવું: ફાઇલ રાઇટ્સ અને નેટવર્ક ઍક્સેસ.

જો અમે ફાઇલ લખવાની ક્રિયાઓને બિલકુલ મર્યાદિત ન કરીએ, તો સલામતીની સમસ્યા ઊભી થાય છે. જો અમે ફાઇલ લખવાની ક્રિયાઓને ખૂબ મર્યાદિત કરીએ, તો સતત મંજૂરી માંગવાની જરૂરિયાતથી સેન્ડબોક્સ વપરાશકર્તાની ઉત્પાદકતાને નુકસાન પહોંચાડશે. આ સમસ્યાને ઉકેલવા માટે, અમે Windows નાં બે મહત્વપૂર્ણ મૂળભૂત ઘટકો પર આધાર રાખ્યો: SIDs અને લખવા-પ્રતિબંધિત ટોકન.

SID, અથવા સુરક્ષા ઓળખકર્તા, એ એવી ઓળખ છે જેને Windows પરવાનગીઓ સાથે જોડે છે. દરેક વપરાશકર્તા પાસે SID હોય છે, જૂથો પાસે SIDs હોય છે, અને એક જ લૉગિન સત્રને પણ પોતાનું SID મળે છે. ઉદાહરણ તરીકે, હાલમાં લૉગ ઇન થયેલા સત્રમાં S-1-5-5-X-Y જેવું SID હોઈ શકે છે. સ્થાનિક એડમિનિસ્ટ્રેટર્સ ગ્રુપને સોંપાયેલ SID S-1-5-32-544 હોઈ શકે છે.

Windows તમને એવા સિન્થેટિક SIDs બનાવવા પણ દે છે જે વાસ્તવિક વપરાશકર્તા સાથે સંબંધિત નથી, પરંતુ તેમ છતાં ACLs (access control lists)માં દેખાઈ શકે છે, જે નિર્ધારિત કરે છે કે ચોક્કસ ફાઇલો અથવા ડિરેક્ટરીઝ કોણ વાંચી, લખી અથવા એક્ઝિક્યુટ કરી શકે છે. આથી 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 ને 'માત્ર વાંચન' તરીકે વર્ગીકૃત કરેલા અને 'લખી શકાય તેવા' સ્થાનોમાં લખવાની ઍક્સેસ સ્પષ્ટ રીતે નકારી હતી, જેમ કે:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex એ લખાણ-પ્રતિબંધિત ટોકન હેઠળ કમાન્ડ્સ લોન્ચ કર્યા, જેના પ્રતિબંધિત SID સૂચિમાં Everyone, વર્તમાનમાં લૉગ ઇન થયેલ સેશન SID અને sandbox-write સિન્થેટિક SID શામેલ છે.

આ ફ્લોએ ફાઇલમાં લખવાની કામગીરીને મર્યાદિત કરવાની સમસ્યાને અસરકારક રીતે ઉકેલી અને આશાસ્પદ લાગી. હવે અમને સેન્ડબોક્સની નેટવર્ક ઍક્સેસ મર્યાદિત કરવા માટે ઉકેલની જરૂર હતી.

નેટવર્ક એક્સેસને મર્યાદિત કરવું સેન્ડબોક્સનો એક મહત્વપૂર્ણ ભાગ છે; તે વિના, દુર્ભાવનાપૂર્ણ કોડ મશીનમાંથી ઇન્ટરનેટ પર ડેટા ચોરીને બહાર મોકલી શકે છે. કારણ કે અમે એલિવેશનની આવશ્યકતા ટાળવા માંગતા હતા, નેટવર્ક ટ્રાફિકને કડક રીતે બ્લૉક કરવા માટે અમારી પાસે મર્યાદિત વિકલ્પો હતા. અમે જે ટૂલ્સનો ઉપયોગ કરવા માગતા હતા, જેમ કે Windows Firewall, સામાન્ય રીતે એડમિન પરવાનગીઓ વિના ઇન્સ્ટોલ કરી શકાતાં નહોતાં.

Windows Firewall વિકલ્પ તરીકે ઉપલબ્ધ ન હોવાથી, અમે જેનું નિયંત્રણ કરી શકતા હતા તે મર્યાદિત કર્યું. અમે ચાઇલ્ડ એન્વાયર્નમેન્ટને ડેવલપર્સ વાસ્તવમાં ઉપયોગ કરતા નેટવર્ક-આધારિત ટૂલ્સ માટે 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 કસ્ટમ-બનાવેલ સિન્થેટિક SID સાથે સંબંધિત છે, જેનો ઉપયોગ માત્ર સેન્ડબોક્સ દ્વારા થાય છે.
• બદલવા મુશ્કેલ સેમેન્ટિક્સ: ફાઇલ-આધારિત પ્રતિબંધો માટે ACLs પરની નિર્ભરતાનો અર્થ એ છે કે સેન્ડબોક્સ સેમેન્ટિક્સ બદલવું ખર્ચાળ અને જટિલ છે. જ્યારે macOS પર, અમે .sbpl કેવી રીતે જનરેટ કરીએ છીએ તે ગતિશીલ રીતે બદલી શકીએ છીએ Seatbelt ને કન્ફિગર કરવા માટે વપરાતી ફાઇલ, Windows સેન્ડબોક્સને ACLs સમાયોજિત કરવા માટે ધીમી અને સંસાધન-ગહન પ્રક્રિયાની જરૂર પડી શકે છે.
• નેટવર્કનું રક્ષણ નબળું છે. પહેલાં ઉલ્લેખ કર્યો તેમ, તે “સલાહરૂપ” હતું, પોતાનો નેટવર્કિંગ સ્ટેક અમલમાં મૂકતા કેટલાક પ્રોગ્રામ્સ દ્વારા તે નિશ્ચિતપણે બાયપાસ કરવામાં આવત, અને પ્રતિકૂળ કોડ સામે ટકી રહેવા માટે રચાયેલ નહોતું.

પ્રથમ ત્રણ મુદ્દાઓ એવા કસ્ટમ સેન્ડબોક્સ અમલીકરણમાં સહજ છે, જે એજન્ટિક ફ્લોઝ માટે પૂરતું લવચીક હોય છે. જોકે, નેટવર્ક સપ્રેશનની બાબત અલગ હતી.

દુર્ભાવનાપૂર્ણ એજન્ટ પર્યાવરણ આધારિત નેટવર્ક દમનને સરળતાથી બાયપાસ કરી શકે છે. આ ઉપરાંત, સારા ઇરાદાવાળા ઘણા કોડ અથવા બાઇનરીઝ પણ તેને બાયપાસ કરી શકે છે, જો તેઓ પર્યાવરણ પ્રોક્સી વેરિએબલ્સનું પાલન ન કરે અથવા પોતાનો સોકેટ આધારિત નેટવર્ક કોડ અમલમાં મૂકે. અમને લાગ્યું કે આ પાસું વધુ સારા સેન્ડબોક્સ મોડમાં રોકાણ કરવા માટે પૂરતું છે.

શ્રેષ્ઠ નેટવર્ક અવરોધન મેળવવા માટે, અમે Windows Firewall નો ઉપયોગ કરવા માંગતા હતા, જે અમને વપરાશકર્તાઓ અથવા પ્રોગ્રામ્સ માટે આઉટબાઉન્ડ નેટવર્ક ટ્રાફિકને અવરોધિત કરવાની મંજૂરી આપે છે. દુર્ભાગ્યે, અમુક કારણોસર અમે એવો કાર્યક્ષમ ફાયરવોલ નિયમ અસરકારક રીતે બનાવી શક્યા નથી, જે માત્ર Codex હાર્નેસ દ્વારા શરૂ કરેલા કમાન્ડ્સ પર જ લાગુ પડે.

• Windows પ્રતિબંધિત ટોકનની ગેર-મુખ્ય ઓળખ સાથે ફાયરવૉલ નિયમને મેળ કરવાની મંજૂરી આપતું નથી. આનો અર્થ એ છે કે અમે “કોઈપણ એવા ટોકન કે જેમાં તેની પ્રતિબંધિત SID યાદીમાં અમારું સિન્થેટિક SID શામેલ હોય” પર ફાયરવૉલ નિયમ લાગુ કરી શકતા નથી.
• જ્યારે અમે ચોક્કસ બાઇનરી સાથે મેળ ખાતો ફાયરવોલ નિયમ બનાવી શકીએ છીએ, તે અમને માત્ર codex.exe માટે નેટવર્કિંગ મર્યાદિત કરવાની મંજૂરી આપે છે. તે વપરાશકર્તાની વતી એજન્ટ દ્વારા શરૂ કરેલી પ્રક્રિયાઓ પર લાગુ નહીં પડે, જેમ કે Git અથવા Python પ્રક્રિયાઓ.
• અન્ય ફાયરવૉલ મેચ પરિમાણો પણ ખોટા આકારના હતા. વપરાશકર્તા-સ્કોપવાળા નિયમો એલિવેટ ન કરેલી ડિઝાઇનમાં હજુ પણ માત્ર પ્રતિબંધિત ચાઇલ્ડ સાથે જ નહીં, પરંતુ વાસ્તવિક Windows વપરાશકર્તા સાથે પણ મૅચ થયા. પ્રોગ્રામ-પાથના નિયમો ખૂબ જ અસ્પષ્ટ હતા: તેઓ સામાન્ય રીતે codex.exe અથવા python.exe ને બ્લોક કરી શકતા હતા, પરંતુ python.exe ના આ ચોક્કસ સેન્ડબોક્સ કરેલા ઇન્વોકેશનને નહીં. પોર્ટ- અથવા સરનામા-આધારિત નિયમો પણ સંપૂર્ણપણે ખોટો નીતિગત અભિગમ હતા. દાખલા તરીકે, અમે પોર્ટ 443 બ્લૉક કરવા માંગતા નહોતાં; અમે આ ચોક્કસ પ્રતિબંધિત પ્રોસેસ ટ્રી માટે મનસ્વી આઉટબાઉન્ડ ઍક્સેસને બ્લૉક કરવા માંગતા હતા.

અમારા સેન્ડબોક્સ કરાયેલા કમાન્ડ્સ પર ખાસ કરીને ફાયરવૉલ નિયમ લાગુ કરવા માટે, અમારે તેમને “વાસ્તવિક” વપરાશકર્તા તરીકે નહીં, પરંતુ અલગ તત્વ તરીકે ચલાવવાની જરૂર હતી. આ અભિગમ અમને એક નવા માર્ગ પર લઈ ગયો, જેમાં અમે અમારા 'નો એલિવેશન'ના પ્રતિબંધમાં થોડી છૂટછાટ આપી.

સેન્ડબોક્સનું આગામી પુનરાવર્તન, જે અમારી વર્તમાન અમલાવણી છે, તેને સેટઅપ સમયે ઉચ્ચ એડમિન પરવાનગીઓની જરૂરિયાત છે. આથી હું તેને “ઉન્નત સેન્ડબોક્સ” તરીકે ઓળખું છું. જે સીમા પર Codex સિસ્ટમ પર કમાન્ડ શરૂ કરે છે, ત્યાં ઉચ્ચાધિકારવાળું સેન્ડબોક્સ બિન-ઉચ્ચાધિકારવાળું સેન્ડબોક્સ જેવું લાગે છે. તે હજી પણ ચાઇલ્ડ પ્રોસેસોને પ્રતિબંધિત ટોકન હેઠળ ચલાવે છે—જેમાં [Everyone, Logon, Synthetic]ની સમાન પ્રતિબંધિત SID સૂચિ ધરાવતું write_restricted ટોકન વપરાય છે—જોકે, આ ટોકનનો પ્રિન્સિપલ હવે વાસ્તવિક Windows વપરાશકર્તા નથી, પરંતુ Codex દ્વારા પોતે બનાવવામાં આવેલા બે સ્થાનિક વપરાશકર્તાઓમાંથી એક છે:

• CodexSandboxOffline (જે ફાયરવૉલ નિયમો દ્વારા નિશાન બનાવવામાં આવ્યું છે)
• CodexSandboxOnline (ફાયરવોલ નિયમો દ્વારા લક્ષિત ન કરાયેલું)

આ દેખીતી રીતે નાની લાગતી વિગત વાસ્તવમાં સેન્ડબોક્સ, તેનો ઉપયોગ કોણ કરી શકે છે, તેમજ તેના સેટઅપ અને રનટાઇમ એક્ઝિક્યુશનની જટિલતા માટે મોટી અસરો ધરાવે છે.

તે દૃષ્ટિએ અનએલિવેટેડ પ્રોટોટાઇપ જેવું જ છે, જેમાં ફાયરવોલ નિયમો અને સમર્પિત Windows વપરાશકર્તાનો સમાવેશ થાય છે, જે કમાન્ડ્સ ચલાવે છે. (જોકે, આ નવા ખ્યાલોની રજૂઆતનો અર્થ એ છે કે સેન્ડબોક્સ કમાન્ડ્સ ચલાવવાનું અને તેમને સુરક્ષિત કરવાનું શરૂ કરી શકે તે પહેલાં વધુ સેટઅપ કામ કરવું પડશે.)

એલિવેટેડ પરવાનગીઓ વગરની સેન્ડબોક્સ ડિઝાઇનમાં એક સરળ સેટઅપ પગલું હતું, પરંતુ તે તુલનાત્મક રીતે નાનું હતું.

• જો જરૂરી હોય તો કૃત્રિમ SID બનાવો
• sandbox-write કૃત્રિમ SID માટે ACL લાગુ કરો

જોકે, એલિવેટેડ સેન્ડબોક્સે વધુ કામ કરવાનું છે.

• કૃત્રિમ SID બનાવો, જો તે પહેલેથી બનાવેલ ન હોય તો
• જો પહેલેથી બનાવેલા ન હોય, તો ઑનલાઇન અને ઑફલાઇન સેન્ડબોક્સ વપરાશકર્તાઓ બનાવો
• નવા બનાવેલા વપરાશકર્તાઓના ક્રેડેન્શિયલ્સને સ્થાનિક રીતે સંગ્રહિત કરો અને Windows Data Protection API (DPAPI) નો ઉપયોગ કરીને એવી જગ્યાએ એન્ક્રિપ્ટ કરો જ્યાં સેન્ડબોક્સ વપરાશકર્તાઓ તેને વાંચી ન શકે
• CodexSandboxOffline વપરાશકર્તા માટે તમામ આઉટબાઉન્ડ નેટવર્ક ઍક્સેસને બ્લૉક કરતા ફાયરવોલ નિયમો બનાવો અથવા, જો તે પહેલેથી અસ્તિત્વમાં હોય, તો તે યોગ્ય છે કે નહીં તે ચકાસો

સેટઅપ તબક્કામાં એક વધારાની જટિલતા છે. Codex ના સેન્ડબોક્સને વાસ્તવિક Windows યુઝર જેટલી જ વાંચવાની ઍક્સેસ હોવાની અપેક્ષા છે. એલેવેટેડ વિના સેન્ડબોક્સમાં, જ્યાં પ્રતિબંધિત ટોકનનું પ્રિન્સિપલ SID Windows વપરાશકર્તા હતું, આ હાંસલ કરવામાં આવ્યું. જોકે, જ્યારે પ્રિન્સિપલ નવો CodexSandbox વપરાશકર્તા બને છે, ત્યારે તે મફતમાં મળતું નથી. Windows પર ઘણી સંબંધિત ડિરેક્ટરીઓ “Authenticated Users” ને વાંચવા/ચલાવવાની પરવાનગીઓ આપશે. એક નોંધપાત્ર ઉદાહરણ વપરાશકર્તાની પ્રોફાઈલ ડિરેક્ટરી છે. ડિફૉલ્ટ રૂપે, Windows વપરાશકર્તાઓ અન્ય Windows વપરાશકર્તાઓની પ્રોફાઇલ ડિરેક્ટરીઓ વાંચી શકતા નથી, તેથી ઘણી પરિસ્થિતિઓમાં ફાઇલ વાંચવાની સરળ ક્રિયાઓ પણ નિષ્ફળ જાય.

આને ઉકેલવા માટે, અમે સેન્ડબોક્સ સેટઅપ પ્રક્રિયામાં એક વધુ સ્તર ઉમેર્યું—એવું સ્તર જે ત્યાં, જ્યાં આવા ACLs પહેલેથી ન હોય, સેન્ડબોક્સ વપરાશકર્તાઓને read ACLs મંજુર કરે છે. ઉદાહરણ તરીકે, સામાન્ય રીતે વપરાતી કેટલીક Windows ડિરેક્ટરીઓ માટે:

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

કારણ કે ડિરેક્ટરીઓની આ સૂચિ શ્રેષ્ઠ-પ્રયાસ આધારિત છે અને દરેક પર ACLs સ્થાપિત કરવું ઘણું ખર્ચાળ હોઈ શકે છે, અમે આ લોજિક અસિંક્રોનસ રીતે ચલાવીએ છીએ જેથી સેન્ડબોક્સ સેટઅપ પગલું, જે વપરાશકર્તાઓ માટે બ્લોકિંગ છે, તેને તે પૂર્ણ થવાની રાહ જોવી ન પડે.

અમે સેટઅપ લોજિકને તેની પોતાની બાઇનરીમાં આંશિક રીતે એટલા માટે એન્કેપ્સ્યુલેટ કર્યું કે UAC સીમા માત્ર જરૂરી હોય ત્યારે જ પાર કરવી પડે. પરંતુ વધુ ઊંડું કારણ આર્કિટેક્ચર સંબંધિત હતું: સેન્ડબોક્સ સેટઅપનું કાર્ય codex.exe કરતાં મૂળભૂત રીતે અલગ છે. સેન્ડબોક્સ સેટઅપ લોજિકને સમર્પિત બાઇનરીમાં રાખવાથી codex.exe ને સામાન્ય, ઉન્નત વિશેષાધિકારો વગરનો હાર્નેસ તરીકે રહેવા દીધું; ફક્ત Windows માટેની સેટઅપ વ્યવસ્થાને અન્ય પ્લેટફોર્મ્સ પર codex.exe ને ભારે બનાવવાથી રોકી; લાંબા સમય સુધી ચાલતા સેટઅપ કાર્યને મુખ્ય પ્રક્રિયાના આયુષ્યથી અલગ કર્યું; અને સેન્ડબોક્સને જરૂરી અલગ-અલગ સેટઅપ માર્ગોને સંભાળવા માટે અમને એક જ સ્થાન આપ્યું.

Windows વપરાશકર્તા અને ટોકન લૉગિન સીમાઓ જે રીતે કાર્ય કરે છે તેના કારણે, અનએલિવેટેડ સેન્ડબોક્સ સાથે અમે જેમ કરી શકતા હતા તેમ પ્રતિબંધિત ટોકન બનાવવાનું અને તેના હેઠળ પ્રક્રિયા શરૂ કરવાનું ચાલુ રાખી શક્યા નહીં. અલગ Windows વપરાશકર્તા તરીકે કમાન્ડ્સ ચલાવવા માટે, અમારું પ્રથમ વિચાર નીચે મુજબ હતું:

• codex.exe વાસ્તવિક વિન્ડોઝ વપરાશકર્તા તરીકે ચાલે છે. ત્યારબાદ, એક ક્રમમાં, Codex:
  • સેન્ડબોક્સ વપરાશકર્તા માટે LogonUserW(...) ને કૉલ કરે છે.
  • તે સેન્ડબોક્સ-વપરાશકર્તા ટોકન પર CreateRestrictedToken(...) કૉલ કરે છે.
  • તે પ્રતિબંધિત સેન્ડબોક્સ-વપરાશકર્તા ટોકનનો ઉપયોગ કરીને, અંતિમ ચાઇલ્ડ પ્રોસેસ લૉન્ચ કરવા માટે 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(...) ને કૉલ કરે છે.

આલ્બર્ટ આઇન્સ્ટાઇને કહ્યું હતું, “દરેક વસ્તુને શક્ય તેટલી સરળ બનાવવી જોઈએ, પરંતુ તેનાથી વધુ સરળ નહીં.” એ જ ભાવનામાં, અમારી ડિઝાઇને દરેક સમસ્યાનો પૂરતો ઉકેલ આપ્યો. અંતિમ આર્કિટેક્ચરમાં અમે અગાઉ આવરી લીધેલા ચાર સ્તરો છે:

• codex.exe પોતે જ
• તમામ એલિવેટેડ સેટઅપ સંબંધિત કાર્યોને હેન્ડલ કરવા માટે codex-windows-sandbox-setup.exe
• પ્રતિબંધિત ટોકન કમાન્ડ્સ ચલાવવા માટે codex-command-runner.exe
• ચાઇલ્ડ પ્રક્રિયા

જ્યારે મેં પ્રથમ વખત આ પ્રોજેક્ટ હાથ ધર્યો, ત્યારે તે અંતે ક્યાં પહોંચશે તેની મને બહુ સ્પષ્ટ સમજ નહોતી. મારો અભિગમ Codex અને ઓપરેટિંગ સિસ્ટમ વચ્ચેની સીમા પર સેન્ડબોક્સિંગ ક્ષમતાને ઇન્સ્ટ્રુમેન્ટ કરીને શરૂઆત કરવાનો હતો. આ અભિગમ macOS અને Linux પર Codex નું સેન્ડબોક્સ જે રીતે અમલમાં મૂકાયું છે તેની સાથે ઘણો નજીકથી મેળ ખાય છે.

જેમ જેમ મને Windows દ્વારા પૂરા પાડવામાં આવતા વિશિષ્ટ ટૂલ્સ વિશે વધુ જાણ થતી ગઈ, અને સુરક્ષા અને ઉપયોગની સરળતા વચ્ચે સંતુલન સાધતા ડઝનો નિર્ણયો દ્વારા, સિસ્ટમ તેના વર્તમાન સ્વરૂપ સુધી વિકસતી ગઈ—બહુવિધ બાઇનરીઝ (મલ્ટિપલ બાઇનરીઝ), કસ્ટમ યુઝર્સ, ફાયરવૉલ નિયમો, ઉચ્ચ અધિકારોવાળું સેટઅપ પગલું (એલિવેટેડ સેટઅપ સ્ટેપ), અસિંક્રોનસ પ્રક્રિયાઓ અને વધુ.

તે ખાસ કરીને સરળ સિસ્ટમ નથી, પરંતુ જટિલતાનો દરેક ભાગ જરૂરિયાતને કારણે ઉમેરવામાં આવ્યો હતો, જેથી એવો સેન્ડબોક્સ બનાવી શકાય જે સુરક્ષિત પણ હોય અને, શક્ય તેટલું, વપરાશકર્તાના માર્ગમાં પણ ન આવે.

Windows પર Codex વપરાશકર્તાઓ માટે સારો વપરાશકર્તા અનુભવ આપવા માટે કામ કરતી વખતે, અમારો ધ્યેય એવું કંઈક બનાવવાનો હતો જે સુરક્ષિત હોય અને ઉપયોગિતામાં કોઈ સમાધાન ન કરતું હોય—Codex નો ઉપયોગ કરવાનો મુખ્ય હેતુ એ છે કે એજન્ટ્સ તમારા સતત ધ્યાન વિના કામ કરી શકે.

આ પ્રોજેક્ટમાંથી મળેલા સૌથી મોટા પાઠોમાંથી એક એ હતો કે Windowsએ અમને એવો કોઈ પ્રિમિટિવ આપ્યો નહોતો, જે “સુરક્ષિત સ્વાયત્ત કોડિંગ એજન્ટ” સાથે સ્પષ્ટ રીતે મેળ ખાતો હોય. અમે કંઈક સુસંગત બનાવવા માટે અનેક ટૂલ્સ અને ખ્યાલોને સંયોજિત કર્યા. કેટલાક પ્રારંભિક વિચારો નિષ્ફળ સાબિત થયા. અંતિમ ડિઝાઇન અગાઉના પ્રોટોટાઇપ્સનું સંયોજન હતું, જેમાંથી દરેકે સમસ્યાનો એક ભાગ ઉકેલ્યો હતો.

બીજો પાઠ એ હતો કે કોડિંગ એજન્ટ માટેની સુરક્ષા, વધુ પરંપરાગત એપ્લિકેશન સુરક્ષા કરતાં એક અલગ પ્રકારનો પડકાર છે. Codex એ વાસ્તવિક ડેવલપર વર્કફ્લોઝ માટે કામ કરવું જોઈએ. એન્જિનિયરિંગ કામ એજન્ટિક વર્કલોડ્સ સાથેની સુસંગતતા અને વાસ્તવિક અમલબજવણી વચ્ચે સંતુલન સાધવા વિશે હતું. એ તણાવે અંતિમ ડિઝાઇનમાં કરાયેલા ટ્રેડ-ઓફ્સને આકાર આપ્યો.

Codex સેન્ડબોક્સને કાર્યરત જોવા માટે ઉત્સુક છો? તેને અજમાવી જુઓ⁠.