Tworzenie bezpiecznego i wydajnego środowiska izolowanego dla Codex w systemie Windows

Kiedy dołączyłem do zespołu inżynieryjnego Codex we wrześniu 2025 roku, Codex dla systemu Windows nie zawierał środowiska izolowanego, co oznaczało, że użytkownicy systemu Windows byli zmuszeni wybierać między dwiema kiepskimi opcjami podczas korzystania z agentów kodujących OpenAI:

1. Zatwierdzaniem niemal każdego polecenia (nawet odczytu), które agent kodujący chciał uruchomić, co było nieefektywne i uciążliwe Podstawowy sens stosowania Codex polega na tym, żeby nie wykonywać samodzielnie całej żmudnej pracy.
2. Włączeniem trybu pełnego dostępu: zezwala to systemowi Codex na uruchamianie wszystkich poleceń bez zatwierdzania i ograniczeń, co z kolei zmniejsza niewygodę obsługi, ale przy jednoczesnej utracie kontroli.

Nasz agent kodujący Codex⁠ działa na laptopach deweloperów poprzez CLI, rozszerzenie IDE albo aplikację instalowanej na komputerze i zarządza konwersacją między człowiekiem przy klawiaturze a modelem działającym w chmurze, który obsługuje wnioskowanie.

Codex domyślnie działa z uprawnieniami prawdziwego użytkownika, co oznacza, że może zrobić wszystko to, co użytkownik. Podejście takie daje bardzo wysokie uprawnienia i jest potencjalnie niebezpieczne. Model kodujący może wymusić na warstwie wykonawczej lokalne realizowanie poleceń: uruchamianie testów, odczyt lub edycję pliku, a nawet tworzenie gałęzi Git. Dlatego też w trybie domyślnym Codex stara się znaleźć równowagę między skutecznością działania a bezpieczeństwem pracy. Tryb domyślny pozwala Codex odczytać pliki niemal wszędzie i zapisywać je w obrębie przestrzeni roboczej (tj. katalogu, z którego uruchamiany jest Codex) bez dostępu do internetu, chyba że użytkownik określi, że tego chce. Aby możliwe było takie automatyczne ograniczenie zapisu plików i dostępu do sieci w bezpiecznym zakresie, Codex potrzebuje środowiska izolowanego, które rzeczywiście egzekwuje te ograniczenia.

Środowisko izolowane to ograniczone środowisko wykonawcze. Gdy programista używa Codex, system operacyjny jego komputera uruchamia polecenie z ograniczonymi uprawnieniami, a ograniczenia propagują się w dół drzewa procesów. Każde polecenie Codex jest od początku uruchamiane jest w środowisku izolowanym, a każdy proces potomny ma takie same ograniczenia.

Codex potrzebuje funkcji separacji egzekwowanych przez system operacyjny komputera, aby skutecznie wykorzystywać izolację. Niektóre systemy operacyjne zapewniają narzędzia odpowiednie do tego celu (np. Seatbelt w systemie MacOs albo seccomp czy bubblewrap w Linux); jednak system Windows obecnie nie daje tego typu możliwości w konfiguracji domyślnej.

Aby korzystanie z Codex w systemie Windows było równie bezpieczne i wydajne jak w innych systemach, musieliśmy zaimplementować własne środowisko izolowane.

System Windows oferuje pewne narzędzia i podstawy separacji, jednak żadne z nich nie spełniało całkowicie naszych wymagań, więc przyjrzeliśmy się kilku potencjalnym rozwiązaniom – AppContainer, Windows Sandbox oraz etykietowaniu Mandatory Integrity Control.

AppContainer

• Kandydat: AppContainer to natywne środowisko izolowane w systemie Windows, czyli model przeznaczony dla aplikacji, które z góry dokładnie wiedzą, do czego potrzebują dostępu.
• Zalety: oferuje rzeczywiste ograniczenia systemu operacyjnego zamiast ograniczeń typu „pozornie najlepsze”.
• Wady: Codex nie jest jedną ściśle ograniczoną aplikacją. Obsługuje otwarte przepływy pracy programistów: powłoki, Git, Python, menedżery pakietów, narzędzia kompilacji i inne pliki wykonywalne, które agent uzna za potrzebne do działania. W praktyce AppContainer nie był odpowiednim kandydatem do tego typu działań, ponieważ zapewniał silną izolację, ale dla znacznie węższej klasy zadań niż definiowane stwierdzeniem „pozwól agentowi działać jak programiście”.

Windows Sandbox

• Kandydat: Windows Sandbox to jednorazowa lekka maszyna wirtualna Microsoft. Zapewnia nowy pulpit Windows z silną separacją, a wszystkie wykonane w jego ramach operacje znikają po zakończeniu sesji.
• Zalety: rozwiązanie to było interesujące, ponieważ zapewniało znacznie wyższą zgodność z dowolnym oprogramowaniem niż AppContainer, a z perspektywy bezpieczeństwa oznacza to dużo mocniejsze odizolowanie.
• Wady: Codex musi działać bezpośrednio na faktycznym repozytorium użytkownika, w jego narzędziach i środowisku, a nie w osobnym tymczasowym pulpicie, który wymagałby konfiguracji i mostkowania host/gość. Występował też podstawowy problem produktowy: Windows Sandbox nie jest nawet dostępny w edycjach Home systemu Windows.

Etykietowanie integralności Mandatory Integrity Control (MIC)

• Rozwiązanie: w systemie Windows występują „poziomy integralności” (niski, średni i wysoki), które określają, jak bardzo system ufa obiektom i procesom. Podstawowa zasada mówi, że proces o niższej integralności nie może zapisywać do obiektu o wyższym poziomie integralności, nawet jeśli zwykła lista ACL w innym wypadku by na to pozwalała. Przykładowo: proces o niskiej integralności jest traktowany jako mniej zaufany, więc system operacyjny blokuje mu zapis do zwykłych obiektów o średniej integralności, chyba że dla tych obiektów jawnie ponownie zostanie określone zezwolenie na zapis.
• Zalety: MIC wyglądał elegancko na papierze; pozwalał uruchomić Codex z niską integralnością, ponownie oznaczyć zapisywalne korzenie z określeniem niskiej integralności i pozwolić systemowi Windows na egzekwowanie braku zapisu wszędzie indziej. Zapewniałoby to ścieżkę bez uprawnień administratora z rzeczywistym mechanizmem systemowym w tle.
• Wady: podobnie jak ACL, etykiety integralności modyfikują rzeczywisty system plików hosta, a w tym przypadku zmiana semantyczna jest szczególnie szeroka. Oznaczenie przestrzeni roboczej z ustawieniem niskiej integralności nie oznacza tylko „Codex może tu zapisywać”. Oznacza, że procesy o niskiej integralności ogólnie mogą tam zapisywać. Na prawdziwym komputerze programisty zamienia to faktyczne repozytorium użytkownika w obszar pozwalający na zapisy o niskiej integralności dla hosta, co jest znacznie bardziej ryzykowne niż przyznanie starannie ukierunkowanych ACL jednemu projektowi środowiska izolowanego. Nawet jeśli narzędzia programistyczne o średniej integralności nadal by działały, podstawowy model zaufania przestrzeni roboczej zmieniłby się w sposób, który trudno ograniczyć i jeszcze trudniej uzasadnić.

Po ustaleniu, że żadna z tych opcji nie nadaje się do zastosowania zaczęliśmy projektować własne rozwiązanie, aby zapewnić użytkownikom Windows dobre wrażanie z używania Codex.

Nasz pierwszy działający prototyp stanowił połączenie koncepcji i narzędzi Windows pozwalających na wdrożenie potrzebnej nam izolacji. Od początku jednym z celów było zapewnienie, że nasze rozwiązanie będzie działać bez podwyższania uprawnień, co oznaczało, że Codex nie musiałby prosić użytkownika o uprawnienia administratora tylko po to, by skonfigurować lub uruchomić środowisko izolowane. Czyli musieliśmy wymyślić sposób na rozsądne ograniczenie dwóch działań: zapisu plików i dostępu do sieci.

Gdybyśmy w ogóle nie ograniczyli zapisu plików, mielibyśmy problem z bezpieczeństwem. Gdybyśmy ograniczyli go zbyt mocno, środowisko izolowane obniżałoby wydajność użytkownika, ciągle wyświetlając monity o zatwierdzenie. Aby rozwiązać ten problem, oparliśmy się na dwóch ważnych elementach składowych Windows: SID i tokenach z ograniczeniem zapisu.

SID, czyli identyfikator bezpieczeństwa, to tożsamość, do której system Windows przypisuje uprawnienia. Każdy użytkownik ma SID, grupy mają SID, a nawet pojedyncza sesja logowania otrzymuje własny SID. Przykładowo: SID bieżącej sesji logowania może wyglądać tak: S-1-5-5-X-Y. SID przypisany do lokalnej grupy administratorów może mieć postać S-1-5-32-544.

System Windows pozwala także tworzyć syntetyczne SID, które nie odpowiadają prawdziwemu użytkownikowi, ale nadal mogą pojawiać się w ACL (listach kontroli dostępu) definiujących, kto może odczytywać/zapisywać/wykonywać określone pliki lub katalogi. Ta cecha powoduje, że SID są użyteczne w kontekście naszego środowiska izolowanego, ponieważ możemy tworzyć SID przeznaczone wyłącznie do użytku przez izolację Codex bez zakłócania innych operacji na komputerze.

Tokeny procesów to obiekty bezpieczeństwa w systemie Windows, które definiują tożsamość i uprawnienia działającego procesu. Określają one zadania dostępne do wykonania przez proces. Token z ograniczeniem zapisu to szczególny typ tokenu procesu, który sprawia, że podczas operacji zapisu w systemie Windows przeprowadzane są dodatkowe kontrole dostępu.

Aby zapis się powiódł, dwie kontrole muszą zakończyć się pomyślnie:

1. Normalna tożsamość użytkownika (właściciela tokena) musi mieć możliwość wykonania operacji
2. Co najmniej jeden SID z listy ograniczonych SID tokena również musi mieć przyznany dostęp

Te kontrole pozwoliły nam używać ACL do dokładnego zdefiniowania, gdzie środowisko izolowane może modyfikować system plików, co zapewniło nam wymaganą precyzję w zakresie zarządzania operacjami zapisu.

Dzięki SID i tokenom z ograniczeniem zapisu nasze środowisko izolowane bez podwyższonych uprawnień działała następująco:

1. Podczas konfiguracji izolacji tworzony jest syntetyczny SID o nazwie sandbox-write.
2. Identyfikatorowi SID sandbox-write przyznano uprawnienia do zapisu, wykonywania i usuwania w:
   1. bieżącym katalogu roboczym,
   2. wszelkich dodatkowych zmiennych writable_roots skonfigurowanych w pliku config.toml.
3. Konfiguracja środowiska izolowanego odmawiała temu samemu SID możliwości zapisu w lokalizacji przeznaczonej „tylko do odczytu w obrębie lokalizacji zapisywalnych”, np.:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex uruchamia polecenia z tokenem z ograniczeniem zapisu, którego lista ograniczonych SID obejmuje Everyone, SID bieżącej zalogowanej sesji oraz syntetyczny SID sandbox-write.

Taka konfiguracja skutecznie rozwiązuje problem ograniczania zapisu plików i uznaliśmy ją za właściwą. Teraz potrzebowaliśmy rozwiązania do ograniczania dostępu środowiska izolowanego do sieci.

Ograniczanie dostępu do sieci jest ważnym aspektem środowiska izolowanego; bez tego zabezpieczenia złośliwy kod mógłby pobierać dane z komputera i przekazywać przez internet. Chcieliśmy uniknąć stosowania podwyższonych uprawnień, więc mieliśmy ograniczone możliwości silnego blokowania ruchu sieciowego. Narzędzi, których chcieliśmy użyć, takich jak Zapora systemu Windows, zasadniczo nie dało się zainstalować bez uprawnień administratora.

Brak możliwości użycia Zapory systemu Windows ograniczył zakres obszarów, które mogliśmy kontrolować. Próbowaliśmy wymusić, by działanie środowiska potomnego domyślnie kończyło się niepowodzeniem dla typów narzędzi sieciowych, z których deweloperzy faktycznie korzystają, tak aby działanie poleceń Git, instalatorów pakietów itd. kończyło się niepowodzeniem w środowisku izolowanym, a użytkownik musiał zatwierdzać wszelkie operacje odnoszące się do internetu. Chcieliśmy zablokować oczywiste drogi ucieczki i skierować ruch proxy do martwego punktu końcowego, wymusić to samo zachowanie w przypadku transportu HTTP(S) Git i spowodować, by działanie Git przez SSH kończyło się natychmiastowym niepowodzeniem. Ponadto dodaliśmy do PATH mały katalog denybin i zmieniliśmy kolejność PATHEXT, aby atrapowe skrypty SSH i SCP były realizowane przed prawdziwymi plikami wykonywalnymi.

Oto przykładowe nadpisania środowiska, których użyliśmy do ograniczenia dostępu do sieci:

• 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

Zatrzymywało to dużą część zwykłego ruchu generowanego przez narzędzia, ale nadal nie było rozwiązaniem idealnym, ponieważ proces mógł zignorować środowisko, ominąć PATH albo po prostu otworzyć gniazda bezpośrednio, co było zbyt ryzykowne.

Jak przy każdej ciekawej implementacji oprogramowania, pierwszy prototyp miał zalety i wady. Spełniał on swoje zadanie przy użyciu tylko kilku standardowych funkcji systemu Windows, pozwalał na bardzo jawne i szczegółowe zapisy w systemie plików oraz działał bez podwyższonych uprawnień (co ograniczało wymóg akceptowania przez użytkowników nadmiernej liczby monitów o podwyższenie uprawnień lub posiadanie praw administratora na komputerze lokalnym), jednak miał zbyt wiele wad, by uznać go za satysfakcjonujący:

• Szybkość konfiguracji: stosowanie ACL przestrzeni roboczej może być kosztowne w zależności od topologii katalogu przestrzeni roboczej.
• Ślad: stosowaliśmy rzeczywiste ACL w systemie programisty, chociaż ten ślad nie jest szczególnie inwazyjny, ponieważ wszystkie zastosowane ACL dotyczą niestandardowego, syntetycznego SID utworzonego wyłącznie na potrzeby środowiska izolowanego.
• Trudna do zmiany semantyka: poleganie na ACL przy ograniczeniach dot. plików sprawia, że zmiana semantyki środowiska izolowanego jest kosztowna i złożona. W systemie macOS możemy dynamicznie zmieniać sposób generowania pliku .sbpl używanego do konfiguracji Seatbelt, jednak środowisko izolowane w systemie Windows może wymagać długotrwałej i niewygodnej operacji dostosowania ACL.
• Ochrona sieciowa jest słaba. Jak wspomnieliśmy wcześniej, ochrona z pewnością zostałaby ominięta przez niektóre programy implementujące własny stos sieciowy i jej projekt nie umożliwiał powstrzymania działania wrogiego kodu.

Pierwsze trzy problemy są nieodłączną częścią niestandardowej implementacji środowiska izolowanego, która jest wystarczająco elastyczna dla przepływów agentowych. Sprawa z ograniczaniem dostępu do sieci wyglądała jednak inaczej.

Nie tylko złośliwy agent mógłby łatwo obejść blokady sieciowe oparte na środowisku, ale i wiele niegroźnych aplikacji/rozwiązań również mogło to zrobić poprzez nierespektowanie zmiennych proxy w środowisku lub implementację własnego kodu sieciowego opartego na gniazdach. Uznaliśmy, że ten aspekt sam w sobie jest wystarczającym powodem, by zainwestować w lepszy tryb izolowany.

Do zapewnienia lepszych blokad sieciowych chcieliśmy użyć Zapory systemu Windows, która pozwala blokować wychodzący ruch sieciowy dla użytkowników lub programów. Niestety nie mogliśmy skutecznie utworzyć działającej reguły zapory, która miałaby zastosowanie wyłącznie do poleceń uruchamianych przez warstwę wykonawczą Codex, z kilku powodów:

• System Windows nie pozwala dopasować reguły zapory do tożsamości niebędącej główną tożsamością ograniczonego tokena. Oznacza to, że nie mogliśmy zastosować reguły zapory do „dowolnego tokena, który zawiera nasz syntetyczny SID na liście ograniczonych SID”.
• Mogliśmy utworzyć regułę zapory dopasowaną do konkretnego pliku wykonywalnego, jednak pozwala to ograniczyć dostęp sieciowy tylko dla samego procesu codex.exe. Nie działałoby to względem procesów, które agent uruchamia w imieniu użytkownika, takich jak procesy Git czy Python.
• Inne aspekty dopasowania zapory również nie zapewniały oczekiwanych rezultatów. Reguły ograniczone do użytkownika nadal odwoływały się do prawdziwego użytkownika Windows w projekcie bez podwyższonych uprawnień, a nie tylko do ograniczonego procesu potomnego. Reguły oparte na ścieżce programu były zbyt ogólne: mogły blokować ogólnie procesy codex.exe lub python.exe, ale nie proces python.exe uruchamiany w środowisku izolowanym. Reguły oparte na porcie lub adresie także nie sprawdziły się. Przykładowo: nie chcieliśmy blokować portu 443; chcieliśmy blokować dowolny wychodzący dostęp dla tego konkretnego ograniczonego drzewa procesów.

Aby zastosować regułę zapory konkretnie do naszych poleceń uruchamianych w środowisku izolowanym, musieliśmy uruchamiać je jako osobny podmiot zabezpieczeń, a nie jako „prawdziwy” użytkownik. To podejście skierowało nas na nowe tory i poluzowaliśmy nasze ograniczenie „bez podwyższonych uprawnień”.

Kolejna iteracja środowiska izolowanego, która jest naszą obecną, wymaga podwyższonych uprawnień administratora w czasie konfiguracji. Dlatego nazywamy ją „środowiskiem izolowanym z podwyższonymi uprawnieniami”. Na granicy, gdzie Codex uruchamia polecenie w systemie, środowisko izolowane z podwyższonymi uprawnieniami wygląda jak środowisko bez podwyższonych uprawnień. Nadal uruchamia procesy potomne z ograniczonym tokenem (podobnie do tokenu write_restricted z tą samą listą ograniczonych SID [Everyone, Logon, Synthetic]), jednak podmiotem tego tokena nie jest już rzeczywisty użytkownik Windows, lecz jeden z dwóch użytkowników lokalnych utworzonych przez sam Codex:

• CodexSandboxOffline (objęty regułami zapory)
• CodexSandboxOnline (nieobjęty regułami zapory)

Ten pozornie drobny szczegół ma w rzeczywistości duże konsekwencje dla środowiska izolowanego, jego dozwolonych użytkowników oraz złożoności jego konfiguracji i wykonywania.

Wizualnie przypomina ono prototyp bez podwyższonych uprawnień, ale zawiera reguły zapory i dedykowanego użytkownika Windows, który faktycznie uruchamia polecenia. Jednak wprowadzenie tych nowych koncepcji oznacza, że należy prowadzić więcej działań konfiguracyjnych, zanim środowisko izolowane będzie mogło uruchamiać i chronić polecenia).

Środowisko izolowane bez podwyższonych uprawnień było stosunkowo proste w konfiguracji:

• Utworzenie syntetycznego SID w razie potrzeby
• Zastosowanie ACL dla syntetycznego SID sandbox-write

W środowisku izolowanym z podwyższonymi uprawnieniami czeka jednak więcej pracy.

• Utworzenie syntetycznego SID, jeśli nie został jeszcze utworzony
• Utworzenie użytkowników środowiska online i offline, jeśli nie zostali jeszcze utworzeni
• Lokalne przechowanie poświadczeń nowo utworzonych użytkowników i zaszyfrowanie ich za pomocą interfejsu Windows Data Protection API (DPAPI) w miejscu, którego użytkownicy środowiska izolowanego rzeczywiście nie mogą odczytać
• Utworzenie reguł zapory blokujących cały wychodzący ruch sieciowy dla użytkownika CodexSandboxOffline lub, jeśli już istnieją, zweryfikowanie ich poprawności

Na etapie konfiguracji pojawia się dodatkowe utrudnienie. Od środowiska izolowanego Codex oczekuje się dostępu do odczytu analogicznego do odczytu na poziomie rzeczywistego użytkownika systemu Windows. W środowisku bez podwyższonych uprawnień, gdzie główny SID ograniczonego tokena był użytkownikiem Windows, zostało to osiągnięte. Jednak występują pewne problemy, gdy głównym podmiotem staje się nowy użytkownik CodexSandbox. Wiele istotnych katalogów w Windows przyznaje uprawnienia do odczytu/wykonywania „uwierzytelnionym użytkownikom”. Jednym z ważnych przykładów jest katalog profilu użytkownika. Domyślnie użytkownicy Windows nie mogą odczytywać katalogów profilowych innych użytkowników Windows, więc nawet proste odczyty plików w wielu scenariuszach kończyłyby się niepowodzeniem.

Aby temu zaradzić, dodaliśmy kolejną warstwę do procesu konfiguracji środowiska izolowanego – przyznającą użytkownikom środowiska izolowanego ACL uprawnienia do odczytu w obszarach, gdzie takie listy mogą jeszcze nie istnieć. Na przykład dla niektórych często używanych katalogów Windows:

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

Ponieważ ta lista katalogów ma charakter „najlepsze możliwe”, a instalowanie ACL na każdym z nich może być dość kosztowne, uruchamiamy tę logikę asynchronicznie, aby etap konfiguracji środowiska izolowanego, który blokuje użytkowników, nie musiał czekać na ukończenie.

Zamknęliśmy logikę konfiguracji w osobnym pliku wykonywalnym częściowo po to, by przekraczać granicę UAC tylko wtedy, gdy jest to potrzebne. Ale ważniejszy powód był związany z architekturą: konfiguracja środowiska izolowanego ma zasadniczo inne zadanie niż proces codex.exe. Utrzymanie logiki konfiguracji środowiska izolowanego w dedykowanym pliku wykonywalnym: pozwoliło procesowi codex.exe pozostać zwykłą warstwą wykonawczą bez podwyższonych uprawnień; zapewniło, że konfiguracja tylko dla systemu Windows nie spowoduje rozrostu codex.exe na innych platformach; oddzieliło dłużej trwające prace konfiguracyjne od czasu działania procesu głównego; oraz zapewniło możliwość obsługi różnych ścieżek konfiguracji wymaganych przez środowisko izolowane w jednym miejscu.

Ze względu na to, jak działają granice logowania użytkowników i tokenów w Windows, nie mogliśmy dalej tworzyć ograniczonego tokena i uruchamiać pod nim procesu tak, jak mogliśmy to robić w środowisku izolowanym bez podwyższonych uprawnień. Nasz pierwszy pomysł na faktyczne uruchamianie poleceń jako inny użytkownik Windows wyglądał następująco:

• codex.exe działa jako rzeczywisty użytkownik systemu Windows. Następnie Codex kolejno:
  • Wywołuje LogonUserW(...) dla użytkownika środowiska izolowanego.
  • Wywołuje CreateRestrictedToken(...) dla tego tokenu użytkownika środowiska izolowanego.
  • Za pomocą tego ograniczonego tokena użytkownika środowiska izolowanego wywołuje CreateProcessAsUserW(...), aby uruchomić końcowy proces potomny.

W praktyce ten pożądany przepływ nie zadziałał z powodu bariery uprawnień w przypadku CreateProcessAsUserW(...). Oznacza to, że codex.exe mógł utworzyć ograniczony token dla użytkownika środowiska izolowanego, ale nie mógł niezawodnie uruchomić z tym tokenem procesu potomnego po stronie granicy należącej do rzeczywistego użytkownika. Potrzebowaliśmy procesu, który już działał jako użytkownik środowiska izolowanego. Pozwoliłoby to na występowanie etapu ograniczenia i końcowego uruchomienia po stronie granicy należącej do użytkownika środowiska izolowanego, a nie po stronie rzeczywistego użytkownika.

To wymaganie doprowadziło do powstania nowego pliku wykonywalnego codex-command-runner.exe, którego jedynym zadaniem jest utworzenie ograniczonego tokena i uruchomienie żądanego polecenia. Zamiast wymagać od codex.exe wykonania całego przepływu (rzeczywisty użytkownik → użytkownik środowiska izolowanego → ograniczony token → proces potomny), podzieliliśmy przepływ na dwie części:

Część 1

• codex.exe wywołuje CreateProcessWithLogonW(...), aby uruchomić codex-command-runner.exe jako użytkownika środowiska izolowanego, bez używania jeszcze ograniczonego tokena.

Część 2

• Wewnątrz realizatora OpenProcessToken(GetCurrentProcess(), ...) otwiera własny token realizatora, który już należy do użytkownika środowiska izolowanego.
• Realizator wywołuje GetTokenInformation(...), aby wyodrębnić SID logowania środowiska izolowanego, a następnie CreateRestrictedToken(...), aby utworzyć końcowy ograniczony token.
• Nadal wewnątrz realizatora wywołuje CreateProcessAsUserW(...) z tym ograniczonym tokenem, aby uruchomić właściwy proces potomny.

Albert Einstein powiedział: „Wszystko powinno być tak proste, jak to tylko możliwe, ale nie prostsze”. Zgodnie z tą ideą nasz projekt odpowiednio rozwiązał każdy problem. Ostateczna architektura ma cztery warstwy, które omówiliśmy wcześniej:

• codex.exe
• codex-windows-sandbox-setup.exe do obsługi wszystkich zadań konfiguracyjnych wymagających podwyższonych uprawnień
• codex-command-runner.exe do uruchamiania poleceń z ograniczonym tokenem
• Proces potomny

Kiedy na początek konfrontowałem się z tym projektem, nie miałem pojęcia, jak będzie wyglądać jego ostateczne rozwiązanie. Na początek chciałem zinstrumentalizować możliwości środowiska izolowanego na granicy między Codex a systemem operacyjnym. To podejście ściśle odpowiada temu, jak środowisko izolowane Codex jest zaimplementowane w systemach MacOs i Linux.

W miarę poznawania konkretnych narzędzi dostępnych w systemie Windows i odejmowania decyzji równoważących bezpieczeństwo i łatwość użycia, system rozrósł się do obecnej postaci – wielu plików wykonywalnych, niestandardowych użytkowników, reguł zapory, etapu konfiguracji z podwyższonymi uprawnieniami, procesów asynchronicznych i innych.

Jest to dość skomplikowane rozwiązanie, ale każdy element złożoności został dodany z konieczności, aby mogło powstać środowisko wykonywalne, które jest bezpieczne i jak najmniej przeszkadza użytkownikowi w pracy.

Skupiając się na wygodzie użytkowników korzystających z Codex w systemie Windows, naszym celem było stworzenie systemu bezpiecznego i wygodnego w obsłudze, ponieważ cały sens używania Codex polega na tym, by agenty mogły wykonywać pracę bez ciągłych interakcji z użytkownikiem.

Jednym z najważniejszych wniosków z tego projektu było to, że system Windows nie zapewnił elementu podstawowego, który jednoznacznie pozwalałby na korzystanie z „bezpiecznego autonomicznego agenta kodującego”. Uzyskanie spójnego rozwiązania wymagało zestawienia kilku narzędzi i koncepcji. Niektóre początkowe pomysły okazały się ślepymi zaułkami, a ostateczny projekt był hybrydą wcześniejszych prototypów, z których każdy rozwiązywał część problemu.

Drugi wniosek to: bezpieczeństwo w kontekście agenta kodującego to zupełnie inne bezpieczeństwo niż w przypadku klasycznej aplikacji. Codex musi działać w prawdziwych przepływach pracy programistów. Praca inżynieryjna polegała na równoważeniu zgodności z obciążeniami agentowymi z realnym egzekwowaniem. To napięcie ukształtowało kompromisy w ostatecznym projekcie.

Chcesz zobaczyć jak działa środowisko izolowane Codex? Wypróbuj⁠.