Drošas un efektīvas smilškastes izveide, lai iespējotu Codex lietošanu Windows vidē

Kad 2025. gada septembrī pievienojos Codex inženieru komandai, Codex darbam Windows vidē nebija izmēģināšanas vides ieviešanas, kas nozīmēja, ka Windows lietotājiem, izmantojot OpenAI kodēšanas aģentus, bija jāizvēlas starp divām neapmierinošām iespējām:

1. Gandrīz katras komandas (pat lasīšanas darbību) apstiprināšana, ko kodēšanas aģents vēlējās izpildīt, kas ir neefektīvi un apgrūtinoši. Būtiska Codex izmantošanas priekšrocība ir tā, ka viss apnicīgais darbs nav jādara pašrocīgi.
2. Pilnas piekļuves režīma iespējošana: ļaut Codex izpildīt visas komandas bez apstiprinājuma vai ierobežojumiem, kas novērš procesa aizturi uz pārraudzības rēķina.

Codex⁠, mūsu kodēšanas aģents, darbojas izstrādātāju klēpjdatoros neatkarīgi no tā, vai tiek izmantots CLI, IDE paplašinājums vai darbvirsmas lietotne. Tas pārvalda sarunu starp cilvēku pie tastatūras un mākonī darbojošos modeli, kas veic inferenci.

Codex pēc noklusējuma darbojas ar reāla lietotāja atļaujām, kas nozīmē, ka tas var darīt visu, ko lietotājs. Tas ir jaudīgi, bet potenciāli bīstami. Kodēšanas modelis var dot norādi izpildes ietvaram lokāli palaist komandas, sākot no testu veikšanas līdz faila lasīšanai vai rediģēšanai un Git atzara izveidei, tāpēc Codex noklusējuma režīms cenšas rast līdzsvaru starp efektivitāti un drošību. Šajā noklusējuma režīmā Codex var lasīt failus jebkurā vietā un rakstīt failus tavā darbvietā (t. i., direktorijā, kurā palaid Codex), bez interneta piekļuves, ja vien nenorādi, ka to vēlies. Lai automātiski nodrošinātu failu rakstīšanas un tīkla piekļuves ierobežojumus drošās robežās, Codex ir nepieciešama smilškastes vide, kas šos ierobežojumus tiešām liek ievērot.

Smilškaste ir ierobežota izpildes vide. Kad izstrādātājs izmanto Codex, viņa datora operētājsistēma palaiž komandu ar samazinātām atļaujām, un šie ierobežojumi tiek pārmantoti procesa koka ietvaros. Katra Codex komanda jau no sākuma tiek izolēta smilškastē, un katrs tās atvasinātais process paliek tajās pašās robežās.

Lai izveidotu efektīvu smilškasti, Codex ir nepieciešamas datora operētājsistēmas līmeņa izolācijas funkcijas. Dažās operētājsistēmās ir pieejamas utilītprogrammas, kas šo uzdevumu pilda teicami (piemēram, Seatbelt operētājsistēmā MacOs, seccomp vai bubblewrap Linux vidē), taču Windows standarta komplektācija šādu iespēju pagaidām nepiedāvā.

Lai Codex lietošana Windows vidē būtu tikpat droša un ērta kā citās platformās, mums nācās izstrādāt pašiem savu smilškasti.

Windows piedāvā vairākus izolācijas rīkus un pamatelementus. Lai gan neviens no tiem pilnībā neatbilda mūsu prasībām, mēs izvērtējām vairākus iespējamos risinājumus, proti, AppContainer, Windows Sandbox un obligātās integritātes kontroles marķēšanu.

AppContainer

• Kas tas ir: AppContainer ir Windows iebūvētā smilškaste – uz iespējām balstīts izolācijas modelis, kas izstrādāts lietotnēm, kurām jau iepriekš ir precīzi zināmi nepieciešamie piekļuves resursi.
• Kāpēc: Tas ir pievilcīgs risinājums, jo piedāvā reālu operētājsistēmas (OS) robežu, nevis tikai ierobežojumus bez stingrām garantijām.
• Kāpēc nē: Codex nav viena lietotne ar šauri definētu tvērumu. Tas atbalsta atvērtus izstrādātāju darba procesus: čaulas, Git, Python, pakotņu pārvaldniekus, būvēšanas rīkus un jebkurus citus bināros failus, kas aģentam var būt nepieciešami. Praksē tas padarīja AppContainer par šai problēmai nepiemērotu risinājumu. Tā nodrošināja spēcīgu izolāciju, taču daudz šaurākam darba slodžu klāstam nekā “ļaut aģentam darboties kā izstrādātājam”.

Windows Sandbox

• Kas tas ir: Windows Sandbox ir Microsoft vienreizlietojama, viegla virtuālā mašīna. Tu iegūsti jaunu Windows darbvirsmu ar stingru izolācijas robežu, un viss, ko tajā dari, pazūd, kad sesija beidzas.
• Kāpēc: Interesanti acīmredzamu iemeslu dēļ – tas ir daudz saderīgāks ar patvaļīgu programmatūru nekā AppContainer, un no drošības viedokļa tā ir daudz spēcīgāka izolācijas vide.
• Kāpēc nē: Codex ir jādarbojas tieši lietotāja faktiskajā darba vidē, rīkos un sistēmā, nevis atsevišķā vienreizlietojamā darbvirsmā, kurai būtu nepieciešama iestatīšana un saimnieka/viesa savienošana. Tam bija arī būtiska produkta problēma: funkcija Windows Sandbox pat nav pieejama Windows Home SKU laidienos.

Obligātās integritātes kontroles (MIC) integritātes marķēšana

• Kas tas ir: Operētājsistēmā Windows ir jēdziens “integritātes līmeņi”, piemēram, zems, vidējs un augsts, kas nosaka, cik lielā mērā sistēma uzticas objektiem un procesiem. Pamatnoteikums ir tāds, ka process ar zemāku integritātes līmeni nevar rakstīt objektā ar augstāku integritātes līmeni, pat ja parastais ACL to citādi atļautu. Piemēram, zemas integritātes process tiek uzskatīts par mazāk uzticamu, tāpēc Windows bloķē tā iespēju rakstīt parastos vidējas integritātes objektos, ja vien šie objekti nav nepārprotami pārmarķēti, lai to atļautu.
• Kāpēc: Teorētiski MIC risinājums šķita elegants – palaist Codex ar zemas integritātes līmeni, pārzīmēt rakstāmos saknes direktorijus kā zemas integritātes un ļaut Windows visur citur nodrošināt aizliegumu rakstīšanai. Tas mums būtu nodrošinājis ceļu bez administratora tiesībām, kas balstīts uz reālu operētājsistēmas mehānismu.
• Kāpēc nē: Tāpat kā ACL, integritātes etiķetes modificē reālo resursdatora failu sistēmu, un šajā gadījumā semantiskās izmaiņas ir īpaši plašas. Darbvietas atzīmēšana kā zemas integritātes nenozīmē tikai “Codex var šeit rakstīt”. Tas nozīmē, ka procesi ar zemu integritātes līmeni kopumā var tur veikt ierakstus. Reālā izstrādātāja datorā tas pārvērš lietotāja faktisko izgūto darba kopiju par resursdatora zema integritātes līmeņa uztvērēju, kas ir daudz riskantāk nekā rūpīgi mērķētu ACL piešķiršana vienam smilškastes risinājumam. Pat ja vidējas integritātes izstrādātāja rīki turpina darboties, darbvietas pamatā esošais uzticamības modelis ir mainījies tādā veidā, ko ir grūti ierobežot un vēl grūtāk pamatot.

Izvērtējuši visas iespējas un atzinuši tās par nederīgām, mēs sākām izstrādāt savu risinājumu, lai nodrošinātu kvalitatīvu Codex lietošanas pieredzi Windows lietotājiem.

Mūsu pirmais funkcionējošais prototips izmantoja Windows koncepciju un rīku kombināciju, lai ieviestu mums nepieciešamo izolāciju. Jau no paša sākuma viens no mērķiem bija panākt, lai tas darbotos, neprasot privilēģiju paaugstināšanu, proti, lai Codex nevajadzētu rādīt lietotājam uzvedni par administratora privilēģijām tikai tādēļ, lai iestatītu vai palaistu smilškasti. Tas nozīmēja izdomāt, kā noteikt saprātīgus ierobežojumus divām lietām: rakstīšanai failos un piekļuvei tīklam.

Ja mēs vispār neierobežotu failu rakstīšanu, rastos drošības riski. Savukārt, ierobežojot to pārāk stingri, ciestu lietotāja produktivitāte, jo sistēma pastāvīgi prasītu apstiprinājumu. Lai to atrisinātu, mēs izmantojām divus būtiskus Windows arhitektūras elementus: SID un rakstīšanas ierobežotās tekstvienības.

SID jeb drošības identifikators ir identitāte, ko Windows saista ar atļaujām. Katram lietotājam ir SID, grupām ir SID, un pat viena pieteikšanās sesija iegūst savu SID. Piemēram, pašreizējai sesijai, kurā lietotājs ir pieteicies, var būt šāds SID: S-1-5-5-X-Y. Vietējo administratoru grupai piešķirtais SID varētu būt S-1-5-32-544.

Windows ļauj izveidot arī sintētiskus SID, kas nav piesaistīti reāliem lietotājiem, taču ir izmantojami ACL. Šie saraksti nosaka, kam ir tiesības lasīt/rakstīt vai izpildīt konkrētus failus vai direktorijus. Tādējādi SID kļūst par noderīgu pamatelementu mūsu smilškastei: mēs varam izveidot unikālus SID tieši Codex vajadzībām, neietekmējot pārējos sistēmas iestatījumus.

Procesa tekstvienības ir drošības objekti operētājsistēmā Windows, kas nosaka identitāti un privilēģijas izpildes procesam. Tie nosaka, kādas darbības process var veikt. Tekstvienība ar rakstīšanas ierobežojumu ir īpašs procesa tekstvienības veids, kas liek sistēmai Windows veikt papildu piekļuves pārbaudi rakstīšanas darbībām.

Lai rakstīšana būtu sekmīga, ir jāizpilda divas pārbaudes:

1. Parastajai lietotāja identitātei (tekstvienībai “owner”) ir jābūt atļaujai to darīt
2. Vismaz vienam SID tekstvienības ierobežoto SID sarakstā ir jābūt arī piešķirtai piekļuvei

Praksē šīs pārbaudes mums ļauj izmantot ACL, lai precīzi noteiktu, kur smilškaste drīkst modificēt failu sistēmu, nodrošinot nepieciešamo granulitāti rakstīšanas darbībām.

Izmantojot SID un rakstīšanai ierobežotas pilnvaras mūsu neprivileģētā smilškaste darbojās šādi:

1. Smilškastes iestatīšanas laikā tika izveidots sintētisks SID ar nosaukumu sandbox-write.
2. sandbox-write SID tika piešķirta rakstīšanas, izpildes un dzēšanas piekļuve
   1. Pašreizējais darba direktorijs
   2. Visi papildu writable_roots ieraksti, kas konfigurēti failā config.toml.
3. Smilškastes iestatījumos šim pašam SID tika skaidri liegta rakstīšanas piekļuve “tikai lasāmajām, bet rakstāmajā vidē esošajām” atrašanās vietām, piemēram:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex palaida komandas ar rakstīšanai ierobežotu tekstvienību, kuras ierobežoto SID sarakstā ir iekļauts Everyone, pašreizējās pieteiktās sesijas SID un sintētiskais SID sandbox-write.

Šī plūsma efektīvi atrisināja failu rakstīšanas ierobežošanu un šķita daudzsološa. Tagad mums bija nepieciešams risinājums smilškastes tīkla piekļuves ierobežošanai.

Tīkla piekļuves ierobežošana ir svarīga smilškastes daļa – bez tās ļaunprātīgs kods varētu nopludināt datus no datora internetā. Tā kā vēlējāmies izvairīties no paaugstinātu tiesību prasībām, mūsu iespējas iespējas stingri bloķēt tīkla trafiku bija ierobežotas. Rīkus, kurus vēlējāmies izmantot, piemēram, Windows ugunsmūri, parasti nevarēja instalēt bez administratora atļaujas.

Tā kā Windows ugunsmūris nebija pieejams kā iespēja, mēs ierobežojām to, ko varējām kontrolēt. Mēs centāmies panākt, lai pakārtotā vide atteices gadījumā paliktu slēgta tiem tīklā darbojošajiem rīkiem, kurus izstrādātāji faktiski izmanto, lai Git komandas, pakotņu instalētāji u.c. smilškastē neizdotos un lietotājam būtu jāapstiprina jebkuras ar internetu saistītas darbības. Iecere bija padarīt acīmredzamos atkāpšanās ceļus nelietojamus: sūtīt starpniekserveri atbalstošu datplūsmu uz nestrādājošu galapunktu, likt Git HTTP(S) transportam darīt to pašu un panākt, lai Git, izmantojot SSH, nekavējoties beigtos ar kļūdu. Turklāt mēs pievienojām nelielu denybin direktoriju PATH sākumā un pārkārtojām PATHEXT, lai SSH un SCP aizstājējskripti tiktu atrasti pirms īstajiem binārajiem failiem.

Piemēram, šeit ir daži no konkrētajiem vides aizstāšanas iestatījumiem, ko izmantojām tīkla piekļuves ierobežošanai:

• 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

Tas aptvēra lielu daļu parastās rīku radītās datu plūsmas, taču joprojām bija tikai rekomendējošs mehānisms. Process varēja ignorēt vidi, apiet PATH vai tieši atvērt tīkla ligzdas – tas bija pārāk riskanti.

Tāpat kā jebkurai interesantai programmatūras ieviešanai, pirmajam prototipam bija savi plusi un mīnusi. Lai gan tas paveica uzdevumu, izmantojot tikai dažas standarta Windows iespējas, ļāva veikt ļoti precīzas un detalizētas rakstīšanas darbības failu sistēmā un darbojās bez paaugstinātām tiesībām, tādējādi novēršot nepieciešamību lietotājiem apstiprināt pārmērīgas tiesību paaugstināšanas uzvednes vai būt administratoriem savā lokālajā datorā, tam bija arī būtiski trūkumi, kas liedza tam kļūt par mūsu galīgo risinājumu:

• Iestatīšanas ātrums: darbvietas ACL piemērošana var būt resursietilpīga atkarībā no darbvietas direktorija topoloģijas.
• Ietekme uz sistēmu: mēs piemērojām reālus ACL izstrādātāja sistēmai, lai gan šī ietekme nav pārlieku invazīva, jo visi piemērotie ACL attiecas uz īpaši izveidotu sintētisku SID, ko izmanto tikai smilškaste.
• Grūti maināma semantika: atkarība no ACL failu līmeņa ierobežojumiem nozīmē, ka smilškastes semantikas maiņa ir dārga un sarežģīta. Savukārt macOS vidē mēs varam dinamiski mainīt veidu, kā tiek ģenerēts .sbpl fails, kas tiek izmantots Seatbelt konfigurēšanai, bet Windows smilškastei ACL pielāgošana var prasīt lēnu un intensīvu darbību.
• Tīkla aizsardzība ir vāja. Kā minēts iepriekš, tā bija “rekomendējoša”, to noteikti apietu dažas programmas, kas ieviesa savu tīkla steku, un tā nebija paredzēta, lai izturētu ļaunprātīgu kodu.

Pirmās trīs problēmas ir raksturīgas pielāgotai smilškastes sistēmas ieviešanai, kas ir pietiekami elastīga aģentu darba plūsmām. Taču stāsts par tīkla ierobežošanu bija citāds.

Papildus tam, ka ļaundabīgs aģents varētu viegli apiet uz vidi balstīto tīkla ierobežošanu, to darītu arī daudzi labticīgi kodi vai binārie faili, ja tie vienkārši neievērotu vides starpniekservera mainīgos vai izmantotu savu uz ligzdām balstītu kodu. Mēs uzskatījām, ka ar to pietiek, lai ieguldītu labākā smilškastes režīmā.

Lai panāktu labāku tīkla ierobežošanu, mēs vēlējāmies izmantot Windows ugunsmūri, kas ļauj bloķēt izejošo tīkla trafiku lietotājiem vai programmām. Diemžēl vairāku iemeslu dēļ mēs nevarējām efektīvi izveidot funkcionālu ugunsmūra noteikumu, kas attiektos tikai uz komandām, ko palaiž Codex ietvars:

• Windows neļauj saskaņot ugunsmūra noteikumu ar ierobežotas tekstvienības neprimāro identitāti. Tas nozīmē, ka mēs nevarējām piemērot ugunsmūra noteikumu “jebkurai tekstvienībai, kuras ierobežoto SID sarakstā ir mūsu sintētiskais SID”.
• Lai gan mēs varētu izveidot ugunsmūra kārtulu, kas atbilst konkrētam binārajam failam, tas ļautu ierobežot tīklu tikai pašam codex.exe. Tas neattiektos uz procesiem, kurus aģents palaiž lietotāja vārdā, piemēram, Git vai Python procesiem.
• Arī citām ugunsmūra atbilstības dimensijām bija nepareiza forma. Lietotāja tvēruma kārtulas nepaaugstināto privilēģiju projektējumā joprojām atbilda īstajam Windows lietotājam, nevis tikai ierobežotajam bērnprocesam. Programmu ceļu kārtulas bija pārāk vispārīgas: tās varēja kopumā bloķēt codex.exe vai python.exe, bet ne šo konkrēto smilškastē izolēto python.exe izsaukumu. Arī kārtulas, kuru pamatā ir porti vai adreses, bija pilnīgi nepareiza politika. Piemēram, mēs nevēlējāmies bloķēt 443. portu – mēs vēlējāmies bloķēt jebkādu izejošo piekļuvi šim konkrētajam ierobežotajam procesu kokam.

Lai piemērotu ugunsmūra kārtulu tieši mūsu smilškastē palaistajām komandām, tās bija jāpalaiž kā atsevišķa identitāte, nevis kā “īstais” lietotājs. Šī pieeja mūs aizveda pie jauna risinājuma, kurā mēs mazinājām ierobežojumu attiecībā uz tiesību paaugstināšanu.

Nākamā smilškastes iterācija, kas ir mūsu pašreizējā ieviešana, iestatīšanas laikā prasa privileģētas administratora tiesības. Tāpēc es to dēvēju par “privileģēto smilškasti”. Robežpunktā, kur Codex sistēmā palaiž komandu, izolētā vide ar paaugstinātām privilēģijām izskatās tāpat kā izolētā vide bez paaugstinātām privilēģijām. Tā joprojām palaiž bērnprocesus ar ierobežotu tekstvienību – līdzīgi kā write_restricted tekstvienību ar to pašu ierobežoto SID sarakstu [Everyone, Logon, Synthetic]–, tomēr šīs tekstvienības drošības subjekts vairs nav faktiskais Windows lietotājs, bet gan viens no diviem lokālajiem lietotājiem, ko izveidojis pats Codex:

• CodexSandboxOffline (tas, uz kuru attiecas ugunsmūra noteikumi)
• CodexSandboxOnline (tas, uz kuru ugunsmūra noteikumi neattiecas)

Šai šķietami sīkajai detaļai patiesībā ir liela ietekme uz smilškasti, to, kas to var izmantot, kā arī uz tās iestatīšanas un izpildes sarežģītību.

Vizuāli tā ir līdzīga neprivileģētajam prototipam, bet ar ugunsmūra noteikumu un īpaša Windows lietotāja ieviešanu, kurš faktiski izpilda komandas. (Tomēr šo jauno jēdzienu ieviešana nozīmē, ka pirms smilškastes palaišanas un komandas izolēšanas ir jāveic vairāk sagatavošanas darbu.)

Neprivileģētās smilškastes dizainam bija vienkāršs iestatīšanas solis, taču tas bija salīdzinoši neliels:

• Izveidot sintētisku SID, ja nepieciešams
• Piemērot ACL ierobežotajam “sandbox-write” sintētiskajam SID

Taču saistībā ar privileģēto smilškasti ir vairāk darāmā.

• Izveidot sintētisku SID, ja tas vēl nav izveidots
• Izveidot tiešsaistes un bezsaistes smilškastes lietotājus, ja tie vēl nav izveidoti
• Lokāli saglabāt jaunizveidoto lietotāju pieteikšanās datus un šifrēt tos ar Windows Data Protection API (DPAPI) vietā, kur paši smilškastes lietotāji nevar nolasīt
• Izveidot ugunsmūra noteikumus, kas bloķē visu izejošo tīkla piekļuvi lietotājam CodexSandboxOffline, vai, ja tie jau pastāv, pārbaudīt to pareizību

Iestatīšanas posmā ir vēl kāds papildu sarežģījums. Paredzams, ka Codex smilškastei būs lasīšanas piekļuve, kas ir līdzvērtīga faktiskā Windows lietotāja piekļuvei. Neprivileģētajā smilškastē, kur ierobežotās tekstvienības galvenais SID bija Windows lietotājs, tas tika panākts. Tomēr tas nenotiek bez papildu izmaksām, kad drošības subjekts kļūst par jaunu CodexSandbox lietotāju. Daudzi attiecīgie direktoriji operētājsistēmā Windows piešķir lasīšanas/izpildes atļaujas “Autentificētie lietotāji”. Viens ievērojams piemērs ir lietotāja profila direktorijs. Pēc noklusējuma Windows lietotāji nevar lasīt citu Windows lietotāju profilu direktorijus, tāpēc daudzos gadījumos neizdotos pat vienkāršas failu nolasīšanas operācijas.

Lai to risinātu, mēs smilškastes iestatīšanas procesam pievienojām vēl vienu slāni – tādu, kas piešķir lasīšanas ACL smilškastes lietotājiem tur, kur šādu ACL, iespējams, vēl nav. Piemēram, dažiem bieži izmantotiem Windows direktorijiem:

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

Tā kā šis direktoriju saraksts ir indikatīvs un ACL iestatīšana katram no tiem var būt diezgan resursietilpīga, mēs šo loģiku darbinām asinhroni, lai smilškastes iestatīšanas solim, kas parasti bloķē lietotāja darbības, nebūtu jāgaida, līdz process tiek pabeigts.

Mēs nodalījām iestatīšanas loģiku atsevišķā binārfailā, daļēji tādēļ, lai UAC robežu šķērsotu tikai tad, kad tas ir nepieciešams. Taču dziļākais iemesls bija arhitektūras rakstura: smilškastes iestatīšana principiāli pilda citu funkciju nekā codex.exe. Iestatīšanas loģikas turēšana atsevišķā binārajā failā ļāva codex.exe saglabāt parastu, neprivileģētu ietvaru, neļāva Windows specifiskajai iestatīšanas mašinērijai pārblīvēt codex.exe citās platformās, nodalīja laikietilpīgo iestatīšanas darbu no galvenā procesa dzīves cikla un deva mums vienu vietu, kur apstrādāt dažādos smilškastei nepieciešamos iestatīšanas ceļus.

Windows lietotāju un pilnvaru pieteikšanās robežu darbības principu dēļ mēs vairs nevarējām turpināt izveidot ierobežotu tekstvienību un palaist procesu tāpat, kā to darījām neprivileģētajā smilškastē. Lai komandas palaistu cita Windows lietotāja vārdā, mūsu sākotnējā ideja bija šāda plūsma:

• codex.exe darbojas kā faktiskais Windows lietotājs. Pēc tam secīgi Codex:
  • Izsauc LogonUserW(...) smilškastes lietotājam.
  • Izsauc CreateRestrictedToken(...) šai smilškastes lietotāja tekstvienībai.
  • Izmantojot šo ierobežoto sandbox-user tekstvienību, izsauc CreateProcessAsUserW(...), lai palaistu gala bērnprocesu.

Praksē šī vēlamā plūsma nedarbojās, jo pie CreateProcessAsUserW(...) radās privilēģiju šķērslis. Tas nozīmē, ka codex.exe varēja izveidot ierobežotu tekstvienību smilškastes lietotājam, taču nevarēja uzticami palaist bērnprocesu ar šo tekstvienību no robežas reālā lietotāja puses. Mums bija nepieciešams process, kas jau darbotos ar smilškastes lietotāja tiesībām – tas ļautu ierobežošanas solim un galīgajai procesa palaišanai notikt robežas smilškastes lietotāja, nevis īstā lietotāja pusē.

Šī prasība noveda pie codex-command-runner.exe – jauna binārā faila, kura vienīgais uzdevums ir ģenerēt ierobežotu tekstvienību un palaist pieprasīto komandu. Tā vietā, lai prasītu codex.exe veikt visu plūsmu pašam (īstais lietotājs → smilškastes lietotājs → ierobežota tekstvienība → bērnprocess), mēs sadalījām plūsmu divās daļās:

1. daļa

• codex.exe izsauc CreateProcessWithLogonW(...), lai palaistu codex-command-runner.exe kā smilškastes lietotāju, pagaidām vēl neizmantojot ierobežotu tekstvienību.

2. daļa

• Palaidēja iekšienē OpenProcessToken(GetCurrentProcess(), ...) atver paša palaidēja tekstvienību, kas jau pieder smilškastes lietotājam.
• Palaidējs izsauc GetTokenInformation(...), lai izgūtu smilškastes pieteikšanās SID, un pēc tam CreateRestrictedToken(...), lai izveidotu galīgo ierobežoto tekstvienību.
• Joprojām palaidējā iekšienē tas izsauc CreateProcessAsUserW(...) ar šo ierobežoto tekstvienību, lai palaistu īsto bērnprocesu.

Alberts Einšteins reiz teica: “Visam jābūt tik vienkāršam, cik iespējams, bet ne vienkāršākam”. Šajā garā mūsu dizains pienācīgi atrisināja katru problēmu. Galīgā arhitektūra sastāv no četriem slāņiem, kurus iepriekš apskatījām:

• Pats codex.exe
• codex-windows-sandbox-setup.exe visu ar paaugstinātām privilēģijām saistīto iestatīšanas darbu apstrādei
• codex-command-runner.exe ierobežotu tekstvienību komandu izpildei
• Bērnprocess

Kad pirmo reizi pievērsos šim projektam, man nebija skaidras vīzijas, kāds būs gala rezultāts. Mana pieeja bija sākt ar smilškastes funkcionalitātes ieviešanu robežšķirtnē starp Codex un operētājsistēmu. Šī pieeja cieši atbilst tam, kā Codex smilškaste ir realizēta MacOs un Linux vidēs.

Uzzinot vairāk par specifiskajiem rīkiem, ko piedāvā Windows, un pieņemot desmitiem lēmumu, lai līdzsvarotu drošību un lietošanas ērtumu, sistēma ieguva savu pašreizējo formu – vairāki binārie faili, pielāgoti lietotāji, ugunsmūra noteikumi, paaugstinātu privilēģiju iestatīšanas solis, asinhroni procesi un vēl daudz kas cits.

Tā nav īpaši vienkārša sistēma, taču katrs sarežģītības elements tika pievienots nepieciešamības dēļ, lai izveidotu smilškasti, kas ir gan droša, gan, pēc iespējas mazāk traucējoša lietotājam.

Strādājot ar nolūku nodrošināt labu lietošanas pieredzi Codex lietotājiem Windows vidē, mūsu mērķis bija izveidot kaut ko drošu, neupurējot lietderību. Visa Codex izmantošanas būtība ir ļaut aģentiem paveikt darbu bez lietotāja pastāvīgas uzmanības.

Viena no lielākajām mācībām šajā projektā bija tāda, ka Windows mums nedeva vienu gatavu elementu, kas tieši atbilstu jēdzienam “drošs autonoms kodēšanas aģents”. Mēs apvienojām vairākus rīkus un koncepcijas, lai izveidotu saskaņotu risinājumu. Dažas agrīnās idejas izrādījās strupceļi. Galīgais dizains bija agrāko prototipu hibrīds, kur katrs no tiem atrisināja daļu problēmas.

Vēl viena atziņa bija tāda, ka kodēšanas aģenta drošība būtiski atšķiras no klasiskās lietotņu drošības. Codex ir jāspēj darboties reālās izstrādātāju darba plūsmās. Inženiertehniskais darbs bija saistīts ar līdzsvara atrašanu starp saderību ar aģentiskām darba slodzēm un reālu drošības kontroli. Šī spriedze noteica kompromisus galīgajā dizainā.

Vēlies redzēt Codex smilškasti darbībā? Izmēģini⁠.