Jak jsme vytvořili bezpečný a efektivní sandbox pro Codex ve Windows

Když jsem se v září 2025 připojil k vývojářskému týmu Codex, Codex pro Windows neměl implementaci sandboxu, což znamenalo, že uživatelé Windows si při používání programovacích agentů OpenAI museli vybrat mezi dvěma špatnými možnostmi:

1. Schvalovat téměř každý příkaz (dokonce i čtení), který chtěl programovací agent spustit, což je neefektivní a otravné. Velkou výhodou používání nástroje Codex je, že nemusíte veškerou tu zdlouhavou práci dělat sami.
2. Zapnout režim úplného přístupu: nechat Codex spouštět všechny příkazy bez schválení nebo omezení, což zvyšuje plynulost za cenu menší kontroly.

Codex⁠, náš programovací agent, běží na noteboocích vývojářů — ať už přes rozhraní příkazového řádku, rozšíření do IDE, nebo desktopovou aplikaci. Řídí konverzaci mezi člověkem u klávesnice a modelem běžícím v cloudu, který zajišťuje inferenci.

Codex ve výchozím nastavení běží s oprávněními skutečného uživatele, což znamená, že může dělat vše, co může dělat uživatel. To je silné a potenciálně nebezpečné. Programovací model může harnessu říct, aby lokálně spouštěl příkazy – od spouštění testů přes čtení nebo úpravu souboru až po vytvoření větve Git – takže výchozí režim Codexu se snaží najít správnou rovnováhu mezi efektivitou a bezpečností. Tento výchozí režim umožňuje Codexu číst soubory téměř kdekoli a zapisovat soubory v rámci pracovního prostoru (tj. adresáře, kde je Codex spuštěn) bez přístupu k internetu, pokud výslovně neurčíte, že to chcete. Aby bylo možné toto automatické omezení zápisu do souborů a přístupu k síti vynucovat v bezpečných mezích, potřebuje Codex sandboxové prostředí, které tato omezení skutečně vynucuje.

Sandbox je omezené prostředí pro spouštění. Když vývojář používá Codex, operační systém jeho počítače spustí příkaz se sníženými oprávněními a tato omezení se propagují dolů stromem procesů. Každý příkaz Codexu je od začátku v sandboxu a každý následný proces zůstává uvnitř stejné hranice.

Codex potřebuje izolační funkce vynucované operačním systémem počítače, aby mohl implementovat efektivní sandbox. Některé operační systémy poskytují nástroje, které to dělají dobře (např. Seatbelt v MacOs, seccomp nebo bubblewrap v Linuxu), Windows však tuto schopnost ve výchozí instalaci aktuálně nenabízí.

Aby bylo používání Codexu ve Windows stejně bezpečné a příjemné jako všude jinde, museli jsme implementovat vlastní sandbox.

Windows nabízí některé nástroje a primitiva pro izolaci. I když žádný z nich plně nesplnil naše požadavky, zkoumali jsme řadu možných řešení – konkrétně AppContainer, Windows Sandbox a označování Mandatory Integrity Control.

AppContainer

• Co to je: AppContainer je nativní sandbox Windows, model izolace založený na funkcích, vytvořený pro aplikace, které předem přesně vědí, k čemu potřebují přístup.
• Proč: Je atraktivní, protože nabízí skutečná omezení operačního systému namísto omezení typu maximálního úsilí.
• Proč ne: Codex není jedna úzce vymezená aplikace. Řídí otevřené vývojářské pracovní postupy: shelly, Git, Python, správce balíčků, nástroje na sestavování a jakékoli další binární soubory, které se agent rozhodne potřebovat. V praxi to znamenalo, že AppContainer měl pro tento problém nevhodný tvar. Šlo o silnou izolaci, ale pro mnohem užší třídu úloh než „nechat agenta pracovat jako vývojáře“.

Windows Sandbox

• Co: Windows Sandbox je jednorázový odlehčený virtuální počítač od Microsoftu. Dostáváte o čistý počítač Windows se silnou izolační hranicí a vše, co v ní uděláte, po skončení relace zmizí.
• Proč: Zajímavý ze zřejmých důvodů – mnohem kompatibilnější s arbitrárním softwarem než AppContainer a z pohledu zabezpečení je to mnohem silnější bariéra.
• Proč ne: Codex potřebuje pracovat přímo se skutečným checkoutem, nástroji a prostředím uživatele, ne uvnitř odděleného dočasného systému, který vyžaduje instalaci a nastavení propojení hosta s hostitelem. Mělo to také zásadní produktový problém: Windows Sandbox není dostupný na SKU Windows Home.

Označování integrity Mandatory Integrity Control (MIC)

• Co to je: Windows má koncept „úrovní integrity“, jako jsou nízká, střední a vysoká, které určují, jak moc systém objektům a procesům důvěřuje. Základní pravidlo je, že proces s nižší integritou nemůže zapisovat do objektu s vyšší úrovní integrity, i kdyby to běžné ACL jinak povolovalo. Například proces s nízkou integritou je považován za méně důvěryhodný, takže mu Windows zablokuje zápis do běžných objektů se střední integritou, pokud tyto objekty nejsou výslovně označeny tak, že to dovolují.
• Proč: Model MIC vypadal na papíře elegantně – spustit Codex s nízkou integritou, přeznačit zapisovatelné kořeny na nízkou integritu a nechat Windows vynucovat zákaz zápisu všude jinde. To by nám dalo cestu bez oprávnění správce s oporou v mechanismu skutečného operačního systému.
• Proč ne: Stejně jako ACL i štítky integrity upravují skutečný souborový systém hostitele a v tomto případě je sémantická změna obzvlášť široká. Označit pracovní prostor nízkou integritou neznamená jen „Codex sem může zapisovat“. Znamená to, že tam mohou zapisovat procesy s nízkou integritou obecně. Na skutečném počítači vývojáře se tak z jeho checkoutu stává cíl s nízkou integritou pro hostitele, což je mnohem rizikovější než udělit pečlivě cílená ACL jednomu návrhu sandboxu. I když nástroje vývojáře se střední integritou mohou dál fungovat, základní model důvěry pracovního prostoru se změnil způsobem, který je těžké omezit a ještě těžší obhájit.

Po vyhodnocení všech možností jako slepých uliček jsme začali navrhovat vlastní řešení, které by uživatelům Windows poskytovalo dobrou funkčnost při používání Codexu.

Náš první funkční prototyp využíval kombinaci konceptů a nástrojů Windows k implementaci potřebné izolace. Od začátku bylo jedním z cílů zajistit, aby to fungovalo bez nutnosti zvýšených oprávnění, tedy aby Codex nemusel uživatele žádat o oprávnění správce jen kvůli instalaci a nastavení nebo spuštění sandboxu. To znamenalo najít způsob, jak rozumně omezit dvě věci: zápis do souborů a přístup k síti.

Pokud bychom zápis do souborů neomezili vůbec, měli bychom bezpečnostní problém. Pokud bychom ho omezili příliš, sandbox by brzdil produktivitu uživatelů a musel by neustále žádat o schvalování. K vyřešení tohoto problému jsme se opřeli o dva důležité stavební bloky systému Windows: SID a tokeny s omezeným zápisem.

SID neboli identifikátor zabezpečení je identita, ke které Windows váže oprávnění. Každý uživatel má SID, skupiny mají SID, a dokonce i jedna přihlašovací relace má vlastní SID. Například aktuální přihlášená relace může mít SID jako S-1-5-5-X-Y. SID přiřazený místní skupině správců může být S-1-5-32-544.

Windows také umožňuje vytvářet syntetické SID, která neodpovídají skutečnému uživateli, ale mohou se přesto objevit v ACL (seznamech řízení přístupu), které definují, kdo může číst, zapisovat nebo spouštět konkrétní soubory či adresáře. Díky tomu jsou SID užitečným primitivem pro náš sandbox: můžeme vytvořit SID výhradně pro použití sandboxem Codexu, aniž bychom zasahovali do čehokoli jiného na počítači.

Tokeny procesů jsou objekty zabezpečení ve Windows, které definují identitu a oprávnění spuštěného procesu. Určují, které akce může proces provádět. Token s omezeným zápisem je konkrétní typ tokenu procesu, kvůli kterému Windows při operacích zápisu provádí dodatečnou kontrolu přístupu.

Aby byl zápis úspěšný, musí projít dvě kontroly:

1. Běžná identita uživatele („vlastník“ tokenu) to musí mít povoleno
2. Alespoň jednomu SID v seznamu omezených SID tokenu musí být také udělen přístup

V praxi nám tyto kontroly umožnily používat ACL k přesnému vymezení míst, kde může sandbox upravovat souborový systém, což nám poskytlo potřebnou granularitu pro operace zápisu.

Se SID a tokeny s omezeným zápisem náš sandbox bez zvýšených oprávnění fungoval takto:

1. Nastavení sandboxu vytvořilo syntetický SID s názvem sandbox-write.
2. SID sandbox-write byl udělen přístup pro zápis, spouštění a mazání
   1. k aktuálnímu pracovnímu adresáři
   2. všem dalším položkám writable_roots nakonfigurovaným v souboru config.toml.
3. Nastavení sandboxu tomuto SID výslovně zakázalo přístup k zápisu do umístění „jen pro čtení v rámci zapisovatelných“, například:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex spouštěl příkazy pod tokenem s omezeným zápisem, jehož seznam omezených SID zahrnuje Všichni, SID aktuálně přihlášené relace a syntetický SID sandbox-write.

Tento postup účinně vyřešil omezení zápisu do souborů a vypadal slibně. Teď jsme potřebovali řešení pro omezení přístupu sandboxu k síti.

Omezení přístupu k síti je důležitou součástí sandboxu, bez něj by škodlivý kód mohl z počítače exfiltrovat data na internet. Protože jsme se chtěli vyhnout požadavku na zvýšená oprávnění, měli jsme omezené možnosti, jak síťový provoz důsledně blokovat. Nástroje, které jsme chtěli použít, jako brány Windows Firewall, obvykle nebylo možné nainstalovat bez oprávnění správce.

Bez brány Windows Firewall jsme měli omezené možnosti ovládání. Snažili jsme se, aby podřízené prostředí bylo pro typy síťových nástrojů, které vývojáři skutečně používají, uzavřené na chyby, aby příkazy Git, instalátory balíčků apod. v sandboxu selhaly a uživatel by musel schválit jakékoli operace směřující na internet. Myšlenkou bylo zmařit zjevné únikové cesty: směrovat provoz zohledňující proxy na mrtvý koncový bod, přimět přenos Git přes HTTP(S), aby dělal totéž, a zajistit, aby Git přes SSH selhal okamžitě. K tomu jsme ještě přidali malý adresář denybin na začátek PATH a změnili pořadí PATHEXT, aby se zástupné skripty SSH a SCP přeložily dříve než skutečné binární soubory.

Například zde jsou některá konkrétní potlačení proměnných prostředí, která jsme použili k omezení přístupu k síti:

• 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

Tím jsme zachytili velkou část běžného provozu iniciovaného nástroji, ale stále šlo jen o doporučení. Proces mohl prostředí ignorovat, obejít PATH nebo prostě otevřít sockety přímo – příliš riskantní.

Stejně jako u každé zajímavé softwarové implementace měl i první prototyp své výhody a nevýhody. Přestože odvedl práci jen s několika standardními schopnostmi Windows, umožňoval velmi explicitní a granulární zápisy do souborového systému a běžel bez zvýšených oprávnění – což eliminovalo nutnost, aby uživatelé museli odsouhlasovat nadměrné množství výzev k udělení oprávnění nebo byli správci na svém místním počítači – měl příliš mnoho nevýhod na to, aby se stal naším finálním návrhem:

• Rychlost nastavení: použití ACL na pracovní prostor může být v závislosti na topologii adresáře pracovního prostoru nákladná.
• Stopa v systému: aplikovali jsme skutečná ACL do systému vývojáře, i když tato stopa není nijak zvlášť invazivní, protože všechna použitá ACL se vztahují ke speciálně vytvořenému syntetickému SID, který používá pouze sandbox.
• Obtížně měnitelná sémantika: spoléhání na ACL pro omezení založená na souborech znamená, že změna sémantiky sandboxu je nákladná a složitá. Zatímco v macOS můžeme dynamicky měnit způsob generování souboru .sbpl používaného ke konfiguraci Seatbeltu, sandbox ve Windows může k úpravě ACL vyžadovat pomalou a intenzivní operaci.
• Síťová ochrana je slabá. Jak už bylo zmíněno, byla „doporučující“, některé programy s vlastní síťovou vrstvou by ji rozhodně obešly a nebyla navržena tak, aby obstála proti nepřátelskému kódu.

První tři problémy jsou vlastní každé implementaci vlastního sandboxu, která je dostatečně flexibilní pro agentní postupy. Příběh potlačení sítě byl ale jiný.

Kromě toho, že útočný agent mohl potlačení sítě založené na prostředí snadno obejít, obešlo by ho i mnoho kódu nebo binárních souborů s dobrými úmysly, pokud by nerespektovaly proměnné proxy prostředí nebo implementovaly vlastní síťový kód založený na socketech. Měli jsme za to, že tento aspekt sám o sobě stojí za investici do lepšího režimu sandboxu.

Abychom získali lepší potlačení sítě, chtěli jsme použít bránu Windows Firewall, která nám umožňuje blokovat odchozí síťový provoz pro uživatele nebo programy. Bohužel jsme nemohli efektivně vytvořit funkční pravidlo brány firewall, které by se vztahovalo jen na příkazy spouštěné harnessem Codexu, a to z několika důvodů:

• Windows neumožňuje přiřadit pravidlo brány firewall k identitě omezeného tokenu jiné než instančního objektu. To znamená, že jsme pravidlo brány firewall nemohli použít na „jakýkoli token, který ve svém seznamu omezených SID obsahuje náš syntetický SID“.
• I když bychom mohli vytvořit pravidlo brány firewall, které odpovídá konkrétnímu binárnímu souboru, umožnilo by nám to omezit síť pouze pro samotný soubor codex.exe. Nevztahovalo by se na procesy, které agent spouští jménem uživatele, jako jsou procesy Git nebo Python.
• Také ostatní dimenze shody brány firewallu byly nevhodné. Pravidla s oborem uživatele stále odpovídala skutečnému uživateli Windows v návrhu bez zvýšených oprávnění, ne pouze omezenému podřízenému procesu. Pravidla podle cesty k programu byla příliš hrubá: dokázala obecně blokovat codex.exe nebo python.exe, ale ne právě toto sandboxované spuštění python.exe. Pravidla založená na portech nebo adresách také představovala zcela nesprávnou zásadu. Nechtěli jsme například blokovat port 443, chtěli jsme blokovat libovolný odchozí přístup pro tento konkrétní omezený strom procesů.

Abychom mohli použít pravidlo brány firewall konkrétně na naše sandboxované příkazy, museli jsme je spouštět jako samostatný instanční objekt, ne jako „skutečného“ uživatele. Tento přístup nás zavedl na novou cestu, ve které jsme rozvolnili zásadu „bez zvýšených oprávnění“.

Další iterace sandboxu, která je naší současnou implementací, vyžaduje při nastavení zvýšená oprávnění správce. Proto ji označuji jako „sandbox se zvýšenými oprávněními“. Na hranici, kde Codex v systému spouští příkaz, vypadá sandbox se zvýšenými oprávněními podobně jako ten bez zvýšených oprávnění. Stále spouští podřízené procesy pod omezeným tokenem – podobně tokenem write_restricted se stejným seznamem omezených SID [Všichni, Přihlášení, Syntetický] – instanční objekt tohoto tokenu už však není skutečný uživatel Windows, ale jeden ze dvou místních uživatelů vytvořených samotným Codexem:

• CodexSandboxOffline (ten, na kterého cílí pravidla brány firewall)
• CodexSandboxOnline (ten, na kterého pravidla firewallu necílí)

Tento zdánlivě malý detail má ve skutečnosti zásadní důsledky pro sandbox, pro to, kdo ho může používat, i pro složitost jeho nastavení a běhu.

Vizuálně je podobný prototypu bez zvýšených oprávnění s přidáním pravidel brány firewall a vyhrazeného uživatele Windows, který příkazy skutečně spouští. (Zavedení těchto nových konceptů však znamená, že je víc práce s nastavováním, než sandbox může začít spouštět a chránit příkazy.)

Návrh sandboxu bez zvýšených oprávnění měl jednoduchý krok nastavení, ale byl relativně malý:

• Vytvořit syntetický SID, je-li potřeba
• Použít ACL pro syntetický SID sandbox-write

U sandboxu se zvýšenými oprávněními je toho však potřeba udělat víc.

• Vytvořit syntetický SID, pokud ještě nebyl vytvořen
• Vytvořit online a offline uživatele sandboxu, pokud ještě nebyli vytvořeni
• Uložit přihlašovací údaje nově vytvořených uživatelů lokálně a zašifrovat je pomocí rozhraní Windows Data Protection API (DPAPI) na místě, které uživatelé sandboxu nemohou skutečně číst
• Vytvořit pravidla brány firewall, která blokují veškerý odchozí síťový přístup pro uživatele CodexSandboxOffline, nebo pokud už existují, ověřit, že jsou správná

Ve fázi nastavení je ještě jeden háček. Od sandboxu Codexu se očekává, že bude mít přístup ke čtení ekvivalentní skutečnému uživateli Windows. V sandboxu bez zvýšených oprávnění, kde SID instančního objektu omezeného tokenu byl uživatel Windows, toho bylo dosaženo. To však není zadarmo, když se instanční objekt stane novým uživatelem CodexSandbox. Mnoho relevantních adresářů ve Windows uděluje oprávnění ke čtení a spouštění skupině „Ověření uživatelé“. Jedním významným příkladem je profilový adresář uživatele. Ve výchozím nastavení uživatelé Windows nemohou číst profilové adresáře jiných uživatelů Windows, takže i jednoduché čtení souborů by v mnoha situacích selhalo.

Abychom to vyřešili, přidali jsme do procesu nastavení sandboxu další vrstvu – pro udělení ACL pro čtení uživatelům sandboxu tam, kde taková ACL ještě možná neexistují. Například pro některé běžně používané adresáře Windows:

• C:\Users\<skutečný-uživatel>
• C:\Windows\
• C:\Program Files\
• C:\Program Files (x86)\
• C:\ProgramData\

Protože tento seznam adresářů je pouze nejlepší dostupný a instalace ACL na každý z nich může být poměrně nákladná, spouštíme tuto logiku asynchronně, takže krok nastavení sandboxu, který uživatele blokuje, na jejich dokončení nemusí čekat.

Logiku nastavení jsme zapouzdřili do samostatného binárního souboru částečně proto, abychom hranici UAC překračovali jen tehdy, když je to potřeba. Hlubší důvod byl ale architektonický: nastavení sandboxu má zásadně odlišnou úlohu než codex.exe. Oddělení logiky nastavení sandboxu do vyhrazeného binárního souboru umožnilo, aby soubor codex.exe zůstal běžným harnessem bez zvýšených oprávnění, zabránilo tomu, aby mechanika nastavení specifická pro Windows zvětšovala soubor codex.exe i na jiných platformách, oddělilo déle běžící práci při nastavení od životního cyklu hlavního procesu a dalo nám společné místo pro obsluhu různých cest nastavení, které sandbox potřeboval.

Vzhledem k tomu, jak ve Windows fungují hranice přihlášení uživatelů a tokenů, jsme nemohli dál vytvářet omezený token a spouštět pod ním proces stejným způsobem jako u sandboxu bez zvýšených oprávnění. Abychom skutečně mohli spouštět příkazy jako jiný uživatel Windows, náš první nápad byl následující postup:

• codex.exe běží jako skutečný uživatel Windows. Poté Codex postupně:
  • volá LogonUserW(...) pro uživatele sandboxu,
  • volá CreateRestrictedToken(...) pro daný token uživatele sandboxu,
  • pomocí tohoto omezeného tokenu uživatele sandboxu volá CreateProcessAsUserW(...) ke spuštění finálního podřízeného procesu.

V praxi tento zamýšlený postup nefungoval kvůli bariéře oprávnění u CreateProcessAsUserW(...). To znamená, že codex.exe mohl vytvořit omezený token pro uživatele sandboxu, ale nemohl ze strany hranice skutečného uživatele spolehlivě spustit podřízený proces s tímto tokenem. Potřebovali jsme proces, který už běží jako uživatel sandboxu – to by umožnilo, aby krok omezení a finální spuštění proběhly na straně uživatele sandboxu, nikoli na straně skutečného uživatele.

Tento požadavek vedl ke vzniku souboru codex-command-runner.exe, nového binárního souboru, jehož jedinou úlohou je vytvořit omezený token a spustit požadovaný příkaz. Místo toho, abychom po souboru codex.exe chtěli, aby provedl celý postup sám (skutečný uživatel → uživatel sandboxu → omezený token → podřízený proces), postup jsme rozdělili na dvě části:

1. část

• Soubor codex.exe zavolá CreateProcessWithLogonW(...) ke spuštění souboru codex-command-runner.exe jako uživatele sandboxu, zatím bez použití omezeného tokenu.

2. část

• Uvnitř runneru otevře OpenProcessToken(GetCurrentProcess(), ...) token samotného runneru, který už patří uživateli sandboxu.
• Runner zavolá GetTokenInformation(...), aby extrahoval SID přihlášení sandboxu, a poté CreateRestrictedToken(...), aby vytvořil finální omezený token.
• Stále uvnitř runneru pak zavolá CreateProcessAsUserW(...) s tímto omezeným tokenem a spustí skutečný podřízený proces.

Albert Einstein řekl: „Všechno by mělo být uděláno tak jednoduše, jak je to jen možné, ale ne jednodušeji.“ V tomto duchu náš návrh adekvátně vyřešil každý problém. Finální architektura má čtyři vrstvy, které jsme už popsali:

• samotný soubor codex.exe,
• soubor codex-windows-sandbox-setup.exe pro zpracování veškeré práce související s nastavením se zvýšenými oprávněními,
• codex-command-runner.exe ke spouštění příkazů pod omezeným tokenem,
• podřízený proces.

Když jsem se k tomuto projektu poprvé dostal, neměl jsem jasnou představu, kam až povede. Začal jsem tím, že jsem sandboxovací schopnost instrumentoval na hranici mezi Codexem a operačním systémem. Tento přístup se velmi podobá tomu, jak je sandbox Codexu implementován v systémech MacOS a Linux.

Jak jsem se dozvídal víc o konkrétních nástrojích, které Windows poskytuje, a jak jsme činili desítky rozhodnutí vyvažujících zabezpečení a snadnost použití, systém se rozrostl do své současné podoby – více binárních souborů, vlastní uživatelé, pravidla brány firewall, krok nastavení se zvýšenými oprávněními, asynchronní procesy a další.

Není to nijak zvlášť jednoduchý systém, ale každý prvek složitosti jsme přidali z nutnosti, abychom vybudovali sandbox, který je bezpečný a zároveň uživateli co nejméně překáží.

Ve snaze poskytnout uživatelům Codexu na Windows dobrou funkčnost bylo naším cílem vytvořit něco bezpečného, co nesleví z užitečnosti – celý smysl používání Codexu je v tom, aby agenti mohli pracovat bez neustálé pozornosti.

Jedním z největších ponaučení tohoto projektu bylo, že systém Windows nám neposkytlo jedno primitivum, které by se čistě mapovalo na „bezpečného autonomního programovacího agenta“. Složili jsme několik nástrojů a konceptů, abychom vytvořili něco soudržného. Některé první nápady byly slepé uličky. Konečný návrh je hybridem dřívějších prototypů, z nichž každý řešil část problému.

Druhým ponaučením bylo, že zabezpečení programovacího agenta je jiný druh problému než klasičtější zabezpečení aplikace. Codex musí fungovat ve skutečných pracovních postupech vývojářů. Vývojářská práce spočívala ve vyvažování kompatibility s agentními úlohami s reálným vynucováním. Toto napětí formovalo kompromisy ve finálním návrhu.

Zajímá vás, jak sandbox Codexu funguje v praxi? Vyzkoušejte si ho⁠.