Turvallisen ja tehokkaan hiekkalaatikon rakentaminen Codexia varten Windowsissa

Kun liityin Codexin suunnittelutiimiin syyskuussa 2025, Windowsin Codexissa ei ollut hiekkalaatikkototeutusta, mikä tarkoitti, että Windows-käyttäjät joutuivat valitsemaan OpenAI:n koodausagentteja käyttäessään kahden heikon vaihtoehdon välillä:

1. Hyväksyä lähes jokainen komento (jopa lukuoperaatiot), jonka koodausagentti halusi suorittaa, mikä on tehotonta ja rasittavaa. Codexin koko pointti on, että kaikkea puuduttavaa työtä ei tarvitse tehdä itse.
2. Ottaa käyttöön Full Access -tilan: antaa Codexin suorittaa kaikki komennot ilman hyväksyntää tai rajoituksia, mikä vähentää kitkaa valvonnan kustannuksella.

Codex⁠-koodausagenttimme toimii kehittäjien kannettavilla tietokoneilla – joko CLI:n, IDE-laajennuksen tai työpöytäsovelluksen kautta. Se hallinnoi keskustelua näppäimistön ääressä olevan ihmisen ja pilvessä päättelyä varten ajettavan mallin välillä.

Codex toimii oletusarvoisesti oikean käyttäjän oikeuksilla, mikä tarkoittaa, että se voi tehdä kaiken, mitä käyttäjäkin voi tehdä. Tämä on tehokasta ja mahdollisesti vaarallista. Koodausmalli voi pyytää ajuria suorittamaan komentoja paikallisesti, testien ajamisesta tiedoston lukemiseen tai muokkaamiseen ja Git-haaran luomiseen asti, joten Codexin oletustila pyrkii löytämään oikean tasapainon tehokkuuden ja turvallisuuden välillä. Tässä oletustilassa Codex voi lukea tiedostoja lähes mistä tahansa ja kirjoittaa tiedostoja työtilassasi (eli hakemistossa, jossa suoritat Codexia), ilman internetyhteyttä, ellet erikseen halua sitä. Jotta tiedostojen kirjoittamista ja verkon käyttöä voidaan automaattisesti rajoittaa turvallisiin rajoihin, Codex tarvitsee hiekkalaatikkoympäristön, joka todella valvoo näitä rajoituksia.

Hiekkalaatikko on rajoitettu suoritusympäristö. Kun kehittäjä käyttää Codexia, hänen tietokoneensa käyttöjärjestelmä käynnistää komennon pienennetyillä oikeuksilla, ja nämä rajoitukset periytyvät alaspäin prosessipuussa. Jokainen Codex-komento ajetaan alusta alkaen hiekkalaatikossa, ja jokainen jälkeläisprosessi pysyy saman eristysrajan sisällä.

Codex tarvitsee tietokoneen käyttöjärjestelmän valvomia eristysominaisuuksia toteuttaakseen tehokkaan hiekkalaatikon. Jotkin käyttöjärjestelmät tarjoavat apuohjelmia, jotka tekevät tämän hyvin (esim. Seatbelt MacOs:ssa, seccomp tai bubblewrap Linuxissa); Windows ei kuitenkaan tällä hetkellä tarjoa tällaista valmiutta valmiina.

Jotta Codex olisi Windowsissa yhtä turvallinen ja miellyttävä käyttää kuin se jo on kaikkialla muualla, meidän piti toteuttaa oma hiekkalaatikkomme.

Windows tarjoaa joitakin eristykseen tarkoitettuja työkaluja ja perusominaisuuksia. Vaikka mikään niistä ei täysin vastannut vaatimuksiamme, tarkastelimme useita mahdollisia ratkaisuja – erityisesti AppContaineria, Windows Sandboxia ja Mandatory Integrity Control -merkintöjä.

AppContainer

• Mikä: AppContainer on Windowsin natiivi hiekkalaatikko, kyvykkyyksiin perustuva eristysmalli sovelluksille, jotka tietävät etukäteen tarkalleen, mitä niiden täytyy käyttää.
• Miksi: houkutteleva, koska se tarjoaa aidon käyttöjärjestelmärajan ”parhaansa mukaan” -rajoituksen sijaan.
• Miksi ei: Codex ei ole yksi tarkasti rajattu sovellus. Se ohjaa avoimia kehittäjätyönkulkuja: komentotulkkeja, Gitiä, Pythonia, paketinhallintaohjelmia, koontityökaluja ja mitä tahansa muita binäärejä, joita agentti päättää tarvitsevansa. Käytännössä tämä tarkoitti, että AppContainer ei ollut sopivanlainen ratkaisu tähän ongelmaan. Se tarjosi vahvan eristyksen, mutta paljon suppeammalle työkuormien joukolle kuin ”anna agentin toimia kehittäjän tavoin”.

Windows Sandbox

• Mikä: Windows Sandbox on Microsoftin kertakäyttöinen kevyt virtuaalikone. Saat uuden Windows-työpöydän vahvalla eristysrajalla, ja kaikki, mitä sen sisällä teet, katoaa istunnon päättyessä.
• Miksi: Kiinnostava ilmeisistä syistä – paljon yhteensopivampi mielivaltaisen ohjelmiston kanssa kuin AppContainer, ja tietoturvan näkökulmasta paljon vahvempi eristys.
• Miksi ei: Codexin täytyy toimia suoraan käyttäjän todellisessa checkoutissa, työkaluissa ja ympäristössä, ei erillisellä väliaikaisella työpöydällä, joka vaatisi asetuksia ja isäntä-/vierasyhteyksiä. Siinä oli myös perustavanlaatuinen tuoteongelma: Windows Sandbox ei ole edes saatavilla Windows Home -tuoteversioissa.

Mandatory Integrity Control (MIC) -eheysmerkinnät

• Mitä: Windowsissa on käsite nimeltä ”eheystasot”, kuten matala, keskitaso ja korkea, jotka määrittävät, kuinka paljon järjestelmä luottaa objekteihin ja prosesseihin. Perussääntö on, että alemman eheystason prosessi ei voi kirjoittaa objektiin, jolla on korkeampi eheystaso, vaikka normaali ACL sen muuten sallisi. Esimerkiksi alhaisen eheystason prosessia pidetään vähemmän luotettuna, joten Windows estää sitä kirjoittamasta tavallisiin keskitason eheystason objekteihin, ellei näitä objekteja ole nimenomaisesti merkitty uudelleen sen sallimiseksi.
• Miksi: MIC näytti paperilla elegantilta – suorita Codex matalalla eheystasolla, merkitse kirjoitettavat juuret matalan eheystason kohteiksi ja anna Windowsin estää kirjoitukset kaikkialle muualle. Se olisi tarjonnut meille reitin ilman järjestelmänvalvojan oikeuksia, ja sen taustalla olisi ollut oikea käyttöjärjestelmämekanismi.
• Miksi ei: ACL:ien tavoin eheystunnisteet muokkaavat todellista isäntäkoneen tiedostojärjestelmää, ja tässä tapauksessa semanttinen muutos on erityisen laaja. Työtilan merkitseminen matalan eheystason työtilaksi ei tarkoita vain sitä, että ”Codex voi kirjoittaa tänne.” Se tarkoittaa, että matalan eheystason prosessit voivat yleisesti ottaen kirjoittaa sinne. Todellisessa kehittäjän koneessa tämä muuttaa käyttäjän varsinaisen työkopion isäntäjärjestelmän alhaisen eheystason nieluksi, mikä on huomattavasti riskialttiimpaa kuin huolellisesti kohdennettujen ACL-oikeuksien myöntäminen yhdelle hiekkalaatikkoratkaisulle. Vaikka keskitason eheystasolla toimivat kehittäjätyökalut toimisivat edelleen, työtilan taustalla oleva luottamusmalli on muuttunut tavalla, jota on vaikea rajata ja vielä vaikeampi perustella.

Koska kaikki vaihtoehdot osoittautuivat lähtökohtaisesti toimimattomiksi, aloimme suunnitella omaa ratkaisua hyvän Codex-kokemuksen tuomiseksi Windows-käyttäjille.

Ensimmäinen toimiva prototyyppimme hyödynsi Windowsin käsitteiden ja työkalujen yhdistelmää tarvitsemamme eristyksen toteuttamiseen. Alusta alkaen yhtenä tavoitteena oli saada tämä toimimaan ilman, että se edellyttää oikeuksien korotusta, mikä tarkoittaa, ettei Codexin tarvitsisi pyytää käyttäjältä järjestelmänvalvojan oikeuksia pelkästään hiekkalaatikon määrittämistä tai suorittamista varten. Se tarkoitti sen selvittämistä, miten kahdelle asialle voitaisiin asettaa kohtuulliset rajat: tiedostoihin kirjoittamiselle ja verkkoyhteyksille.

Jos emme olisi rajoittaneet tiedostokirjoituksia lainkaan, meillä olisi ollut turvallisuusongelma. Jos olisimme rajoittaneet niitä liikaa, hiekkalaatikko olisi heikentänyt käyttäjien tuottavuutta ja pyytänyt jatkuvasti hyväksyntää. Ratkaistaksemme tämän ongelman hyödynsimme kahta tärkeää Windowsin peruselementtiä: SID-tunnisteita ja kirjoitusoikeuksia rajoittavia tunnuksia.

SID eli suojaustunnus on identiteetti, jonka Windows yhdistää käyttöoikeuksiin. Jokaisella käyttäjällä on SID-tunnus, ryhmillä on SID-tunnukset, ja jopa yksittäinen kirjautumisistunto saa oman SID-tunnuksensa. Esimerkiksi nykyisellä kirjautuneella istunnolla voi olla seuraavanlainen SID: S-1-5-5-X-Y. Paikalliselle järjestelmänvalvojien ryhmälle määritetty SID voi olla S-1-5-32-544.

Windowsissa voi myös luoda synteettisiä SID-tunnisteita, jotka eivät vastaa oikeaa käyttäjää mutta voivat silti esiintyä ACL-luetteloissa (access control list), jotka määrittävät, kuka voi lukea/kirjoittaa/suorittaa tiettyjä tiedostoja tai hakemistoja. Tämä tekee SID:eistä hyödyllisen primitiivin hiekkalaatikollemme: voimme luoda SID-tunnisteita yksinomaan Codexin hiekkalaatikon käyttöön häiritsemättä mitään muuta koneessa.

Prosessitokenit ovat Windowsin suojausobjekteja, jotka määrittävät käynnissä olevan prosessin identiteetin ja oikeudet. Ne määrittävät, mitä toimintoja prosessi voi suorittaa. Kirjoitusrajoitettu token on erityinen prosessitokenin tyyppi, jonka vuoksi Windows suorittaa ylimääräisen käyttöoikeustarkistuksen kirjoitustoiminnoissa.

Jotta kirjoitus onnistuisi, kahden tarkistuksen on läpäistävä:

1. Tavallisen käyttäjäidentiteetin (tokenin ”omistajan”) on oltava oikeutettu siihen
2. Vähintään yhdelle tokenin restricted SID -luettelon SID-tunnisteelle on myös oltava myönnetty pääsy

Käytännössä nämä tarkistukset antoivat meille mahdollisuuden käyttää ACL-luetteloita määrittämään tarkasti, missä hiekkalaatikko sai muokata tiedostojärjestelmää, mikä tarjosi tarvitsemamme tarkkuuden kirjoitustoimintojen ympärille.

SID-tunnisteiden ja kirjoitusrajoitettujen tokenien avulla korottamaton sandboximme toimi näin:

1. Hiekkalaatikon asennus loi synteettisen SID-tunnisteen nimeltä sandbox-write.
2. sandbox-write -SID:lle myönnettiin kirjoitus-, suoritus- ja poisto-oikeudet kohteeseen
   1. Nykyinen työhakemisto
   2. Mahdolliset muut writable_roots -kohteet, jotka on määritetty config.toml-tiedostossa.
3. Sandboxin asennus esti nimenomaisesti samalta SID-tunnisteelta kirjoitusoikeuden ”kirjoitettavan alueen sisällä vain luku” -sijainteihin, kuten:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex käynnisti komennot kirjoitusrajoitetulla tokenilla, jonka rajoitettu SID-luettelo sisältää Kaikki-ryhmän, nykyisen kirjautuneen istunnon SID:n ja synteettisen sandbox-write-SID:n.

Tämä työnkulku ratkaisi tehokkaasti tiedostokirjoitusten rajoittamisen ja vaikutti lupaavalta. Seuraavaksi tarvitsimme ratkaisun hiekkalaatikon verkkokäytön rajoittamiseen.

Verkkokäytön rajoittaminen on tärkeä osa hiekkalaatikkoa; ilman sitä haitallinen koodi voisi vuotaa tietoja koneelta internetiin. Koska halusimme välttää korotusvaatimuksen, meillä oli rajalliset mahdollisuudet estää verkkoliikenne vahvasti. Työkalut, joita halusimme käyttää, kuten Windowsin palomuuri, eivät yleensä olleet asennettavissa ilman järjestelmänvalvojan oikeuksia.

Koska Windowsin palomuuri ei ollut vaihtoehto, rajoitimme sitä, mitä pystyimme hallitsemaan. Yritimme saada aliympäristön epäonnistumaan oletusarvoisesti niiden verkkotyökalujen osalta, joita kehittäjät oikeasti käyttävät, niin että Git-komennot, pakettien asentajat jne. epäonnistuisivat sandboxissa ja käyttäjän olisi hyväksyttävä kaikki internetiin suuntautuvat toiminnot. Ajatuksena oli myrkyttää ilmeiset pakoreitit: ohjata välityspalvelintietoiset pyynnöt kuolleeseen päätepisteeseen, saada Gitin HTTP(S)-siirto tekemään sama ja saada Git over SSH epäonnistumaan heti. Lisäksi lisäsimme pienen denybin-hakemiston PATH-muuttujan alkuun ja järjestimme PATHEXT-muuttujan uudelleen, jotta SSH- ja SCP-tynkäskriptit ratkeaisivat ennen oikeita binaareja.

Esimerkiksi tässä on joitakin käyttämiämme ympäristömuuttujaohituksia verkkokäytön rajoittamiseen:

• 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

Se keräsi paljon tavallista työkalujen tuottamaa liikennettä, mutta se oli silti vain suositusta. Prosessi saattoi sivuuttaa ympäristön, ohittaa PATH-muuttujan tai avata yhteyksiä suoraan – liian riskialtista.

Kuten kaikissa mielenkiintoisissa ohjelmistototeutuksissa, ensimmäisessä prototyypissä oli hyvät ja huonot puolensa. Vaikka se hoiti tehtävän vain muutamilla Windowsin vakiokyvykkyyksillä, mahdollisti hyvin eksplisiittiset ja tarkkarajaiset tiedostojärjestelmäkirjoitukset ja toimi ilman korotusta – vähentäen tarvetta käyttäjien hyväksyä liiallisia korotuskehotteita tai olla järjestelmänvalvojia omalla paikallisella koneellaan – siinä oli joitakin todellisia haittapuolia, joista osa esti sitä päätymästä lopulliseksi suunnitelmaksemme:

• Asetusten nopeus: työtilan ACL-oikeuksien soveltaminen voi olla kallista työtilahakemiston topologiasta riippuen.
• Jalanjälki: sovelsimme oikeita ACL-oikeuksia kehittäjän järjestelmään, vaikka jalanjälki ei ole erityisen tunkeileva, koska kaikki sovelletut ACL:t koskevat mukautetusti luotua synteettistä SID-tunnistetta, jota käyttää vain hiekkalaatikko.
• Vaikeasti muutettava semantiikka: tiedostopohjaisten rajoitusten riippuvuus käyttöoikeusluetteloista (ACL) tarkoittaa, että hiekkalaatikon semantiikan muuttaminen on kallista ja monimutkaista. Sen sijaan macOS:ssä voimme muuttaa dynaamisesti tapaa, jolla luomme Seatbeltin määritykseen käytettävän .sbpl-tiedoston, Windowsin hiekkalaatikko voi edellyttää hidasta ja kuormittavaa toimenpidettä operaation ACL-oikeuksien säätämiseksi.
• Verkon suojaus on heikko. Kuten aiemmin mainittiin, se oli ”ohjeellinen”, jotkin ohjelmat, jotka toteuttivat oman verkkopinonsa, kiertäisivät sen varmasti, eikä sitä ollut suunniteltu kestämään vihamielistä koodia.

Kolme ensimmäistä ongelmaa ovat luontaisia mukautetulle hiekkalaatikkototeutukselle, joka on riittävän joustava agenttisiin työnkulkuihin. Verkon estämisen tilanne oli kuitenkin erilainen.

Sen lisäksi, että haitallinen agentti voisi helposti kiertää ympäristöön perustuvan verkoneston, myös moni hyväntahtoinen koodi/binaari kiertäisi sen yksinkertaisesti, jos se ei kunnioittaisi ympäristön välityspalvelinmuuttujia tai toteuttaisi oman socket-pohjaisen verkkokoodinsa. Katsoimme tämän riittäväksi syyksi investoida parempaan hiekkalaatikkotilaan.

Saadaksemme paremman verkoneston halusimme käyttää Windowsin palomuuria, jonka avulla voimme estää käyttäjien tai ohjelmien lähtevän verkkoliikenteen. Valitettavasti emme voineet tehokkaasti luoda toimivaa palomuurisääntöä, joka olisi koskenut vain Codex-ajurin käynnistämiä komentoja, muutamasta syystä:

• Windows ei salli palomuurisäännön täsmäyttämistä rajoitetun tokenin muuhun kuin ensisijaiseen identiteettiin. Tämä tarkoitti, ettemme voineet soveltaa palomuurisääntöä muotoon ”mikä tahansa token, jonka rajoitetun SID:n luettelossa on synteettinen SID:mme”.
• Vaikka voisimme luoda palomuurisäännön, joka vastaa tiettyä binaaria, se sallisi meidän rajoittaa vain itse codex.exe:n verkkoa. Se ei koskisi prosesseja, jotka agentti käynnistää käyttäjän puolesta, kuten Git- tai Python-prosesseja.
• Myös muut palomuurin täsmäytysulottuvuudet olivat väärän muotoisia. Käyttäjäkohtaiset säännöt vastasivat edelleen todellista Windows-käyttäjää korottamattomassa mallissa, eivätkä vain rajoitettua aliprosessia. Ohjelmapolkuihin perustuvat säännöt olivat liian karkeita: ne saattoivat estää ohjelmat codex.exe tai python.exe yleisesti, mutta eivät tätä yksittäistä hiekkalaatikoitua python.exe-käynnistystä. Portti- tai osoitepohjaiset säännöt olivat myös täysin väärä käytäntö. Emme esimerkiksi halunneet estää porttia 443; halusimme estää tältä tietyltä rajoitetulta prosessipuulta mielivaltaiset lähtevät yhteydet.

Jotta palomuurisääntö voitiin kohdistaa nimenomaan hiekkalaatikossa testattuihin komentoihimme, meidän piti ajaa ne erillisenä ”oikeana” käyttäjänä. Tämä lähestymistapa vei meidät uudelle polulle, jossa löysäsimme ”ei korotusta” -rajoitettamme.

Hiekkalaatikon seuraava iteraatio, joka on nykyinen toteutuksemme, edellyttää korotettuja järjestelmänvalvojan oikeuksia käyttöönoton yhteydessä. Siksi kutsun sitä nimellä ”korotettu hiekkalaatikko”. Rajapinnassa, jossa Codex käynnistää komennon järjestelmässä, korotetuilla oikeuksilla suoritettava hiekkalaatikkoympäristö näyttää samalta kuin ilman korotettuja oikeuksia suoritettava. Se suorittaa edelleen aliprosesseja rajoitetulla tokenilla – vastaavasti write_restricted -tokenilla, jolla on sama rajoitettujen SID-tunnisteiden luettelo [Everyone, Logon, Synthetic] – mutta tämän tokenin suojausobjekti ei enää ole varsinainen Windows-käyttäjä vaan toinen kahdesta paikallisesta käyttäjästä, jotka Codex on itse luonut:

• CodexSandboxOffline (se, johon palomuurisäännöt kohdistuvat)
• CodexSandboxOnline (se, johon palomuurisäännöt eivät kohdistu)

Tällä näennäisen pienellä yksityiskohdalla on itse asiassa suuria vaikutuksia hiekkalaatikkoon, siihen kuka voi käyttää sitä sekä sen asennuksen ja ajonaikaisen suorituksen monimutkaisuuteen.

Se näyttää visuaalisesti samankaltaiselta kuin korottamaton prototyyppi, mutta mukaan on tullut palomuurisäännöt ja oma Windows-käyttäjä, joka todella suorittaa komennot. (Näiden uusien käsitteiden lisääminen kuitenkin tarkoittaa, että ennen kuin hiekkalaatikko voi alkaa suorittaa ja suojata komentoja, on tehtävä enemmän asennustyötä.)

Korottamattoman hiekkalaatikon suunnittelussa asennusvaihe oli yksinkertainen, mutta suhteellisen pieni:

• Luo synteettinen SID tarvittaessa
• Sovella ACL-oikeuksia sandbox-write-synteettiselle SID:lle

Korotetulla hiekkalaatikolla on kuitenkin enemmän tehtävää.

• Luo synteettinen SID, jos sitä ei ole vielä luotu
• Luo online- ja offline-sandbox-käyttäjät, jos niitä ei ole vielä luotu
• Tallenna uusien käyttäjien tunnistetiedot paikallisesti ja salaa ne Windows Data Protection API:lla (DPAPI) paikkaan, jota hiekkalaatikon käyttäjät eivät oikeasti voi lukea
• Luo palomuurisäännöt, jotka estävät kaiken lähtevän verkkoliikenteen CodexSandboxOffline -käyttäjältä, tai jos ne ovat jo olemassa, varmista että ne ovat oikein

Määritysvaiheeseen liittyy vielä yksi lisämutka. Codex-eristysympäristöllä odotetaan olevan samat lukuoikeudet kuin varsinaisella Windows-käyttäjällä. Korottamattomassa hiekkalaatikossa, jossa rajoitetun token ensisijainen SID oli Windows-käyttäjä, tämä saavutettiin. Se ei kuitenkaan tule ilmaiseksi, kun käyttöoikeussubjektista tulee uusi CodexSandbox -käyttäjä. Monet asiaankuuluvat Windows-hakemistot myöntävät käyttäjäryhmälle ”Todennetut käyttäjät” luku- ja suoritusoikeudet. Yksi huomionarvoinen esimerkki on käyttäjän profiilihakemisto. Oletusarvoisesti Windows-käyttäjät eivät voi lukea muiden Windows-käyttäjien profiilihakemistoja, joten monissa tilanteissa jopa yksinkertaiset tiedostojen lukutoiminnot epäonnistuisivat.

Tämän ratkaisemiseksi lisäsimme hiekkalaatikon asennusprosessiin vielä yhden kerroksen – sellaisen, joka myöntää hiekkalaatikon käyttäjille luku -ACL-oikeuksia siellä, missä niitä ei ehkä vielä ole. Esimerkiksi joihinkin yleisesti käytettyihin Windows-hakemistoihin:

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

Koska tämä hakemistoluettelo on koottu parhaan mukaan ja ACL-oikeuksien asentaminen kuhunkin niistä voi olla melko kallista, suoritamme tämän logiikan asynkronisesti, jotta käyttäjiä blokkaavan hiekkalaatikkoasennusvaiheen ei tarvitse odottaa niiden valmistumista.

Kapseloimme asennuslogiikan omaan binääritiedostoonsa osittain siksi, että UAC-raja ylitetään vain tarvittaessa. Mutta syvempi syy liittyi arkkitehtuuriin: sandbox-ympäristön määrittämisellä on perustavanlaatuisesti erilainen tehtävä kuin ohjelmalla codex.exe. Asennuslogiikan pitäminen omassa binäärissään antoi codex.exe:n pysyä tavallisena, korottamattomana ajurina; esti Windows-kohtaisen asennuskoneiston paisuttamasta codex.exe:ä muilla alustoilla; irrotti pidempään kestävän asennustyön pääprosessin elinkaaresta; ja antoi meille yhden paikan käsitellä hiekkalaatikon tarvitsemia erilaisia asennuspolkuja.

Windowsin käyttäjä- ja token-kirjautumisrajojen toiminnan vuoksi emme voineet enää luoda rajoitettua tokenia ja käynnistää sen alla prosessia samalla tavalla kuin korottamattomassa hiekkalaatikossa. Jotta komennot todella voitiin käynnistää eri Windows-käyttäjänä, ensimmäinen ajatuksemme oli seuraava työnkulku:

• codex.exe suoritetaan todellisena Windows-käyttäjänä. Seuraavaksi Codex etenee järjestyksessä:
  • Kutsuu LogonUserW(...) -funktiota hiekkalaatikkokäyttäjälle.
  • Kutsuu CreateRestrictedToken(...) -funktiota kyseiselle hiekkalaatikkokäyttäjän tokenille.
  • Käyttäen tätä rajoitettua hiekkalaatikkokäyttäjän tokenia kutsuu CreateProcessAsUserW(...) -funktiota lopullisen aliprosessin käynnistämiseksi.

Käytännössä haluttu kulku ei toiminut, koska CreateProcessAsUserW(...)-kohdassa tuli vastaan käyttöoikeuseste. Tämä tarkoittaa, että codex.exe pystyi luomaan rajoitetun tokenin sandbox-käyttäjälle, mutta se ei pystynyt luotettavasti käynnistämään aliprosessia kyseisellä tokenilla rajan todellisen käyttäjän puolelta. Tarvitsimme prosessin, joka jo toimii hiekkalaatikon käyttäjänä – tämä mahdollistaisi rajoitusvaiheen ja lopullisen käynnistyksen tapahtumisen hiekkalaatikon käyttäjän puolella rajaa, ei oikean käyttäjän puolella.

Tämä vaatimus johti codex-command-runner.exe-nimiseen uuteen suoritettavaan tiedostoon, jonka ainoa tehtävä on luoda rajoitettu token ja käynnistää pyydetty komento. Sen sijaan, että pyytäisimme codex.exe:ä tekemään koko työnkulun itse (oikea käyttäjä → hiekkalaatikon käyttäjä → rajoitettu token → lapsiprosessi), jaoimme työnkulun kahteen osaan:

Osa 1

• codex.exe kutsuu CreateProcessWithLogonW(...) -funktiota käynnistääkseen codex-command-runner.exe:n hiekkalaatikon käyttäjänä, vielä ilman rajoitettua token.

Osa 2

• Suorittajan sisällä OpenProcessToken(GetCurrentProcess(), ...) avaa suorittajan oman tokenin, joka kuuluu jo hiekkalaatikon käyttäjälle.
• Suorittaja kutsuu GetTokenInformation(...) -funktiota poimiakseen hiekkalaatikon logon-SID:n ja sitten CreateRestrictedToken(...) -funktiota rakentaakseen lopullisen rajoitetun tokenin.
• Yhä suorittajan sisällä se kutsuu CreateProcessAsUserW(...) -funktiota tällä rajoitetulla tokenilla käynnistääkseen varsinaisen lapsiprosessin.

Albert Einstein sanoi: ”Kaikki pitäisi tehdä niin yksinkertaiseksi kuin mahdollista, mutta ei yksinkertaisemmaksi.” Siinä hengessä suunnittelumme ratkaisi kunkin ongelman riittävän hyvin. Lopullisessa arkkitehtuurissa on neljä aiemmin käsittelemäämme kerrosta:

• codex.exe itse
• codex-windows-sandbox-setup.exe hoitamaan kaiken korotettuun asennukseen liittyvän työn
• codex-command-runner.exe rajoitettujen token-komentojen suorittamiseen
• Aliprosessi

Kun ryhdyin tähän projektiin, minulla ei ollut selkeää käsitystä siitä, mihin se lopulta johtaisi. Päätin aloittaa toteuttamalla hiekkalaatikkotoiminnon Codexin ja käyttöjärjestelmän välisessä rajapinnassa. Tämä lähestymistapa vastaa hyvin sitä, miten Codexin hiekkalaatikko on toteutettu macOS- ja Linux-käyttöjärjestelmissä.

Kun opin enemmän Windowsin tarjoamista erityisistä työkaluista ja tein kymmeniä päätöksiä tasapainottaen turvallisuutta ja helppokäyttöisyyttä, järjestelmä kasvoi nykyiseen muotoonsa – useita binaareja, mukautettuja käyttäjiä, palomuurisääntöjä, korotettu asennusvaihe, asynkronisia prosesseja ja muuta.

Se ei ole erityisen yksinkertainen järjestelmä, mutta jokainen monimutkaisuuden osa lisättiin tarpeesta, jotta voisimme rakentaa hiekkalaatikon, joka on sekä turvallinen että mahdollisimman vähän käyttäjän tiellä.

Työskennellessämme hyvän käyttökokemuksen toimittamiseksi Codexin Windows-käyttäjille tavoitteemme oli tehdä jotain turvallista, joka ei tingi hyödyllisyydestä – koko Codexin käytön pointti on, että agentit voivat tehdä työtä ilman jatkuvaa huomiotasi.

Yksi tämän projektin suurimmista opetuksista oli, ettei Windows tarjonnut meille yhtä primitiiviä, joka vastaisi siististi käsitettä ”turvallinen autonominen koodausagentti”. Koostimme useita työkaluja ja käsitteitä rakentaaksemme jotain yhtenäistä. Jotkin varhaiset ideat olivat umpikujia. Lopullinen suunnitelma oli hybridi aiemmista prototyypeistä, joista kukin ratkaisi osan ongelmasta.

Toinen opetus oli, että koodausagentin turvallisuus poikkeaa perinteisestä sovellusturvallisuudesta. Codexin on toimittava oikeissa kehittäjätyönkuluissa. Suunnittelutyössä oli kyse yhteensopivuuden tasapainottamisesta agenttisten työkuormien kanssa todellisen valvonnan rinnalla. Tämä jännite muokkasi lopullisen suunnitelman kompromisseja.

Haluatko nähdä Codexin hiekkalaatikon toiminnassa? Kokeile sitä⁠.