Ndërtimi i një sandbox-i të sigurt dhe efektiv për të bërë të mundur Codex në Windows

Kur iu bashkova ekipit inxhinierik të Codex në shtator 2025, Codex për Windows nuk kishte një zbatim sandbox-i, që do të thotë se përdoruesit e Windows ishin të detyruar të zgjidhnin mes dy opsioneve nën standard kur përdornin agjentët e kodimit të OpenAI:

1. Duke miratuar thuajse çdo komandë (edhe leximet) që një agjent kodimi donte të ekzekutonte, gjë që nuk është efikase dhe është e bezdisshme. Një përfitim i madh i përdorimit të Codex është se nuk duhet ta bësh vetë gjithë punën e lodhshme.
2. Aktivizimi i modalitetit të qasjes së plotë: lejimi i Codex që të ekzekutojë të gjitha komandat pa miratim ose kufizime, gjë që eliminon pengesat në kurriz të mbikëqyrjes.

Codex⁠, agjenti ynë i kodimit, ekzekutohet në laptopët e zhvilluesve, pavarësisht nëse bëhet përmes CLI-së, shtesës IDE apo aplikacionit për desktop. Menaxhon një bisedë midis një personi në tastierë dhe një model që ekzekutohet në cloud për të trajtuar inferencën.

Codex ekzekutohet si parazgjedhje me lejet e një përdoruesi real, që do të thotë se mund të bëjë gjithçka që mund të bëjë përdoruesi. Kjo është e fuqishme dhe mund të jetë e rrezikshme. Modeli i kodimit mund t’i thotë strukturës t'i ekzekutojë komandat në nivel lokal, nga ekzekutimi i testeve e deri te leximi ose redaktimi i një skedari dhe te krijimi i një dege të Git, kështu që modaliteti i parazgjedhur i Codex përpiqet të gjejë ekuilibrin e duhur mes efektivitetit dhe sigurisë. Ky modalitet i parazgjedhur e lejon Codex që të lexojë skedarët thuajse kudo dhe të shkruajë skedarët brenda hapësirës së punës (d.m.th. te direktoria ku ekzekutohet Codex), pa qasje në internet, përveçse nëse ti specifikon se e dëshiron këtë. Për të arritur këtë kufizim automatik për shkrimin e skedarëve dhe qasjen në rrjet brenda kufijve të sigurt, Codex ka nevojë për një mjedis sandbox-i që i zbaton vërtet këto kufizime.

Një sandbox është një mjedis ekzekutimi i kufizuar. Kur një zhvillues përdor Codex, sistemi operativ i kompjuterit të tij nis një komandë me leje të reduktuara dhe këto kufizime vijojnë më poshtë në pemën e proceseve. Çdo komandë e Codex izolohet në një mjedis “sandbox” që në fillim, dhe çdo proces pasardhës mbetet brenda të njëjtit kufi.

Codex ka nevojë për veçori izolimi të zbatuara nga sistemi operativ i kompjuterit për të vënë në zbatim një sandbox efektiv. Disa sisteme operative ofrojnë mjete që e bëjnë mirë këtë (p.sh. Seatbelt në MacOs, seccomp ose bubblewrap në Linux); megjithatë, Windows aktualisht nuk e ka gati këtë lloj aftësie.

Për ta bërë Codex po aq të sigurt dhe të lehtë për t'u përdorur në Windows si kudo tjetër, ishte e nevojshme të zbatonim sandbox-in tonë.

Windows ofron disa mjete dhe elemente bazë për izolimin. Edhe pse asnjë prej tyre nuk i plotësonte plotësisht kërkesat tona, ne shqyrtuam disa zgjidhje të mundshme - përkatësisht, AppContainer, Windows Sandbox dhe etiketimin Mandatory Integrity Control.

AppContainer

• Çfarë: AppContainer është sandbox-i origjinal i Windows, një model izolimi i bazuar në aftësi i ndërtuar për aplikacione që e dinë paraprakisht dhe saktësisht se ku duhet të kenë qasje.
• Pse: Pëlqehet sepse ofron një kufi të vërtetë të sistemit operativ në vend të kufizimeve më të mira të mundshme.
• Pse jo: Codex nuk është një aplikacion i vetëm me fushëveprim të përcaktuar ngushtë. Ai mundëson rrjedha pune të hapura zhvillimi: shell-e, Git, Python, menaxherë paketash, mjete ndërtimi dhe çfarëdo skedarësh të tjerë binarë që agjenti vendos se i duhen. Në praktikë, kjo e bëri AppContainer të papërshtatshëm për problemin. Ky ishte izolim i fortë, por për një klasë shumë më të ngushtë ngarkesash pune sesa “ta lësh një agjent të veprojë si një zhvillues”.

Windows Sandbox

• Çfarë: Windows Sandbox është VM-ja e lehtë dhe e përkohshme e Microsoft-it. Merr një desktop të ri të Windows me një kufi të fortë izolimi dhe çdo gjë që bën brenda tij zhduket kur mbaron sesioni.
• Pse: Interesant për arsye të dukshme - shumë më i përputhshëm me softuerë arbitrarë se AppContainer dhe, nga këndvështrimi i sigurisë, është një strukturë shumë më e fortë.
• Pse jo: Codex duhet të veprojë drejtpërdrejt në dorëzimin, mjetet dhe mjedisin aktual të përdoruesit, jo brenda një desktopi të veçantë të përkohshëm që do të kërkonte konfigurim dhe lidhje pritës/vizitor. Ai kishte gjithashtu një problem themelor të produktit: Windows Sandbox nuk është i disponueshëm në SKU-të e Windows Home.

Etiketimi i integritetit Mandatory Integrity Control (MIC)

• Çfarë: Windows ka një koncept të quajtur “nivele integriteti”, si i ulët, mesatar dhe i lartë, që përcaktojnë se sa u beson sistemi objekteve dhe proceseve. Rregulli bazë është që një proces me integritet më të ulët nuk mund të shkruajë në një objekt me nivel më të lartë integriteti, edhe nëse ACL-ja normale përndryshe do ta lejonte këtë. Për shembull, një proces me integritet të ulët trajtohet si më pak i besuar, prandaj Windows e bllokon atë që të shkruajë në objekte normale me integritet mesatar, përveç rasteve kur ato objekte janë rietiketuar në mënyrë të qartë për ta lejuar këtë.
• Pse: MIC dukej elegant në letër—ekzekuto Codex me integritet të ulët, rietiketo rrënjët e shkruajtshme si me integritet të ulët dhe lëre Windows të zbatojë ndalimin e shkrimit kudo tjetër. Kjo do të na kishte dhënë një rrugë pa privilegje administratori, të mbështetur nga një mekanizëm i vërtetë i sistemit operativ.
• Pse jo: Ashtu si ACL-të, etiketat e integritetit modifikojnë sistemin real të skedarëve të hostit, dhe në këtë rast ndryshimi semantik është veçanërisht i gjerë. Shënimi i një hapësire pune si me integritet të ulët nuk do të thotë thjesht “Codex mund të shkruajë këtu.” Kjo do të thotë se proceset me integritet të ulët në përgjithësi mund të shkruajnë aty. Në një makinë reale zhvilluesi, kjo e shndërron checkout-in faktik të përdoruesit në një destinacion me integritet të ulët për hostin, gjë që është shumë më e rrezikshme sesa t’i jepen ACL të synuara me kujdes një dizajni të vetëm sandbox-i. Edhe nëse mjetet e zhvilluesit me integritet mesatar vazhdojnë të funksionojnë, modeli themelor i besimit i hapësirës së punës ka ndryshuar në një mënyrë që është e vështirë të mbahet nën kontroll dhe edhe më e vështirë të justifikohet.

Pasi i vlerësuam të gjitha opsionet si të papërshtatshme, ne filluam të dizajnonim zgjidhjen tonë për të sjellë një eksperiencë të mirë të Codex për përdoruesit e Windows.

Prototipi ynë i parë funksional përdori një kombinim të koncepteve dhe mjeteve të Windows-it për të zbatuar izolimin që na nevojitej. Që nga fillimi, një nga synimet ishte që kjo të funksiononte pa kërkuar ngritje privilegjesh, që do të thotë se Codex nuk do të kishte nevojë t’i shfaqte përdoruesit një kërkesë për privilegje administratori vetëm për të konfiguruar ose ekzekutuar sandbox-in. Kjo do të thoshte të gjenim mënyrën se si të vendosnim kufij të arsyeshëm për dy gjëra: operacionet e shkrimit në skedarë dhe qasjen në rrjet.

Nëse nuk do ta kufizonim aspak shkrimin e skedarëve, do të kishim një problem sigurie. Nëse do ta kufizonim shumë, sandbox-i do të dëmtonte produktivitetin e përdoruesit, duke pasur nevojën për të kërkuar vazhdimisht miratimin. Për ta zgjidhur këtë problem, ne u mbështetëm në dy blloqe të rëndësishme ndërtimi të Windows: identifikuesit SID dhe tokenët me kufizim shkrimi.

Një SID, ose identifikues sigurie, është identiteti që Windows-i e lidh me lejet. Çdo përdorues ka një SID, grupet kanë SID-e, dhe madje edhe një sesion i vetëm hyrjeje merr SID-in e vet. Për shembull, një seancë aktuale me hyrje në sistem mund të ketë një SID si S-1-5-5-X-Y. SID-i i caktuar grupit të administratorëve lokalë mund të jetë S-1-5-32-544.

Windows të lejon gjithashtu të krijosh SID-e sintetike që nuk i korrespondojnë një përdoruesi real, por që mund të shfaqen përsëri në ACL (listat e kontrollit të qasjes), të cilat përcaktojnë kush mund të lexojë/shkruajë/ekzekutojë skedarë ose direktori specifike. Kjo i bën identifikues SID një element bazë të dobishëm për sandbox-in tonë: ne mund të krijojmë identifikues SID ekskluzivisht për përdorim nga sandbox-i i Codex, pa ndërhyrë në asgjë tjetër në pajisje.

Token e proceseve janë objekte sigurie në Windows që përcaktojnë identitetin dhe privilegjet për një proces në ekzekutim. Ato përcaktojnë se çfarë veprimesh mund të kryejë një proces. Një token i kufizuar për shkrim është një lloj i veçantë i token-it të procesit që bën që Windows të kryejë një kontroll shtesë aksesi në operacionet e shkrimit.

Që një shkrim të ketë sukses, duhet të kalohen me sukses dy kontrolle:

1. Identiteti normal i përdoruesit (“pronari” i tokenit) duhet të lejohet ta bëjë këtë
2. Të paktën një SID në listën e kufizuar të SID-ëve të tokenit duhet gjithashtu të ketë qasje

Në praktikë, këto kontrolle na lejuan të përdornim listat ACL për të përcaktuar me saktësi se ku sandbox-i mund të modifikonte sistemin e skedarëve, gjë që na ofroi detajet që na duheshin për operacionet e shkrimit.

Me identifikuesit SID dhe tokenët me kufizim shkrimi, sandbox-i ynë pa privilegje të rritura funksiononte në këtë mënyrë:

1. Konfigurimi i sandbox-it krijonte një SID sintetike të quajtur sandbox-write.
2. SID sandbox-write iu dha e drejta për të shkruar, ekzekutuar dhe fshirë
   1. Direktoria aktuale e punës
   2. Çdo writable_roots shtesë të konfiguruar në config.toml.
3. Konfigurimi i sandbox-it ia ndaloi në mënyrë të qartë të njëjtit SID aksesin për shkrim në vendndodhje “vetëm për lexim brenda të shkruajtshme”, si p.sh.:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex niste komanda nën një token me kufizim shkrimi, lista e identifikuesve të kufizuar SID e të cilit përfshin Everyone, identifikuesin SID të sesionit aktual të identifikuar dhe identifikuesin sintetik SID sandbox-write.

Kjo rrjedhë pune e zgjidhi me efektivitet kufizimin e shkrimit të skedarëve dhe dukej premtuese. Tani na duhej një zgjidhje për kufizimin e qasjes së sandbox-it në rrjet.

Kufizimi i qasjes në rrjet është një pjesë e rëndësishme e sandbox-it; pa të, kodet keqdashëse mund të nxjerrin të dhënat nga kompjuteri në internet. Për shkak se dëshironim të shmangnim kërkesën për rritje privilegjesh, kishim mundësi të kufizuara për të bllokuar fort trafikun e rrjetit. Mjetet që dëshironim të përdornim, si Muri mbrojtës i Windows, në përgjithësi nuk mund të instaloheshin pa leje administratori.

Pa Windows Firewall si opsion, kufizuam atë që mund të kontrollonim. U përpoqëm ta bënim mjedisin fëmijë të funksiononte sipas parimit fail-closed për llojet e mjeteve të lidhura në rrjet që zhvilluesit përdorin realisht, në mënyrë që komandat Git, instaluesit e paketave etj. të dështonin brenda sandbox-it dhe përdoruesi të duhej të miratonte çdo operacion me qasje drejt internetit. Ideja ishte të sabotoheshin rrugëdaljet e dukshme: të dërgohej trafiku që njeh proxy drejt një pike fundore të vdekur, të bëhej që transporti HTTP(S) i Git-it të bënte të njëjtën gjë, dhe të bëhej që Git përmes SSH të dështonte menjëherë. Përveç kësaj, shtuam në fillim të PATH një direktori të vogël denybin dhe rirenditëm PATHEXT që skriptet stub SSH dhe SCP të gjendeshin përpara binarëve realë.

Për shembull, këtu janë disa nga anashkalimet specifike të mjedisit që përdorëm për të kufizuar qasjen në rrjet:

• 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

Kjo kapte shumë trafik normal të drejtuar nga mjetet, por ishte përsëri vetëm këshilluese. Një proces mund ta injoronte mjedisin, të anashkalonte PATH ose thjesht të hapte drejtpërdrejt prizat—shumë e rrezikshme.

Ashtu si çdo implementim interesant softuerik, prototipi i parë kishte disa avantazhe dhe disavantazhe. Edhe pse e kryente punën vetëm me disa aftësi standarde të Windows, lejonte shkrime shumë të qarta dhe të detajuara në sistemin e skedarëve dhe ekzekutohej pa rritje privilegjesh—duke ulur nevojën që përdoruesit të pranonin kërkesa të tepërta për rritje privilegjesh ose të ishin administratorë në kompjuterin e tyre lokal—ai kishte disa mangësi reale, disa prej të cilave e skualifikuan për t’u bërë dizajni ynë përfundimtar:

• Shpejtësia e konfigurimit: Aplikimi i listave ACL të hapësirë pune mund të jetë i kushtueshëm në varësi të topologjisë së direktorisë së hapësirë pune.
• Gjurma: Ne aplikuam lista reale ACL në sistemin e zhvilluesit, megjithëse gjurma nuk është veçanërisht ndërhyrëse pasi të gjitha listat e zbatuara ACL i përkasin një identifikuesi sintetik SID të krijuar posaçërisht që përdoret vetëm nga sandbox-i.
• Semantika të vështira për t’u ndryshuar: Mbështetja te ACL-të për kufizime të bazuara në skedarë do të thotë se ndryshimi i semantikës së sandbox-it është i kushtueshëm dhe kompleks. Ndërsa në macOS, ne mund të ndryshojmë në mënyrë dinamike mënyrën se si gjenerojmë .sbpl skedari i përdorur për të konfiguruar Seatbelt, sandbox-i i Windows mund të kërkojë një operacion të ngadaltë dhe intensiv për të rregulluar ACL-të.
• Mbrojtja e rrjetit është e dobët. Siç u përmend më parë, ishte “këshilluese”, dhe do të anashkalohej pa dyshim nga disa programe që zbatonin stivën e tyre të rrjetit dhe nuk ishte projektuar për të përballuar kodet kundërshtare.

Tri çështjet e para janë themelore për një zbatim të personalizuar të sandbox-it me një fleksibilitet të mjaftueshëm për rrjedhat e punës së agjentëve. Megjithatë, historia e kontrollit të trafikut të rrjetit ishte diçka tjetër.

Përveç faktit që një agjent keqdashës mund ta anashkalonte me lehtësi kontrollin e trafikut të rrjetit bazuar te mjedisi, shumë skedarë të ekzekutueshëm/kode dashamirëse do ta anashkalonin atë thjesht nëse nuk do të respektonin ndryshoret e serverit përfaqësues të mjedisit, ose nëse do të zbatonin kodin e tyre të rrjetit bazuar te priza. Ne menduam se ky aspekt ishte i mjaftueshëm për të marrë parasysh investimin në një modalitet më të mirë sandbox-i.

Për të siguruar një kontroll më të mirë të trafikut të rrjetit, ne dëshironim të përdornim Murin mbrojtës të Windows, i cili na lejon të bllokojmë trafikun dalës të rrjetit për përdoruesit ose programet. Fatkeqësisht, nuk mund të krijonim me efektivitet një rregull funksional për murin mbrojtës që të zbatohej vetëm për komandat e nisura nga struktura e Codex për disa arsye:

• Windows nuk lejon përputhjen e një rregulli të firewall-it me identitetin jo-principal të një token-i të kufizuar. Kjo do të thotë se nuk mund të zbatonim një rregull të murit mbrojtës për “çdo token që përfshin SID-in tonë sintetik në listën e identifikuesve të kufizuar SID”.
• Megjithëse mund të krijonim një rregull të murit mbrojtës që përputhet me një skedar specifik të ekzekutueshëm, kjo na lejon vetëm që të kufizojmë lidhjen e rrjetit për vetë codex.exe. Kjo nuk do të zbatohej për proceset që agjenti nis për llogari të përdoruesit, si proceset Git ose Python.
• Edhe dimensionet e tjera të përputhjes së firewall-it kishin formë të gabuar. Rregullat me fushëveprim përdoruesi vazhdonin të përputheshin me përdoruesin real të Windows-it në dizajnin pa privilegje të ngritura, jo vetëm me procesin fëmijë të kufizuar. Rregullat e shtegut të programit ishin tepër të përgjithshme: ato mund të bllokonin codex.exe ose python.exe në përgjithësi, por jo këtë thirrje të izoluar në sandbox të python.exe. Rregullat e bazuara në porta ose adresa ishin gjithashtu një politikë krejtësisht e gabuar. Për shembull, nuk donim të bllokonim portën 443; donim të bllokonim aksesin dalës arbitrar për këtë pemë specifike të kufizuar procesesh.

Për të zbatuar një rregull të murit mbrojtës në mënyrë specifike për komandat tona të sandbox-it, duhej t’i ekzekutonim ato si një entitet i veçantë, jo si përdoruesi “real”. Kjo qasje na çoi në një rrugë të re, një rrugë ku e zbutëm kufizimin tonë “pa rritje privilegjesh”.

Rasti tjetër i përsëritur i sandbox-it, që është edhe zbatimi ynë aktual, kërkon leje të rritura administratori në kohën e konfigurimit. Për këtë arsye i referohem si “sandbox me rritje privilegjesh”. Në kufirin ku Codex nis një komandë në sistem, sandbox-i me rritje privilegjesh ngjan me atë pa rritje privilegjesh. Ai ekzekuton përsëri proceset dytësore nën një token të kufizuar, në mënyrë të ngjashme një token— write_restricted me të njëjtën listë të kufizuar identifikuesish SID me [Everyone, Logon, Synthetic]—megjithatë entiteti i këtij tokeni nuk është më përdoruesi aktual i Windows, por një nga dy përdoruesit lokalë të krijuar nga vetë Codex:

• CodexSandboxOffline (ai që synohet nga rregullat e murit mbrojtës)
• CodexSandboxOnline (ai që nuk synohet nga rregullat e murit mbrojtës)

Ky detaj në dukje i vogël në fakt ka pasoja të mëdha për sandbox-in, kush mund ta përdorë atë dhe kompleksitetin e konfigurimit dhe ekzekutimit të tij.

Ai është vizualisht i ngjashëm me prototipin pa rritje privilegjesh, me prezantimin e rregullave të murit mbrojtës dhe të një përdoruesi të dedikuar të Windows, i cili ekzekuton aktualisht komandat. (Sidoqoftë, prezantimi i këtyre koncepteve të reja do të thotë se ka më shumë punë për t'u bërë për konfigurimin para se sandbox-i të mund të fillojë të ekzekutojë dhe të mbrojë komandat.)

Dizajni i sandbox-it pa rritje privilegjesh kishte një hap të thjeshtë konfigurimi, por ishte relativisht i vogël:

• Krijo një identifikues sintetik SID nëse është e nevojshme
• Zbato listën ACL për identifikuesin sintetik SID sandbox-write

Sandbox-i me rritje privilegjesh, sidoqoftë, ka më shumë për të bërë.

• Krijo një identifikues sintetik SID, nëse nuk është krijuar tashmë
• Krijo përdoruesit në linjë dhe jashtë linje të sandbox-it, nëse nuk janë krijuar tashmë
• Ruani kredencialet e përdoruesve të sapokrijuar në nivel lokal dhe enkriptojini duke përdorur Windows Data Protection API (DPAPI) në një vend ku përdoruesit e sandbox-it nuk mund t'i lexojnë realisht
• Krijoni rregulla për murin mbrojtës që bllokojnë të gjithë qasjen dalëse të rrjetit për përdoruesin CodexSandboxOffline ose, nëse ekzistojnë tashmë, vërtetoni që janë të sakta

Ka një ndërlikim shtesë në fazën e konfigurimit. Pritet që mjedisi sandbox i Codex të ketë akses leximi të barasvlershëm me atë të përdoruesit aktual të Windows-it. Në sandbox-in pa privilegje të ngritura, ku SID-i kryesor i token-it të kufizuar ishte përdoruesi i Windows-it, kjo u arrit. Megjithatë, kjo nuk vjen pa kosto kur principali bëhet një përdorues i ri i CodexSandbox. Shumë drejtori përkatëse në Windows do t’u japin “Përdoruesve të autentikuar” leje për lexim/ekzekutim. Një shembull i dukshëm është drejtoria e profilit të përdoruesit. Si parazgjedhje, përdoruesit e Windows nuk mund të lexojnë drejtoritë e profilit të përdoruesve të tjerë të Windows, kështu që edhe operacionet e thjeshta të leximit të skedarëve në shumë skenarë do të dështonin.

Për ta zgjidhur këtë, ne shtuam një shtresë tjetër në procesin e konfigurimit të sandbox-it - një për dhënien e listave ACL të leximit për përdoruesit e sandbox-it kur ACL të tilla mund të mos ekzistojnë tashmë. Për shembull, te disa drejtori të Windows-it që përdoren zakonisht:

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

Meqenëse kjo listë direktorish është më e mira e mundshme dhe instalimi i ACL-ve në secilin prej tyre mund të jetë mjaft i kushtueshëm, ne e ekzekutojmë këtë logjikë në mënyrë asinkrone, në mënyrë që hapi i konfigurimit të sandbox-it, i cili i bllokon përdoruesit, të mos duhet të presë për përfundimin e tyre.

E kemi kapsuluar logjikën e konfigurimit në një skedar binar më vete, pjesërisht për të kaluar kufirin e UAC-së vetëm kur është e nevojshme. Por arsyeja më e thellë ishte arkitekturore: konfigurimi i sandbox-it ka një detyrë thelbësisht të ndryshme nga codex.exe. Mbajtja e logjikës së konfigurimit të sandbox-it në një skedar të ekzekutueshëm të dedikuar lejoi që codex.exe të qëndronte si një strukturë normale pa rritje privilegjesh; bëri që proceset e konfigurimit vetëm për Windows të mos e ngadalësonin codex.exe në platforma të tjera; shkëputi punën më të gjatë të konfigurimit nga kohëzgjatja e procesit kryesor; si dhe na dha një vend ku të menaxhonim shtigjet e ndryshme të konfigurimit që i duheshin sandbox-it.

Për shkak të mënyrës se si funksionojnë kufijtë për identifikimin e përdoruesve dhe tokenëve në Windows, nuk mund të vazhdonim të krijonim një token të kufizuar dhe të nisnim një proces nën të në të njëjtën mënyrë si me sandbox-in pa rritje privilegjesh. Për të nisur aktualisht komanda si një përdorues i ndryshëm i Windows, ideja jonë e parë ishte rrjedha në vijim:

• codex.exe ekzekutohet si përdoruesi real i Windows-it. Më pas, në një sekuencë, Codex:
  • Thërret LogonUserW(...) për përdoruesin e sandbox-it.
  • Thërret CreateRestrictedToken(...) në atë token të përdoruesit të sandbox-it.
  • Duke përdorur atë token të kufizuar të përdoruesit të sandbox-it, thërret CreateProcessAsUserW(...) për të nisur procesin dytësor përfundimtar.

Në praktikë, ajo rrjedhë e dëshiruar nuk funksionoi për shkak të një barriere privilegjesh te CreateProcessAsUserW(...). Kjo do të thotë se codex.exe mund të krijonte një token të kufizuar për përdoruesin e sandbox-it, por nuk mund të niste në mënyrë të besueshme një proces fëmijë me atë token nga ana e përdoruesit real të kufirit. Na nevojitej një proces që tashmë po ekzekutohej si përdoruesi i sandbox-it—kjo do të mundësonte që hapi i kufizimit dhe krijimi përfundimtar i procesit të ndodhnin në anën e kufirit që i përket përdoruesit të sandbox-it, dhe jo në anën që i përket përdoruesit real.

Kjo kërkesë çoi te codex-command-runner.exe, një skedar binar i ri, detyra e vetme e të cilit është të krijojë një token të kufizuar dhe të nisë komandën e kërkuar. Në vend që t’i kërkonim codex.exe ta bënte të gjithë rrjedhën vetë (përdoruesi real → përdoruesi i sandbox-it → tokeni i kufizuar → procesi dytësor), ne e ndamë rrjedhën në dy pjesë:

Pjesa 1

• codex.exe thërret CreateProcessWithLogonW(...) për të nisur codex-command-runner.exe si përdorues i sandbox-it, pa përdorur ende një token të kufizuar.

Pjesa 2

• Brenda ekzekutuesit, OpenProcessToken(GetCurrentProcess(), ...) hap tokenin e vet të ekzekutuesit, i cili i përket tashmë përdoruesit të sandbox-it.
• Ekzekutuesi thërret GetTokenInformation(...) për të nxjerrë identifikuesin SID të identifikimit të sandbox-it, pastaj CreateRestrictedToken(...) për të ndërtuar tokenin përfundimtar të kufizuar.
• Akoma brenda ekzekutuesit, ai thërret CreateProcessAsUserW(...) me atë token të kufizuar për të nisur procesin dytësor real.

Albert Anjshtajn tha: “Çdo gjë duhet bërë sa më e thjeshtë të jetë e mundur, por jo më e thjeshtë.” Në këtë frymë, dizajni ynë zgjidhi në mënyrë të përshtatshme çdo problem. Arkitektura përfundimtare ka katër shtresat që i kemi mbuluar më parë:

• Vetë codex.exe
• codex-windows-sandbox-setup.exe për menaxhimin e gjithë punës së konfigurimit me privilegje të rritura
• codex-command-runner.exe për ekzekutimin e komandave me tokenë të kufizuar
• Procesi dytësor

Kur u afrova fillimisht në këtë projekt, nuk kisha një ide të mirë se ku do të përfundonte. Qasja ime ishte të filloja duke shfrytëzuar aftësinë e sandbox-it në kufirin midis Codex dhe sistemit operativ. Kjo qasje përputhet shumë me mënyrën se si zbatohet sandbox-i i Codex në MacOs dhe Linux.

Kur mësova më shumë rreth mjeteve specifike që ofron Windows, dhe përmes dhjetëra vendimeve që balanconin sigurinë dhe lehtësinë e përdorimit, sistemi u rrit në formën e tij aktuale - shumë skedarë të ekzekutueshëm, përdorues të personalizuar, rregulla të murit mbrojtës, një hap konfigurimi me privilegje të rritura, procese asinkrone dhe më shumë.

Nuk është një sistem veçanërisht i thjeshtë, por çdo pjesë e kompleksitetit është shtuar nga nevoja, për të ndërtuar një sandbox që është i sigurt, por edhe, sa më shumë që të jetë e mundur, jo pengesë për përdoruesin.

Në punën tonë për të ofruar një eksperiencë të mirë përdoruesi për përdoruesit e Codex në Windows, objektivi ynë ishte të bënim diçka të sigurt që nuk bënte kompromis për dobinë - i gjithë qëllimi i përdorimit të Codex është që agjentët të jenë në gjendje të bëjnë punën pa pasur nevojë për vëmendje të vazhdueshme.

Një nga mësimet më të mëdha nga ky projekt ishte se Windows nuk na dha një element bazë të vetëm që përputhet plotësisht për “agjentin autonom dhe të sigurt të kodimit”. Ne kompozuam disa mjete dhe koncepte për të ndërtuar diçka koherente. Disa ide të fillimit ishin rrugë pa krye. Dizajni përfundimtar ishte një hibrid i prototipave të mëparshëm ku secili zgjidhte një pjesë të problemit.

Mësimi tjetër ishte se siguria për një agjent kodimi është diçka tërësisht ndryshe nga siguria më klasike e aplikacioneve. Codex duhet të funksionojë për rrjedha reale pune të zhvilluesit. Puna inxhinierike kishte të bënte me ekulibrimin e përputhshmërisë me ngarkesat e punës së agjentëve ndaj zbatimit real. Kjo përballje i dha formën kompromiseve në dizajnin përfundimtar.

Ke kureshtje të shohësh sandbox-in e Codex në veprim? Provoje⁠.