Kujenga sandbox salama na yenye ufanisi ili kuwezesha Codex kwenye Windows

Nilipojiunga na timu ya uhandisi ya Codex mnamo Septemba 2025, Codex ya Windows haikuwa na utekelezaji wa sandbox, kumaanisha kwamba watumiaji wa Windows walilazimika kuchagua kati ya chaguo mbili zisizoridhisha walipotumia mawakala wa OpenAI wa kuandika msimbo:

1. Kuidhinisha karibu kila amri (hata usomaji) ambayo wakala wa kuandika msimbo alitaka kutekeleza, jambo ambalo halina ufanisi na linasumbua. Faida kuu ya kutumia Codex ni kwamba huhitaji kufanya kazi yote ya kuchosha mwenyewe.
2. Kuwezesha hali ya Ufikiaji Kamili: kuacha Codex itekeleze amri zote bila idhini au vizuizi, jambo ambalo huondoa vikwazo lakini hupunguza usimamizi.

Codex⁠, wakala wetu wa kuandika msimbo, huendeshwa kwenye kompyuta za mkononi za wasanidi—iwe ni kupitia CLI, kiendelezi cha IDE, au programu ya kompyuta ya mezani. Hudhibiti mazungumzo kati ya binadamu aliye kwenye kibodi na muundo unaoendeshwa kwenye wingu ili kushughulikia hitimisho.

Codex huendeshwa kwa ruhusa za mtumiaji halisi kwa chaguomsingi, kumaanisha kwamba inaweza kufanya kila kitu ambacho mtumiaji anaweza kufanya. Hili lina nguvu na linaweza kuwa hatari. Muundo wa kuandika msimbo unaweza kuambia harness itekeleze amri ndani ya kifaa, kuanzia kuendesha majaribio hadi kusoma au kuhariri faili hadi kuunda tawi la Git, kwa hivyo hali chaguomsingi ya Codex hujaribu kupata uwiano sahihi kati ya ufanisi na usalama. Hali hii chaguomsingi huruhusu Codex kusoma faili karibu popote na kuandika faili ndani ya eneokazi lako (yaani saraka unayoendeshea Codex), bila ufikiaji wa intaneti isipokuwa ubainishe kuwa unautaka. Ili kufanikisha kizuizi hiki cha kiotomatiki cha kuandika faili na kufikia mtandao ndani ya mipaka salama, Codex inahitaji mazingira ya sandbox yanayotekeleza vizuizi hivi kwa kweli.

Sandbox ni mazingira ya utekelezaji yenye vizuizi. Msanidi anapotumia Codex, mfumo wa uendeshaji wa kompyuta yake huzindua amri yenye ruhusa zilizopunguzwa, na vizuizi hivyo husambaa kwenye mfululizo mzima wa michakato inayofuata. Kila amri ya Codex hutekelezwa katika mazingira yenye vizuizi kuanzia mwanzo, na kila mchakato unaotokana nayo hubaki ndani ya mpaka huo huo.

Codex inahitaji vipengele vya kutenga vinavyotekelezwa na mfumo wa uendeshaji wa kompyuta ili kutekeleza sandbox yenye ufanisi. Baadhi ya mifumo ya uendeshaji hutoa huduma zinazofanya hili vizuri (kwa mfano Seatbelt kwenye MacOs, seccomp au bubblewrap kwenye Linux); hata hivyo, Windows kwa sasa haitoi uwezo wa aina hii moja kwa moja.

Ili kufanya Codex iwe salama na ya kufurahisha kutumia kwenye Windows kama ilivyo kila mahali pengine, tulihitaji kutekeleza sandbox yetu wenyewe.`

Windows hutoa baadhi ya zana na misingi ya kutenga. Ingawa hakuna iliyokidhi kikamilifu mahitaji yetu, tuliangalia suluhisho kadhaa yanayowezekana—yaani AppContainer, Windows Sandbox, na uwekaji lebo wa Mandatory Integrity Control.

AppContainer

• Nini: AppContainer ni sandbox asilia ya Windows, muundo wa kutenga unaotegemea uwezo uliojengwa kwa programu zinazojua mapema kabisa kile zinachohitaji kufikia.
• Kwa nini: Inavutia kwa sababu inatoa mpaka halisi wa mfumo wa uendeshaji badala ya vizuizi vya juhudi bora.
• Kwa nini sivyo: Codex si programu moja yenye upeo mdogo wa matumizi. Huendesha mitiririko ya kazi ya wasanidi programu iliyo wazi: shells, Git, Python, wasimamizi wa vifurushi, zana za kujenga programu, na bainari nyingine zozote ambazo ajenti huamua kuwa inazihitaji. Katika utekelezaji, hilo liliifanya AppContainer isiwe suluhisho linalofaa kwa tatizo hilo. Ulikuwa utenganishaji madhubuti, lakini kwa ajili ya aina ndogo sana ya kazi ikilinganishwa na “kumruhusu ajenti kufanya kazi kama msanidi programu.”

Windows Sandbox

• Nini: Windows Sandbox ni VM nyepesi ya muda ya Microsoft. Unapata kompyuta mpya ya mezani ya Windows yenye mpaka imara wa kutenga, na chochote unachofanya ndani yake hupotea kipindi kinapoisha.
• Kwa nini: Inavutia kwa sababu zilizo wazi—inaendana zaidi na programu za aina mbalimbali kuliko AppContainer, na kwa mtazamo wa usalama, ni kisanduku chenye nguvu zaidi.
• Kwa nini siyo: Codex inahitaji kufanya kazi moja kwa moja kwenye checkout, zana na mazingira halisi ya mtumiaji, si ndani ya kompyuta ya mezani ya muda inayohitaji kuandaliwa na kuunganishwa kati ya mfumo mwenyeji na mgeni. Pia ilikuwa na tatizo la msingi la bidhaa: Windows Sandbox haipatikani hata kwenye SKU za Windows Home.

Uwekaji lebo ya uadilifu ya Mandatory Integrity Control (MIC)

• Nini: Windows ina dhana inayoitwa “viwango vya uadilifu,” kama vile chini, wastani na juu, vinavyoamua kiwango ambacho mfumo unaamini vitu na michakato. Kanuni ya msingi ni kwamba mchakato wenye kiwango cha chini cha uadilifu hauwezi kuandika kwenye kipengee chenye kiwango cha juu cha uadilifu, hata kama ACL ya kawaida ingeruhusu hilo vinginevyo. Kwa mfano, mchakato wenye kiwango cha chini cha uadilifu huchukuliwa kuwa hauaminiki sana, kwa hivyo Windows huzuia mchakato huo kuandika kwenye vipengee vya kawaida vya kiwango cha kati cha uadilifu, isipokuwa vipengee hivyo viwekwe lebo upya waziwazi ili kuuruhusu.
• Kwa nini: MIC ilionekana nadhifu kwenye karatasi—endesha Codex kwa uadilifu wa chini, weka lebo upya vyanzo vinavyoandikika kama vya uadilifu wa chini, na uache Windows izuie uandikaji kwingine kote. Hilo lingetupatia njia isiyohitaji haki za msimamizi, iliyoungwa mkono na utaratibu halisi wa OS.
• Kwa nini sio: Kama ACLs, lebo za uadilifu hubadilisha mfumo halisi wa faili wa mwenyeji, na katika hali hii mabadiliko ya kisemantiki yana athari pana hasa. Kuweka alama eneokazi kuwa lenye uadilifu wa chini hakumaanishi tu kwamba “Codex inaweza kuandika hapa.” Inamaanisha kuwa michakato yenye uadilifu wa chini kwa ujumla inaweza kuandika hapo. Kwenye mashine halisi ya msanidi programu, hilo hugeuza nakala halisi ya kazi ya mtumiaji kuwa eneo la kupokelea lenye kiwango cha chini cha uadilifu kwa host, jambo ambalo ni hatari zaidi kuliko kutoa ruhusa za ACL zilizolengwa kwa makini kwa muundo mmoja wa sandbox. Hata kama zana za wasanidi programu zenye uadilifu wa kiwango cha wastani zitaendelea kufanya kazi, muundo wa msingi wa uaminifu wa eneokazi umebadilika kwa namna ambayo mabadiliko hayo ni vigumu kuyadhibiti na vigumu zaidi kuyahalalisha.

Baada ya kutathmini chaguo zote na kuona hazifai kuanzia mwanzo, tulianza kubuni suluhisho letu wenyewe ili kuwapa watumiaji wa Windows uzoefu mzuri wa Codex.

Prototipu yetu ya kwanza iliyofanya kazi ilitumia mchanganyiko wa dhana na zana za Windows kutekeleza utenganishaji tuliouhitaji. Kuanzia mwanzo, mojawapo ya malengo ilikuwa kuhakikisha hili linafanya kazi bila kuhitaji elevation, kumaanisha kwamba Codex isingehitaji kumwomba mtumiaji ruhusa za msimamizi ili tu kusanidi au kuendesha sandbox. Hilo lilimaanisha kubaini jinsi ya kuweka vikomo vinavyofaa kwa mambo mawili: uandishi wa faili na ufikiaji wa mtandao.

Kama hatungepunguza uandishi wa faili kabisa, tungekuwa na tatizo la usalama. Kama tungepunguza sana uandishi wa faili, sandbox ingeathiri tija ya mtumiaji kwa kuhitaji kuomba idhini kila mara. Ili kutatua tatizo hili, tulitegemea vizuizi viwili muhimu vya Windows: SID na tokeni zenye vizuizi vya kuandika.

SID, au kitambulishi cha usalama, ni utambulisho ambao Windows huambatanisha na ruhusa. Kila mtumiaji ana SID, vikundi vina SID, na hata kipindi kimoja cha kuingia hupata SID yake yenyewe. Kwa mfano, kipindi cha sasa kilichoingia kinaweza kuwa na SID kama S-1-5-5-X-Y. SID iliyokabidhiwa kikundi cha wasimamizi wa ndani inaweza kuwa S-1-5-32-544.

Windows pia hukuruhusu kuunda SID za kubuni ambazo haziendani na mtumiaji halisi lakini bado zinaweza kuonekana kwenye ACL (orodha za udhibiti wa ufikiaji), ambazo hufafanua nani anaweza kusoma/kuandika/kutekeleza faili au saraka maalum. Hilo hufanya SID kuwa msingi muhimu kwa sandbox yetu: tunaweza kuunda SID kwa matumizi ya sandbox ya Codex pekee, bila kuingilia chochote kingine kwenye mashine.

Tokeni za mchakato ni vitu vya kiusalama ndani ya Windows ambavyo hufafanua utambulisho na ruhusa kwa ajili ya mchakato unaojiendesha. Huamua vitendo ambavyo mchakato unaweza kutekeleza. Tokeni yenye kizuizi cha kuandika ni aina mahususi ya tokeni ya mchakato inayofanya Windows itekeleze ukaguzi wa ziada wa ufikiaji katika shughuli za kuandika.

Ili uandishi ufaulu, ukaguzi mara mbili lazima zipite:

1. Utambulisho wa kawaida wa mtumiaji (“mmiliki” wa tokeni) lazima uruhusiwe kufanya hivyo
2. Angalau SID moja katika orodha ya SID zilizozuiliwa ya tokeni pia lazima ipewe ufikiaji

Kwa vitendo, ukaguzi huu ulituwezesha kutumia ACL kufafanua kwa usahihi mahali ambapo sandbox ingeweza kubadilisha mfumo wa faili, jambo lililotupa kiwango cha undani tulichohitaji kwenye shughuli za kuandika.

Kwa SID na tokeni zenye vizuizi vya kuandika, sandbox yetu isiyoinuliwa ilifanya kazi hivi:

1. Usanidi wa sandbox uliunda SID ya kubuni iitwayo sandbox-write.
2. SID ya sandbox-write ilipewa ufikiaji wa kuandika, kutekeleza, na kufuta kwa
   1. Saraka ya sasa inayofanya kazi
   2. Vipengee vyovyote vya ziada vya writable_roots vilivyosanidiwa katika config.toml.
3. Usanidi wa sandbox ulizuia kwa uwazi uandikaji wa SID hiyo hiyo kwenye maeneo ya "kusomwa-tu ndani ya yale yanayoandikika" kama vile:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex ilizindua amri chini ya tokeni yenye vizuizi vya kuandika ambayo orodha yake ya SID zilizozuiliwa inajumuisha Everyone, SID ya kipindi cha sasa kilichoingia, na SID ya kubuni ya sandbox-write.

Mtiririko huu ulitatua kwa ufanisi suala la kupunguza uandishi wa faili na ulionekana kuwa wa kuahidi. Sasa tulihitaji suluhisho la kupunguza ufikiaji wa mtandao wa sandbox.

Kupunguza ufikiaji wa mtandao ni sehemu muhimu ya sandbox; bila hilo, msimbo hasidi ungeweza kutoa data kutoka kwenye mashine kwenda intaneti. Kwa sababu tulitaka kuepuka hitaji la elevation, tulikuwa na chaguo chache za kuzuia kwa nguvu trafiki ya mtandao. Zana tulizotaka kutumia, kama Windows Firewall, kwa kawaida hazingeweza kusakinishwa bila ruhusa za admin.

Bila Windows Firewall kuwa mojawapo ya chaguo, tuliweka kikomo kwa kile tulichoweza kudhibiti. Bila Windows Firewall kama chaguo, tulipunguza kile tulichoweza kudhibiti. Tulijaribu kufanya mazingira ya mtoto yafeli kwa kufungwa kwa aina za zana za mtandao ambazo wasanidi hutumia kwa kawaida, ili amri za Git, visakinishi vya vifurushi, na kadhalika, vifeli ndani ya sandbox na mtumiaji alazimike kuidhinisha shughuli zozote zinazokabili intaneti. Wazo lilikuwa kuzifanya njia dhahiri za kutorokea zisitumike: tuma trafiki inayotambua proxy kwa mwisho usiofanya kazi, fanya usafirishaji wa Git wa HTTP(S) ufanye vivyo hivyo, na fanya Git kupitia SSH ifeli mara moja. Zaidi ya hayo, tuliongeza saraka ndogo ya denybin kwenye PATH na tukapanga upya PATHEXT ili hati za majaribio za SSH na SCP zipatikane kabla ya faili halisi za binary.

Kwa mfano, haya ni baadhi ya mabadiliko mahsusi ya mazingira tuliyotumia kupunguza ufikiaji wa mtandao:

• 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

Hilo lilivuta trafiki nyingi za kawaida zinazoendeshwa na zana, lakini bado lilikuwa la ushauri tu. Mchakato ungeweza kupuuza mazingira, kukwepa PATH, au kufungua soketi moja kwa moja—hatari mno.

Kama ilivyo kwa utekelezaji wowote wa programu unaovutia,prototaipu ya kwanza ilikuwa na faida na hasara kadhaa. Ingawa ilifanya kazi kwa kutumia uwezo mchache tu wa kawaida wa Windows, iliruhusu uandishi wa mfumo wa faili ulio wazi sana na wa kiwango cha undani, na iliendeshwa bila elevation—hivyo kupunguza hitaji la watumiaji kukubali madokezo mengi ya elevation au kuwa admins kwenye mashine yao ya ndani—ilikuwa na mapungufu halisi, baadhi yake yaliyoiondoa kwenye kustahili kuwa muundo wetu wa mwisho:

• Kasi ya usanidi: Kutumia ACL za eneokazi kunaweza kuwa ghali kulingana na topolojia ya saraka ya eneokazi.
• Alama ya athari: Tulitumia ACL halisi kwenye mfumo wa msanidi, ingawa athari hiyo si vamizi sana kwa sababu ACL zote zilizotumika zinahusu SID ya kubuni iliyoundwa maalum inayotumiwa tu na sandbox.
• Maana ngumu kubadilisha: Kutegemea ACL kwa vizuizi vya faili kunamaanisha ni ghali na changamano kubadilisha maana za sandbox. Ilhali kwenye macOS, tunaweza kubadilisha jinsi tunavyotengeneza faili ya .sbpl inayotumika kusanidi Seatbelt, sandbox ya Windows inaweza kuhitaji operesheni ya polepole na nzito ili kurekebisha ACL.
• Ulinzi wa mtandao ni dhaifu. Kama ilivyotajwa awali, ulikuwa wa “ushauri,” bila shaka ungepitiwa na baadhi ya programu zilizotekeleza rafu yao wenyewe ya mitandao, na haukubuniwa kustahimili msimbo wa kiadui.

Masuala matatu ya kwanza ni ya asili kwa utekelezaji wa sandbox maalum unaobadilika vya kutosha kwa mitiririko ya uwakala. Hata hivyo, simulizi ya kuzima mtandao ilikuwa tofauti.

Mbali na wakala hasidi kuweza kukwepa kwa urahisi uzuiaji wa mtandao kulingana na mazingira, msimbo au programu nyingi zenye nia njema pia zingeweza kuukwepa ikiwa tu hazitazingatia vigezo vya mazingira vya seva mbadala (proxy variables), au ikiwa zingetekeleza msimbo wao wenyewe wa mtandao unaotegemea soketi. Tulihisi kuwa kipengele hiki kilitosha kufikiria kuwekeza kwenye mfumo bora zaidi wa sandbox.

Ili kupata uzuiaji bora wa mtandao, tulitaka kutumia Windows Firewall, ambayo huturuhusu kuzuia trafiki ya mtandao inayotoka kwa watumiaji au programu. Kwa bahati mbaya, hatukuweza kuunda kwa ufanisi sheria ya firewall inayotumika tu kwa amri zinazozalishwa na harness ya Codex kwa sababu chache:

• Windows hairuhusu kulinganisha sheria ya firewall na utambulisho usio mkuu wa tokeni yenye vizuizi. Hii ilimaanisha hatungeweza kutumia sheria ya firewall kwa “tokeni yoyote inayojumuisha SID yetu ya kubuni katika orodha yake ya SID zilizozuiliwa.”
• Ingawa tungeweza kuunda sheria ya firewall inayolingana na binary maalum, hilo huturuhusu tu kuzuia mtandao kwa codex.exe yenyewe. Haitatumika kwa michakato ambayo ajenti huanzisha kwa niaba ya mtumiaji, kama vile michakato ya Git au Python.
• Vipimo vingine vya kulinganisha firewall pia vilikuwa na umbo lisilofaa. Sheria zinazolenga mtumiaji bado zililingana na mtumiaji halisi wa Windows katika muundo usioinuliwa, si mchakato mtoto uliozuiliwa tu. Kanuni za njia ya programu zilikuwa jumla mno: zingeweza kuzuia codex.exe au python.exe kwa ujumla, lakini si utekelezaji huu mmoja wa python.exe uliowekwa kwenye sandbox. Kanuni zinazotegemea porti au anwani pia zilikuwa sera isiyofaa kabisa. Kwa mfano, hatukutaka kuzuia porti 443; tulitaka kuzuia ufikiaji wowote unaotoka kwa mchakato huu mahususi uliowekewa vizuizi.

Ili kutumia sheria ya firewall hasa kwa amri zetu zilizowekwa ndani ya sandbox, tulihitaji kuziendesha kama principal tofauti, si kama mtumiaji “halisi”. Mbinu hii ilitupeleka kwenye njia mpya, ambayo tulilegeza kizuizi chetu cha “hakuna elevation”.

Toleo lililofuata la sandbox, ambalo ndilo utekelezaji wetu wa sasa, linahitaji ruhusa za kiwango cha juu za msimamizi wakati wa usanidi. Kwa hivyo, ninaiita “sandbox iliyoinuliwa.” Kwenye mpaka ambapo Codex huanzisha amri kwenye mfumo, sandbox iliyoinuliwa huonekana kama ile isiyoinuliwa. Bado huendesha michakato tanzu chini ya tokeni iliyowekewa vikwazo—vivyo hivyo tokeni ya write_restricted yenye orodha ileile ya SID zilizowekewa vizuizi vya [Everyone, Logon, Synthetic]—hata hivyo, principal ya tokeni hii sio tena mtumiaji halisi wa Windows bali ni mmoja wa watumiaji wawili wa ndani walioundwa na Codex yenyewe:

• CodexSandboxOffline (inayolengwa na sheria za firewall)
• CodexSandboxOnline (isiyolengwa na sheria za firewall)

Maelezo haya yanayoonekana kuwa madogo kwa kweli yana athari kubwa kwa sandbox, ni nani anayeweza kuitumia, na ugumu wa usanidi na utekelezaji wake wakati wa utekelezaji.

Kwa mwonekano inafanana na prototipu isiyoinuliwa, kwa kuongezwa kwa sheria za firewall na mtumiaji maalum wa Windows, ambaye kwa kweli ndiye anayeendesha amri. (Hata hivyo, kuanzishwa kwa dhana hizi mpya kunamaanisha kwamba kuna kazi zaidi ya usanidi ya kufanya kabla sandbox haijaanza kuendesha na kulinda amri.)

Muundo wa sandbox isiyoinuliwa ulikuwa na hatua rahisi ya usanidi, lakini ilikuwa ndogo kiasi:

• Unda SID ya kubuni ikiwa inahitajika
• Tumia ACL kwa SID ya kubuni ya sandbox-write

Hata hivyo, sandbox iliyoinuliwa ina mengi zaidi ya kufanya.

• Unda SID ya sintetiki, ikiwa haijatengenezwa tayari
• Unda watumiaji wa sandbox wa mtandaoni na wa nje ya mtandao, ikiwa hawajaundwa tayari
• Hifadhi vitambulisho vya watumiaji wapya ndani ya kifaa na uvisimbe kwa kutumia Windows Data Protection API (DPAPI) mahali ambapo watumiaji wa sandbox hawawezi kuvisoma
• Unda sheria za firewall zinazozuia ufikiaji wote wa mtandao unaotoka kwa mtumiaji wa CodexSandboxOffline au, ikiwa tayari zipo, thibitisha kuwa ni sahihi

Kuna changamoto ya ziada katika hatua ya usanidi. Sandbox ya Codex inatarajiwa kuwa na ufikiaji wa kusoma ulio sawa na wa mtumiaji halisi wa Windows. Katika sandbox isiyoinuliwa, ambapo SID ya msingi ya tokeni yenye vizuizi ilikuwa mtumiaji wa Windows, hili lilifanikishwa. Hata hivyo, hilo haliji bure wakati mhusika anapokuwa mtumiaji mpya wa CodexSandbox. Saraka nyingi husika kwenye Windows zitawapa “Authenticated Users” ruhusa za kusoma/kutekeleza. Mfano mmoja muhimu ni saraka ya wasifu wa mtumiaji. Kwa chaguo-msingi, watumiaji wa Windows hawawezi kusoma saraka za wasifu za watumiaji wengine wa Windows, kwa hivyo hata shughuli rahisi za kusoma faili katika hali nyingi zingefeli.

Ili kushughulikia hili, tuliongeza tabaka jingine kwenye mchakato wa usanidi wa sandbox—la kutoa ACL za kusoma kwa watumiaji wa sandbox mahali ambapo ACL hizo huenda tayari hazipo. Kwa mfano, kwenye baadhi ya saraka za Windows zinazotumiwa sana:

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

Kwa sababu orodha hii ya saraka ni bora zaidi na kusakinisha ACL kwenye kila moja kunaweza kuwa ghali sana, tunaendesha mantiki hii bila kusawazisha ili hatua ya usanidi wa sandbox, ambayo humzuia mtumiaji, isilazimike kusubiri zikamilike.

Tuliweka mantiki ya usanidi katika faili lake tekelezi ili kuvuka mpaka wa UAC pale tu inapohitajika. Lakini sababu ya msingi zaidi ilikuwa ya usanifu: usanidi wa sandbox una jukumu tofauti kabisa na codex.exe. Kuweka mantiki ya usanidi wa sandbox katika faili lake tekelezi maalum kuliruhusu codex.exe kubaki programu ya kawaida isiyoinuliwa; kulizuia mashine ya usanidi ya Windows pekee isiongeze uzito kwa codex.exe kwenye majukwaa mengine; kulitenganisha kazi ya usanidi ya muda mrefu na muda wa maisha wa mchakato mkuu; na kutupa sehemu moja ya kushughulikia njia mbalimbali za usanidi ambazo sandbox ilihitaji.

Kutokana na jinsi mipaka ya kuingia kwa mtumiaji na tokeni inavyofanya kazi kwenye Windows, hatukuweza kuendelea kuunda tokeni yenye vizuizi na kuanzisha mchakato chini yake kwa njia ile ile ambayo tuliweza kwenye sandbox isiyoinuliwa. Ili kuanzisha amri kama mtumiaji tofauti wa Windows, wazo letu la kwanza lilikuwa mtiririko ufuatao:

• codex.exe huendeshwa kama mtumiaji halisi wa Windows. Kisha, kwa mfululizo, Codex:
  • Huita LogonUserW(...) kwa mtumiaji wa sandbox.
  • Huita CreateRestrictedToken(...) kwenye tokeni hiyo ya mtumiaji wa sandbox.
  • Kwa kutumia tokeni hiyo iliyowekewa vizuizi ya mtumiaji wa sandbox, huita CreateProcessAsUserW(...) ili kuzindua mchakato mtoto wa mwisho.

Kiutendaji, mtiririko uliotarajiwa haukufanya kazi kwa sababu ya kizuizi cha haki za ufikiaji kwenye CreateProcessAsUserW(...). Hii inamaanisha kwamba codex.exe ingeweza kuunda tokeni yenye vizuizi kwa mtumiaji wa sandbox, lakini haingeweza kuzindua kwa kutegemewa mchakato mtoto kwa tokeni hiyo kutoka upande wa mpaka wa mtumiaji halisi. Tulihitaji mchakato ambao tayari ulikuwa unaendeshwa kama mtumiaji wa sandbox—hii ingeruhusu hatua ya kuweka vizuizi na uanzishaji wa mwisho wa mchakato kufanyika upande wa mtumiaji wa mpaka wa sandbox badala ya upande wa mtumiaji halisi.

Sharti hilo lilisababisha kuundwa kwa codex-command-runner.exe,binary mpya ambayo jukumu lake pekee ni kuunda tokeni yenye vizuizi na kuanzisha amri iliyoombwa. Badala ya kuiomba codex.exe ifanye mtiririko mzima yenyewe (mtumiaji halisi → mtumiaji wa sandbox → tokeni yenye vizuizi → mchakato mtoto), tuligawa mtiririko katika sehemu mbili:

Sehemu ya 1

• codex.exe huita CreateProcessWithLogonW(...) kuendesha codex-command-runner.exe kama mtumiaji wa sandbox, bila kutumia tokeni yenye vizuizi bado.

Sehemu ya 2

• Ndani ya runner, OpenProcessToken(GetCurrentProcess(), ...) hufungua tokeni ya runner yenyewe, ambayo tayari ni ya mtumiaji wa sandbox.
• Runner huita GetTokenInformation(...) kutoa SID ya kuingia ya sandbox, kisha CreateRestrictedToken(...) kujenga tokeni ya mwisho yenye vizuizi.
• Bado ndani ya runner, huita CreateProcessAsUserW(...) kwa tokeni hiyo yenye vizuizi kuzindua mchakato halisi wa mtoto.

Albert Einstein alisema, “Kila kitu kinapaswa kufanywa kuwa rahisi kadiri inavyowezekana, lakini si rahisi zaidi ya hapo.” Kwa mtazamo huo, muundo wetu ulitatua kila tatizo ipasavyo. Usanifu wa mwisho una tabaka nne ambazo tumeshazizungumzia awali:

• codex.exe yenyewe
• codex-windows-sandbox-setup.exe ya kushughulikia kazi zote za usanidi zilizoinuliwa
• codex-command-runner.exe ya kuendesha amri za tokeni zenye vizuizi
• Mchakato wa mtoto

Nilipoanza mradi huu kwa mara ya kwanza, sikuwa na picha kamili ya mahali ingeishia. Mbinu yangu ilikuwa kuanza kwa kutumia uwezo wa kuweka sandbox katika mpaka kati ya Codex na mfumo wa uendeshaji. Mbinu hii inalingana kwa karibu na jinsi sandbox ya Codex inavyotekelezwa kwenye MacOs na Linux.

Nilipojifunza zaidi kuhusu zana maalum ambazo Windows hutoa, na kupitia maamuzi kadhaa yaliyosawazisha usalama na urahisi wa matumizi, mfumo ulikua hadi kufikia umbo lake la sasa—binaries nyingi, watumiaji maalum, sheria za firewall, hatua ya usanidi iliyoinuliwa, michakato ya usawazisho huria, na mengine zaidi.

Si mfumo rahisi sana, lakini kila kipande cha uchangamano kiliongezwa kutokana na ulazima, ili kujenga sandbox ambayo ni salama na, kadiri inavyowezekana, haimzuii mtumiaji.

Tulipokuwa tukifanya kazi ili kuleta uzoefu mzuri wa mtumiaji kwa watumiaji wa Codex kwenye Windows, lengo letu lilikuwa kutengeneza kitu salama kisichoathiri manufaa ya matumizi—lengo kuu la kutumia Codex ni kuwa na mawakala wanaoweza kufanya kazi bila uangalizi wako wa kila wakati.

Mojawapo ya masomo makubwa zaidi kutoka kwa mradi huu ni kwamba Windows haikutupa msingi mmoja unaolingana moja kwa moja na “wakala salama wa kuandika msimbo huru.” Tuliunganisha zana na dhana kadhaa ili kujenga kitu kinachoeleweka. Baadhi ya mawazo ya awali yalikuwa njia zisizo na matokeo. Muundo wa mwisho ulikuwa mseto wa prototipu za awali ambazo kila moja ilitatua sehemu ya tatizo.

Somo lingine lilikuwa kwamba usalama kwa wakala wa kuandika msimbo ni tofauti na usalama wa programu za kawaida. Codex lazima ifanye kazi kwa mitiririko halisi ya kazi ya wasanidi. Kazi ya uhandisi ilikuwa inahusu kusawazisha uoanifu na kazi ya kiuwakala dhidi ya utekelezaji halisi. Mvutano huo ndio ulioamua machaguo katika muundo wa mwisho.

Una hamu ya kuona sandbox ya Codex ikifanya kazi? Ijaribu⁠.