Saugios, veiksmingos smėliadėžės kūrimas, kad „Windows“ sistemoje veiktų „Codex“

Kai 2025 m. rugsėjį prisijungiau prie „Codex“ inžinierių komandos, „Windows“ sistemai skirta „Codex“ versija neturėjo bandomosios aplinkos. Vadinasi, „Windows“ naudotojai, dirbdami su „OpenAI“ programavimo agentais, turėjo rinktis vieną iš dviejų nepatogių variantų.

1. Patvirtinti beveik kiekvieną komandą (net ir skaitymo), kurią programavimo agentas nori paleisti, nors tai neefektyvu ir vargina. Juk vienas didžiausių „Codex“ pranašumų – jums nereikia atlikti viso nuobodaus darbo patiems.
2. Įjungti visiškos prieigos režimą ir leisti „Codex“ vykdyti visas komandas be patvirtinimo ar apribojimų. Nors tai pašalina trikdžius, prarandama kontrolė.

Mūsų programavimo agentas Codex⁠ veikia kūrėjų nešiojamuosiuose kompiuteriuose per komandų eilutės sąsają (angl. „Command Line Interface“, CLI), IDE plėtinį ar darbalaukio programą. Jis valdo pokalbį tarp prie klaviatūros sėdinčio žmogaus ir debesyje veikiančio modelio bei užtikrina modelio vykdymą.

Pagal numatytąsias nuostatas „Codex“ veikia turėdamas įprasto naudotojo teises, todėl gali atlikti viską, ką ir pats naudotojas. Tai naudinga, bet kartu gali būti ir pavojinga. Programavimo modelis gali nurodyti infrastruktūrai vykdyti komandas vietiniame įrenginyje – nuo testų paleidimo iki failų skaitymo, redagavimo ar „Git“ atšakos kūrimo. Dėl šios priežasties numatytuoju „Codex“ režimu siekiama rasti optimalią veiksmingumo ir saugos pusiausvyrą. Šis numatytasis režimas leidžia „Codex“ skaityti failus beveik bet kur, o įrašyti – tik jūsų darbo erdvėje (kataloge, kuriame naudojate „Codex“). Be to, prieiga prie interneto nesuteikiama, nebent aiškiai nurodote kitaip. Siekiant automatiškai riboti failų įrašymą ir tinklo prieigą, „Codex“ būtina bandomoji aplinka, gebanti praktiškai taikyti šiuos apribojimus.

Bandomoji aplinka – tai riboto vykdymo aplinka. Kūrėjui naudojant „Codex“, kompiuterio operacinė sistema paleidžia komandą su mažesnėmis teisėmis, o šie apribojimai perduodami toliau visam procesų medžiui. Kiekviena „Codex“ komanda nuo pat pradžių izoliuojama bandomojoje aplinkoje, o kiekvienas išvestinis procesas lieka tose pačiose ribose.

Veiksmingai bandomajai aplinkai sukurti „Codex“ būtinos operacinės sistemos teikiamos izoliavimo funkcijos. Kai kurios operacinės sistemos turi puikiai šią užduotį atliekančių įrankių (pvz., „Seatbelt“ „macOS“ sistemoje, „seccomp“ ar „bubblewrap“ – „Linux“), tačiau „Windows“ šiuo metu iš anksto parengtų tokių galimybių nesiūlo.

Siekdami užtikrinti, kad „Codex“ „Windows“ sistemoje būtų taip pat saugu ir patogu naudoti kaip ir kitur, turėjome sukurti nuosavą bandomąją aplinką.

„Windows“ operacinėje sistemoje yra tam tikrų įrankių ir bazinių elementų procesams izoliuoti. Nors nė vienas jų visiškai netenkino mūsų poreikių, išnagrinėjome kelis galimus sprendimus: „AppContainer“, „Windows Sandbox“ ir „Mandatory Integrity Control“ ženklinimą.

AppContainer

• Kas tai: „AppContainer“ – vietinė „Windows“ bandomoji aplinka. Tai galimybėmis grįstas izoliavimo modelis, sukurtas programoms, iš anksto tiksliai žinančioms, prie ko joms reikės prieigos.
• Kodėl: patrauklu, nes siūlo tikrą operacinės sistemos lygio ribą, o ne tiesiog ribojimus be garantijų.
• Kodėl ne: „Codex“ nėra viena griežtai apibrėžta programa. Ji palaiko atviras kūrėjų darbo eigas: komandų aplinkas, „Git“, „Python“, paketų tvarkytuves, kūrimo įrankius ir visus kitus vykdomuosius failus, kurių gali prireikti agentui. Praktiškai tai reiškė, kad „AppContainer“ šiai problemai spręsti netiko. Nors tai stipri izoliacija, ji skirta gerokai siauresnei darbo krūvių klasei, nei reikalauja siekis „leisti agentui dirbti taip, kaip tai darytų kūrėjas“.

Windows Sandbox

• Kas tai: „Windows Sandbox“ yra vienkartinė ir lengvasvorė „Microsoft“ virtualioji mašina (VM). Jums suteikiamas naujas „Windows“ darbalaukis su stipria izoliavimo riba, o viskas, ką jame atliekate, pasibaigus seansui pradingsta.
• Kodėl: sprendimas įdomus dėl akivaizdžių priežasčių – jis gerokai geriau suderinamas su įvairia programine įranga nei „AppContainer“, be to, užtikrina kur kas patikimesnę saugą.
• Kodėl ne: „Codex“ turi veikti tiesiogiai su faktiniais naudotojo projekto failais, įrankiais ir aplinka, o ne atskirame vienkartiniame darbalaukyje, kuriam reikėtų papildomos sąrankos ir pagrindinės bei svečio sistemų sujungimo. Be to, egzistavo esminė produkto problema: „Windows Sandbox“ net nėra prieinama „Windows Home“ versijose.

Privalomosios vientisumo kontrolės (angl. „Mandatory Integrity Control“, MIC) ženklinimas

• Kas tai: „Windows“ sistemoje taikoma žemo, vidutinio ir aukšto vientisumo lygių (angl. „integrity levels“) koncepcija, nustatanti, kiek sistema pasitiki objektais ir procesais. Pagrindinė taisyklė – mažesnio vientisumo procesas negali įrašyti duomenų į aukštesnio vientisumo objektą, net jei tai leidžia įprastas prieigos kontrolės sąrašas (angl. „Access Control List“, ACL). Pavyzdžiui, žemo vientisumo procesas laikomas mažiau patikimu, todėl „Windows“ neleidžia jam keisti įprastų vidutinio vientisumo objektų, nebent šie objektai aiškiai paženklinti kaip leidžiantys tai daryti.
• Kodėl: teoriškai MIC atrodė puikiai – pakanka paleisti „Codex“ pritaikius žemą vientisumo lygį, paženklinti įrašomuosius šakninius katalogus kaip žemo vientisumo ir leisti operacinei sistemai blokuoti įrašymą visur kitur. Tai būtų leidę veikti be administratoriaus teisių ir naudoti tikrą operacinės sistemos mechanizmą.
• Kodėl ne: kaip ir ACL, vientisumo etiketės keičia tikrąją pagrindinio kompiuterio failų sistemą, tačiau šiuo atveju semantinis pokytis itin platus. Darbo erdvės paženklinimas žemu vientisumo lygiu nereiškia tik to, kad „Codex“ gali čia įrašyti duomenis. Tai reiškia, kad duomenis ten gali įrašyti visi žemo vientisumo procesai. Realaus kūrėjo kompiuteryje naudotojo atsiųsti projekto failai taptų žemo vientisumo duomenų gavėju pagrindinėje sistemoje, o tai gerokai rizikingiau, nei priskirti atidžiai pritaikytus ACL vienai bandomosios aplinkos architektūrai. Net jei vidutinio vientisumo lygio kūrėjo įrankiai ir toliau veikia, pagrindinis darbo erdvės pasitikėjimo modelis pasikeičia taip, kad šį pokytį tampa sunku suvaldyti ir dar sunkiau pateisinti.

Kadangi nuo pat pradžių atmetėme visas šias parinktis kaip netinkamas, ėmėme kurti nuosavą sprendimą, kad „Windows“ naudotojai galėtų sklandžiai dirbti su „Codex“.

Pirmajame veikiančiame prototipe reikiamą izoliaciją įgyvendinome pasitelkę įvairių „Windows“ koncepcijų ir įrankių derinį. Nuo pat pradžių vienas iš tikslų buvo užtikrinti veikimą be teisių lygio padidinimo – vadinasi, vien norint sukonfigūruoti ar paleisti bandomąją aplinką, „Codex“ neprašytų naudotojo suteikti administratoriaus teisių. Tai reiškė, kad reikia rasti būdą, kaip pagrįstai apriboti du dalykus: failų įrašymą ir prieigą prie tinklo.

Jei visiškai neribotume failų įrašymo, kiltų saugos problemų. Jei apribotume per griežtai, bandomoji aplinka trukdytų naudotojo našumui, nes tektų nuolat prašyti patvirtinimų. Šią problemą išsprendėme pasitelkę du svarbius „Windows“ sistemos elementus: SID ir įrašymą ribojančius žetonus.

SID, arba saugos identifikatorius (angl. „security identifier“), – tai tapatybė, kurią „Windows“ susieja su leidimais. Kiekvienas naudotojas ir kiekviena grupė turi po SID, o asmeninį SID gauna net ir pavienis prisijungimo seansas. Pavyzdžiui, aktyvaus prisijungimo seanso SID galėtų atrodyti taip: S-1-5-5-X-Y. Vietinių administratorių grupei priskirtas SID galėtų būti S-1-5-32-544.

„Windows“ taip pat leidžia kurti sintetinius SID. Jie neatitinka realaus naudotojo, bet vis tiek gali būti įtraukiami į ACL, apibrėžiančius, kas gali skaityti, įrašyti ar vykdyti konkrečius failus ar katalogus. Dėl šios priežasties SID tampa naudingu baziniu bandomosios aplinkos elementu: galime sukurti SID, skirtus išimtinai „Codex“ bandomajai aplinkai, ir nesutrikdyti jokio kito kompiuteryje esančio komponento veikimo.

Procesų žetonai – tai „Windows“ saugos objektai, apibrėžiantys vykdomo proceso tapatybę ir teises. Jie nustato, kokius veiksmus procesas gali atlikti. Įrašymą ribojantis žetonas – tai specialus proceso žetono tipas, priverčiantis „Windows“ operacinę sistemą atlikti papildomą prieigos patikrą vykdant įrašymo operacijas.

Kad įrašymas būtų sėkmingas, turi būti įvykdytos dvi sąlygos:

1. tai atlikti turi būti leidžiama įprastai naudotojo tapatybei (žetono „savininkui“);
2. prieiga turi būti suteikta bent vienam SID, esančiam žetono ribojamų SID sąraše.

Praktiškai šios patikros leido pasitelkti ACL, kad tiksliai apibrėžtume, kur bandomoji aplinka gali keisti failų sistemą, ir užtikrintume reikiamą detalumą valdant įrašymo operacijas.

Naudojant SID ir įrašymą ribojančius žetonus, mūsų bandomoji aplinka be padidintų teisių veikė taip:

1. Vykdant sąranką, bandomoji aplinka sukurdavo sintetinį SID, pavadintą „sandbox-write“.
2. Šiam „sandbox-write“ SID buvo suteikiamos skaitymo, vykdymo ir šalinimo teisės į:
   1. dabartinį darbinį katalogą;
   2. visus papildomus įrašomuosius šakninius katalogus (angl. „writable_roots“), sukonfigūruotus faile „config.toml“.
3. Vykdant sąranką, bandomoji aplinka aiškiai uždrausdavo tam pačiam SID rašymo teises į „tik skaityti įrašomojoje aplinkoje“ vietas, pavyzdžiui:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. „Codex“ paleisdavo komandas naudodama įrašymą ribojantį žetoną, kurio ribojamų SID sąraše buvo įtraukta grupė „Visi“ (angl. „Everyone“), aktyvaus prisijungimo seanso SID ir sintetinis „sandbox-write“ SID.

Šis metodas veiksmingai išsprendė failų įrašymo ribojimo problemą ir atrodė daug žadantis. Dabar mums reikėjo sprendimo, kaip apriboti bandomosios aplinkos prieigą prie tinklo.

Prieigos prie tinklo ribojimas – svarbi bandomosios aplinkos dalis; be jo kenkėjiškas kodas galėtų slapta išsiųsti duomenis iš kompiuterio į internetą.Kadangi norėjome išvengti reikalavimo padidinti teises, turėjome nedaug galimybių griežtai blokuoti tinklo srautą.Priemonių, kurių norėjome imtis, pavyzdžiui, „Windows“ užkardos, paprastai nebuvo galima taikyti be administratoriaus teisių.

Neturėdami galimybės naudoti „Windows“ užkardos, apribojome tai, ką galėjome kontroliuoti. Siekėme, kad antrinė aplinka, susidūrusi su kūrėjų realiai naudojamais tinklo įrankiais, pagal numatytąsias nuostatas blokuotų jų veikimą (angl. „fail-closed“). Dėl to „Git“ komandos, paketų diegimo programos ir kiti įrankiai bandomojoje aplinkoje neveiktų, o naudotojui tektų patvirtinti bet kokias su internetu susijusias operacijas. Idėja buvo užblokuoti akivaizdžius apėjimo būdus: nukreipti tarpinius serverius atpažįstantį srautą į neaktyvų prieigos tašką, priversti „Git“ HTTP(S) perdavimą daryti tą patį, o SSH pagrįstam „Git“ taikyti momentinį blokavimą. Be to, į PATH kintamojo pradžią pridėjome nedidelį „denybin“ katalogą ir pakeitėme PATHEXT eiliškumą, kad fiktyvūs (angl. „stub“) SSH ir SCP skriptai būtų iškviečiami greičiau nei tikrieji vykdomieji failai.

Pavyzdžiui, toliau pateikti keli konkretūs aplinkos kintamųjų pakeitimai, kuriuos naudojome prieigai prie tinklo apriboti:

• 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

Tai leido perimti didelę dalį įprasto įrankių generuojamo srauto, tačiau vis tiek buvo tik rekomendacinio pobūdžio.Procesas galėjo ignoruoti aplinką, apeiti PATH kintamąjį ar tiesiogiai atidaryti tinklo lizdus, o tai kėlė per didelę riziką.

Kaip ir bet kuris įdomus programinės įrangos sprendimas, pirmasis prototipas turėjo savų pranašumų ir trūkumų. Nors jis atliko savo darbą pasitelkiant tik kelias standartines „Windows“ funkcijas, leido labai aiškiai ir detaliai kontroliuoti failų sistemos įrašymą ir veikė be padidintų teisių (todėl naudotojams nereikėjo tvirtinti perteklinių teisių padidinimo prašymų ar būti vietiniais administratoriais savo kompiuteriuose), jis turėjo ir rimtų trūkumų.Dėl kai kurių iš jų šio varianto teko atsisakyti kuriant galutinę architektūrą.

• Sąrankos sparta: darbo erdvės ACL taikymas gali būti imlus resursams, atsižvelgiant į darbo erdvės katalogo topologiją.
• Poveikis sistemai: kūrėjo sistemai taikėme tikrus ACL, nors pats poveikis nėra labai invazinis, nes visi taikomi ACL susiję su specialiai sukurtu sintetiniu SID, kurį naudoja tik bandomoji aplinka.
• Sunkiai keičiama semantika: priklausomybė nuo ACL taikant failais pagrįstus apribojimus reiškia, kad keisti bandomosios aplinkos semantiką sudėtinga ir tam reikia daug resursų. Nors „macOS“ sistemoje galime dinamiškai keisti, kaip generuojame „.sbpl“ failą, naudojamą „Seatbelt“ konfigūruoti, „Windows“ bandomojoje aplinkoje ACL koregavimas gali tapti lėta ir resursams imlia operacija.
• Tinklo apsauga – silpna. Kaip minėta, ji buvo tik „rekomendacinė“, todėl ją neabejotinai apeitų programos, turinčios nuosavą tinklo dėklą, be to, ji nebuvo pritaikyta atlaikyti kenkėjiško kodo atakas.

Pirmosios trys problemos būdingos nuosavos bandomosios aplinkos, kuri būtų pakankamai lanksti agentinėms darbo eigoms, integracijai. Tačiau su tinklo srauto ribojimu situacija buvo kitokia.

Maža to, kad kenkėjiškas agentas galėtų lengvai apeiti aplinkos kintamaisiais pagrįstą tinklo apribojimą, jį taip pat apeitų daugybė geranoriško kodo bei vykdomųjų failų, jei jie tiesiog neatsižvelgtų į aplinkos tarpinių serverių kintamuosius arba turėtų įdiegtą nuosavą, tinklo lizdais pagrįstą tinklo kodą. Jautėme, kad šio aspekto pakanka norint pradėti kurti geresnį bandomosios aplinkos režimą.

Norėdami geriau riboti tinklo srautą, siekėme naudoti „Windows“ užkardą, kuri leidžia blokuoti išeinantįjį tinklo srautą naudotojams ar programoms. Deja, dėl kelių priežasčių mums nepavyko sukurti efektyviai veikiančios užkardos taisyklės, kuri būtų taikoma tik „Codex“ infrastruktūros generuojamoms komandoms:

• „Windows“ neleidžia susieti užkardos taisyklės su apriboto žetono nepagrindine tapatybe (angl. „non-principal identity“). Tai reiškė, kad negalėjome taikyti užkardos taisyklės „bet kuriam žetonui, kurio ribojamų SID sąraše yra mūsų sintetinis SID“.
• Nors galėjome sukurti užkardos taisyklę, atitinkančią konkretų vykdomąjį failą, tai leido apriboti tinklo prieigą tik pačiam „codex.exe“. Ji nebūtų taikoma procesams, kuriuos agentas paleidžia naudotojo vardu, pavyzdžiui, „Git“ ar „Python“ procesams.
• Kiti užkardos atitikties kriterijai taip pat netiko. Naudotojo lygmens taisyklės architektūroje be padidintų teisių vis dar atitiko tikrąjį „Windows“ naudotoją, o ne tik apribotą antrinį procesą. Programų keliais pagrįstos taisyklės buvo pernelyg bendro pobūdžio: jos galėjo blokuoti „codex.exe“ arba „python.exe“ apskritai, bet ne konkretų „python.exe“ paleidimą bandomojoje aplinkoje. Prievadais ar adresais pagrįstos taisyklės taip pat buvo visiškai netinkama strategija. Pavyzdžiui, nenorėjome blokuoti 443 prievado; siekėme užblokuoti bet kokią išeinančiąją prieigą konkrečiam apribotam procesų medžiui.

Norint pritaikyti užkardos taisyklę konkrečiai mūsų bandomojoje aplinkoje veikiančioms komandoms, jas reikėjo vykdyti kaip atskirą pagrindinę tapatybę (angl. „principal“), o ne kaip „tikrąjį“ naudotoją. Dėl šio požiūrio teko sukti nauju keliu ir sušvelninti teisių nepadidinimo apribojimą.

Kitai bandomosios aplinkos iteracijai, kurią naudojame šiuo metu, vykdant sąranką reikia padidintų administratoriaus teisių. Todėl ją vadinu „bandomąja aplinka su padidintomis teisėmis“. Ties ta riba, kur „Codex“ sistemoje paleidžia komandą, bandomoji aplinka su padidintomis teisėmis atrodo taip pat kaip ir ankstesnė. Ji vis dar vykdo antrinius procesus naudodama apribotą žetoną – lygiai taip pat „write_restricted“ žetoną su tuo pačiu apribotų SID sąrašu „[Everyone, Logon, Synthetic]“ – tačiau šio žetono pagrindinė tapatybė (angl. „principal“) nebėra tikrasis „Windows“ naudotojas, o vienas iš dviejų vietinių naudotojų, kuriuos sukuria pati „Codex“:

• „CodexSandboxOffline“ (kuriam taikomos užkardos taisyklės);
• „CodexSandboxOnline“ (kuriam netaikomos užkardos taisyklės).

Ši iš pažiūros menka detalė iš tikrųjų turi didelę reikšmę bandomajai aplinkai, tam, kas gali ja naudotis, bei jos sąrankos ir vykdymo aplinkos sudėtingumui.

Vizualiai ji panaši į prototipą be padidintų teisių, tik joje papildomai įdiegtos užkardos taisyklės ir specialiai priskirtas „Windows“ naudotojas, kuris faktiškai vykdo komandas. (Vis dėlto šių naujų koncepcijų integravimas reiškia, kad reikia atlikti daugiau sąrankos darbų, kol bandomoji aplinka galės pradėti veikti ir apsaugoti komandas.)

Bandomosios aplinkos be padidintų teisių architektūra išsiskyrė paprastu ir gana trumpu sąrankos etapu:

• jei reikia, sukurti sintetinį SID;
• pritaikyti ACL, skirtus sintetiniam „sandbox-write“ SID.

Tačiau bandomojoje aplinkoje su padidintomis teisėmis reikia atlikti kur kas daugiau:

• sukurti sintetinį SID, jei jis dar nesukurtas;
• sukurti bandomosios aplinkos prisijungusius ir neprisijungusius (angl. „online and offline“) naudotojus, jei jie dar nesukurti;
• išsaugoti naujai sukurtų naudotojų kredencialus vietoje ir užšifruoti juos naudojant „Windows“ duomenų apsaugos API (angl. „Data Protection API“, DPAPI) tokioje vietoje, kurios bandomosios aplinkos naudotojai faktiškai negalėtų nuskaityti;
• sukurti užkardos taisykles, blokuojančias bet kokią naudotojo „CodexSandboxOffline“ išeinančiąją prieigą prie tinklo, arba, jei taisyklės jau egzistuoja, patikrinti, ar jos teisingos.

Sąrankos etape iškyla ir papildomas sunkumas. Tikimasi, kad „Codex“ bandomoji aplinka turės tokią pačią skaitymo prieigą kaip ir tikrasis „Windows“ naudotojas. Tai pavyko pasiekti bandomojoje aplinkoje be padidintų teisių, kurioje apriboto žetono pagrindinis SID atitiko „Windows“ naudotoją. Tačiau to nepavyksta gauti automatiškai, kai pagrindine tapatybe tampa naujas „CodexSandbox“ naudotojas. Daugelis atitinkamų „Windows“ katalogų suteikia skaitymo ar vykdymo teises autentifikuotiems naudotojams (angl. „Authenticated Users“). Vienas ryškiausių to pavyzdžių – naudotojo profilio katalogas. Pagal numatytąsias nuostatas „Windows“ naudotojai negali nuskaityti kitų „Windows“ naudotojų profilių katalogų, todėl daugelyje scenarijų net paprastos failų skaitymo operacijos būtų nesėkmingos.

Siekdami tai išspręsti, į bandomosios aplinkos sąrankos procesą įtraukėme dar vieną etapą – jis suteikia skaitymo ACL bandomosios aplinkos naudotojams ten, kur tokių ACL gali dar nebūti. Pavyzdžiui, kai kuriems dažnai naudojamiems „Windows“ katalogams:

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

Kadangi šis katalogų sąrašas tėra bandymas užtikrinti kuo geriausią rezultatą (angl. „best-effort“), o ACL diegimas kiekviename jų gali būti imlus resursams, šią logiką vykdome asinchroniškai, todėl naudotojus blokuojantis bandomosios aplinkos sąrankos etapas neturi laukti, kol šis procesas bus baigtas.

Sąrankos logiką izoliavome atskirame vykdomajame faile iš dalies tam, kad Naudotojo paskyros valdymo (angl. „User Account Control“, UAC) ribą kirstume tik tada, kai tai būtina. Tačiau gilesnė priežastis buvo susijusi su architektūra: bandomosios aplinkos sąrankos paskirtis iš esmės skiriasi nuo „codex.exe“ paskirties. Sąrankos logikos perkėlimas į atskirą vykdomąjį failą leido „codex.exe“ išlikti įprasta, nepadidintų teisių infrastruktūra; apsaugojo kitose platformose veikiantį „codex.exe“ nuo išsipūtimo dėl vien tik „Windows“ sistemoje naudojamų sąrankos mechanizmų; atskyrė ilgiau trunkančius sąrankos darbus nuo pagrindinio proceso gyvavimo ciklo ir sukūrė vieną centralizuotą vietą, kurioje galime valdyti skirtingus bandomajai aplinkai reikalingus sąrankos kelius.

Dėl „Windows“ naudotojų ir žetonų prisijungimo ribų veikimo principų nebegalėjome toliau kurti apriboto žetono ir paleisti su juo proceso taip, kaip tai darėme bandomojoje aplinkoje be padidintų teisių. Norėdami faktiškai paleisti komandas kaip kitas „Windows“ naudotojas, iš pradžių sumanėme tokią eigą:

• „codex.exe“ veikia kaip tikrasis „Windows“ naudotojas. Tuomet „Codex“ nuosekliai atlieka šiuos veiksmus:
  • iškviečia „LogonUserW(...)“ bandomosios aplinkos naudotojui;
  • tam bandomosios aplinkos naudotojo žetonui iškviečia „CreateRestrictedToken(...)“;
  • naudodama tą apribotą bandomosios aplinkos naudotojo žetoną, iškviečia „CreateProcessAsUserW(...)“, kad paleistų galutinį antrinį procesą.

Praktiškai ši pageidaujama eiga neveikė, nes ties „CreateProcessAsUserW(...)“ susidurta su teisių barjeru. Tai reiškia, kad „codex.exe“ galėjo sukurti apribotą žetoną bandomosios aplinkos naudotojui, bet negalėjo patikimai paleisti antrinio proceso su tuo žetonu iš tikrojo naudotojo ribos pusės. Mums reikėjo proceso, kuris jau veiktų kaip bandomosios aplinkos naudotojas – tai leistų ribojimo etapą ir galutinį paleidimą atlikti bandomosios aplinkos naudotojo ribos pusėje, o ne tikrojo naudotojo pusėje.

Dėl šio reikalavimo atsirado „codex-command-runner.exe“ – naujas vykdomasis failas, kurio vienintelis darbas – sukurti apribotą žetoną ir paleisti prašomą komandą. Užuot reikalavę, kad „codex.exe“ atliktų visą eigą pati (tikrasis naudotojas → bandomosios aplinkos naudotojas → apribotas žetonas → antrinis procesas), padalijome ją į dvi dalis:

1 dalis

• „codex.exe“ iškviečia „CreateProcessWithLogonW(...)“, kad paleistų „codex-command-runner.exe“ kaip bandomosios aplinkos naudotoją (kol kas nenaudojant apriboto žetono).

2 dalis

• Vykdyklės viduje „OpenProcessToken(GetCurrentProcess(), ...)“ atidaro pačios vykdyklės žetoną, jau priklausantį bandomosios aplinkos naudotojui.
• Vykdyklė iškviečia „GetTokenInformation(...)“, kad ištrauktų bandomosios aplinkos prisijungimo SID, o tada atlieka „CreateRestrictedToken(...)“, kad suformuotų galutinį apribotą žetoną.
• Vykdyklė su apribotu žetonu iškviečia „CreateProcessAsUserW(...)“, kad paleistų tikrąjį antrinį procesą.

Albertas Einšteinas (Albert Einstein) yra pasakęs: „Viskas turi būti daroma kuo paprasčiau, bet ne dar paprasčiau.“ Vadovaudamiesi šia nuostata, sukūrėme architektūrą, tinkamai išsprendusią kiekvieną problemą. Galutinę architektūrą sudaro keturi anksčiau aptarti lygmenys:

• pati „codex.exe“ programinė įranga;
• „codex-windows-sandbox-setup.exe“ padidintų teisių sąrankos darbams tvarkyti;
• „codex-command-runner.exe“ komandoms apriboto žetono aplinkoje vykdyti;
• antrinis procesas.

Kai pradėjau šį projektą, neturėjau aiškaus įsivaizdavimo, kur jis nuves.Mano tikslas buvo pradėti nuo bandomosios aplinkos diegimo tarp „Codex“ ir operacinės sistemos.Tai labai artima tam, kaip „Codex“ bandomoji aplinka įgyvendinta „macOS“ ir „Linux“ sistemose.

Vis daugiau sužinant apie konkrečius „Windows“ teikiamus įrankius ir priėmus daugybę sprendimų bandant išlaikyti balansą tarp saugumo ir patogumo, sistema išaugo iki dabartinės formos – keli vykdomieji failai, pasirinktiniai naudotojai, užkardos taisyklės, sąrankos etapas su padidintomis teisėmis, asinchroniniai procesai ir kt.

Ši sistema nėra itin paprasta, tačiau kiekvienas sudėtingas elementas įdiegtas iš būtinybės siekiant sukurti bandomąją aplinką, kuri ne tik užtikrintų saugumą, bet ir kiek įmanoma netrukdytų naudotojui.

Siekdami užtikrinti gerą patirtį su „Codex“ „Windows“ aplinkoje dirbantiems naudotojams, kėlėme tikslą sukurti saugų ir kompromisų naudingumo atžvilgiu nereikalaujantį sprendimą – juk pagrindinė „Codex“ paskirtis ir yra ta, kad agentai galėtų atlikti darbą be nuolatinio jūsų įsikišimo.

Viena didžiausių šio projekto pamokų buvo ta, kad „Windows“ nesuteikė vieno bazinio elemento, aiškiai atitinkančio „saugaus autonominio programavimo agento“ sąvoką.Norint sukurti vientisą sprendimą, teko sujungti kelis įrankius ir koncepcijas. Kai kurios ankstyvosios idėjos atsidūrė aklavietėje. Galutinė architektūra tapo ankstesnių prototipų, kurių kiekvienas išsprendė tam tikrą problemos dalį, hibridu.

Dar viena pamoka – programavimo agento saugumas yra visai kitoks iššūkis nei klasikinė programų apsauga. „Codex“ privalo veikti atsižvelgiant į realias kūrėjų darbo eigas. Inžinerinis darbas rėmėsi pusiausvyros tarp suderinamumo su agentinėmis užduotimis ir realaus ribojimų taikymo paieškomis. Ši įtampa ir nulėmė galutinės architektūros kompromisus.

Smalsu pamatyti, kaip veikia „Codex“ bandomoji aplinka? Išbandykite⁠.