Windows жүйесінде Codex-ті іске қосуға мүмкіндік беретін қауіпсіз әрі тиімді оқшауланған орта құру

Мен 2025 жылдың қыркүйегінде Codex инженерлік командасына қосылған кезде, Windows жүйесіне арналған Codex-те оқшауланған орта іске асырылмаған еді, яғни Windows пайдаланушылары OpenAI компаниясының код жазу агенттерін пайдаланғанда сапасы төмен екі нұсқаның бірін таңдауға мәжбүр болды:

1. Бағдарламалау агенті іске қосқысы келген әрбір дерлік команданы (тіпті оқу командаларын да) мақұлдау қажет болды. Бұл тиімсіз әрі қолайсыз еді. Codex қолданудың басты артықшылықтарының бірі — барлық жалықтыратын жұмысты өзіңіз істеудің қажеті жоқ.
2. Толық қолжетімділік режимін қосу: Codex-ке барлық командаларды мақұлдаусыз немесе шектеусіз орындауға мүмкіндік береді, бұл бақылау есебінен үйкелісті жояды.

Біздің бағдарламалау агентіміз Codex⁠ әзірлеушілердің ноутбуктерінде CLI, IDE кеңейтімі немесе жұмыс үстелі қолданбасы арқылы жұмыс істейді. Ол пернетақта арқылы жұмыс істейтін адам мен инференсті өңдеу үшін бұлтта жұмыс істейтін модель арасындағы сөйлесуді басқарады.

Codex әдепкі бойынша нақты пайдаланушының рұқсаттарымен жұмыс істейді, яғни ол пайдаланушы жасай алатын барлық әрекетті орындай алады. Бұл қуатты әрі ықтимал қауіпті. Код жазу моделі harness жүйесіне жергілікті түрде командаларды орындауды: тесттерді орындаудан бастап файлды оқуға немесе өңдеуге, Git тармағын жасауға дейін тапсыруы мүмкін, сондықтан Codex-тің әдепкі режимі тиімділік пен қауіпсіздік арасындағы дұрыс тепе-теңдікті табуға тырысады. Бұл әдепкі режим Codex-ке файлдарды кез келген дерлік жерден оқуға және жұмыс кеңістігіңізде, (яғни Codex іске қосылған каталогта) файл жазуға мүмкіндік береді. Интернетке қатынау рұқсаты сіз оны арнайы көрсеткен жағдайда ғана беріледі. Файл жазу және желіге қатынау әрекеттерін қауіпсіз шектерде автоматты түрде шектеу үшін Codex-ке осы шектеулерді нақты қолдана алатын оқшауланған орта қажет.

Оқшауланған орта — шектеулі орындау ортасы. Әзірлеуші Codex-ті пайдаланғанда, оның компьютерінің операциялық жүйесі рұқсаттары шектелген пәрменді іске қосады, ал бұл шектеулер процесс ағашы бойынша таралады. Әрбір Codex пәрмені басынан бастап оқшауланады, ал одан тарайтын әрбір туынды процесс сол шектің ішінде қалады.

Тиімді оқшауланған ортаны іске асыру үшін Codex-ке компьютердің операциялық жүйесі қолданатын оқшаулау мүмкіндіктері қажет. Кейбір операциялық жүйелер мұны жақсы орындайтын құралдарды ұсынады (мысалы, macOS жүйесіндегі Seatbelt, Linux жүйесіндегі seccomp немесе bubblewrap); алайда Windows қазіргі уақытта мұндай мүмкіндікті әдепкі түрде ұсынбайды.

Codex-ті Windows жүйесінде де басқа жерлердегідей қауіпсіз әрі қолдануға жайлы ету үшін, өзіміздің оқшауланған ортаны іске асыруымыз керек болды.

Windows оқшаулау үшін кейбір құралдар мен негізгі элементтерді ұсынады. Олардың ешқайсысы талаптарымызға толық сай келмесе де, біз бірқатар ықтимал шешімдерді қарастырдық, атап айтқанда: AppContainer, Windows Sandbox және Mandatory Integrity Control таңбалауы.

AppContainer

• Мәні: AppContainer — Windows жүйесінің жергілікті оқшауланған ортасы, яғни өздеріне нақты не қажет екенін алдын ала білетін қолданбаларға арналған мүмкіндіктерге негізделген оқшаулау моделі.
• Неге жарайды: Бұл тәсіл тартымды көрінді, өйткені ол ең жақсы күш-жігерді шектеудің орнына операциялық жүйе деңгейіндегі нақты шекара ұсынады.
• Неге жарамайды: Codex — аясы қатаң шектелген бір ғана қолданба емес. Ол алдын ала шектелмеген әзірлеуші жұмыс процестерін: shell-дер, Git, Python, пакет менеджерлері, құрастыру құралдары және агент қажет деп шешкен кез келген басқа бинарлық файлдарды іске қосады. Іс жүзінде бұл AppContainer-ды осы мәселе үшін жарамсыз етті. Бұл күшті оқшаулау болды, бірақ ол «агентке әзірлеуші сияқты жұмыс істеуге мүмкіндік беру» дегенге қарағанда әлдеқайда тар жұмыс жүктемелері санатына арналды.

Windows Sandbox (оқшауланған орта)

• Мәні: Windows Sandbox — Microsoft компаниясының уақытша қолдануға арналған жеңіл виртуалды машинасы. Сіз оқшаулау шекарасы мықты таза Windows жұмыс үстелін аласыз, және оның ішінде жасаған барлық әрекеттеріңіз сеанс аяқталған кезде жоғалады.
• Неге жарайды: Айқын себептермен қызықты — AppContainer-ге қарағанда кез келген бағдарламалық жасақтамамен әлдеқайда үйлесімді, әрі қауіпсіздік тұрғысынан бұл әлдеқайда берік оқшаулау ортасы.
• Неге жарамайды: Codex пайдаланушының нақты төлем процесі, құралдары мен ортасында тікелей әрекет етуі керек, орнатуды және хост пен қонақ арасындағы көпірлеуді қажет ететін бөлек уақытша жұмыс үстелінде емес. Сондай-ақ оның өнімге қатысты түбегейлі мәселесі де болды: Windows Sandbox тіпті Windows Home SKU нұсқаларында да қолжетімді емес.

Міндетті тұтастықты бақылау (MIC) белгілеу жүйесі

• Мәні: Windows жүйесінде жүйенің нысандар мен процестерге қаншалықты сенетінін анықтайтын төмен, орташа және жоғары сияқты «тұтастық деңгейлері» (integrity levels) деп аталатын ұғым бар. Негізгі ереже мынада: тұтастық деңгейі төмен процесс тұтастық деңгейі жоғары нысанға жаза алмайды, тіпті әдеттегі ACL (Access Control List) бұған рұқсат берген жағдайда да. Мысалы, тұтастық деңгейі төмен процесс сенімділігі төмен деп қарастырылады, сондықтан Windows оған қалыпты тұтастық деңгейі орташа нысандарға жазуды бұғаттайды, егер ол нысандар бұған рұқсат беретіндей етіп анық қайта белгіленбесе.
• Неге жарайды: MIC қағаз жүзінде ұтымды көрінді — Codex-ті төмен тұтастық деңгейінде іске қосу, жазуға болатын түбірлік каталогтарды төмен тұтастық деңгейі ретінде қайта белгілеу және қалған барлық жерде жазуға тыйым салуды Windows-қа орындатады. Бұл бізге негізінде нақты ОЖ механизмі бар, әкімші құқықтарын қажет етпейтін жол берер еді.
• Неге жарамайды: Қол жеткізуді басқару тізімдері (ACL) сияқты, тұтастық белгілері хосттың нақты файлдық жүйесін өзгертеді, ал бұл жағдайда семантикалық өзгеріс әсіресе ауқымды болады. Жұмыс кеңістігін төмен тұтастықты деп белгілеу тек «Codex мұнда жаза алады» дегенді білдірмейді. Бұл тұтастығы төмен процестердің жалпы алғанда сол жерге жаза алатынын білдіреді. Нағыз әзірлеуші машинасында бұл пайдаланушының нақты төлемін хост үшін төмен тұтастықтағы қабылдағышқа айналдырады, бұл бір оқшауланған орта дизайнына мұқият бағытталған ACL беруден әлдеқайда қауіпті. Орташа тұтастық деңгейіндегі әзірлеуші құралдары жұмысын жалғастырса да, жұмыс кеңістігінің негізіндегі сенім моделі бақылауда ұстау және негіздеу қиын болатындай өзгерді.

Барлық нұсқаларды жарамсыз деп бағалаған соң, Windows пайдаланушыларына жақсы Codex тәжірибесін ұсыну үшін өз шешімімізді жобалауға кірістік.

Біздің алғашқы жұмыс істейтін прототипіміз бізге қажет оқшаулауды іске асыру үшін Windows тұжырымдамалары мен құралдарының үйлесімін қолданды. Бастапқы мақсаттардың бірі — мұның жоғарылатуды талап етпей жұмыс істеуін қамтамасыз ету болды, яғни оқшауланған ортаны орнату немесе іске қосу үшін Codex пайдаланушыдан әкімші артықшылықтарын көмексөз етуінің қажеті жоқ еді. Бұл екі нәрсеге: файл жазуға және желіге кіруге қалай шектеу қою керектігін анықтауды білдірді.

Егер файл жазу әрекеттерін мүлде шектемесек, қауіпсіздік мәселесі туындайтын еді. Егер файл жазу әрекеттерін тым қатты шектесек, оқшауланған орта пайдаланушы өнімділігіне кері әсер етер еді, өйткені үнемі мақұлдау сұрауға тура келер еді. Бұл мәселені шешу үшін біз Windows жүйесінің екі маңызды құрылымдық элементіне сүйендік: SID (Қауіпсіздік идентификаторлары) және жазуға шектелген токен.

SID (қауіпсіздік идентификаторы) — Windows рұқсаттармен байланыстыратын сәйкестік. Әрбір пайдаланушының SID (қауіпсіздік идентификаторы) бар, топтардың да SID-тері бар, тіпті бір кіру сессиясына жеке SID беріледі. Мысалы, ағымдағы жүйеге кірген сеанста S-1-5-5-X-Y сияқты SID (қауіпсіздік идентификаторы) болуы мүмкін. Жергілікті әкімшілер тобына тағайындалған SID S-1-5-32-544 болуы мүмкін.

Windows жүйесі нақты пайдаланушыға сәйкес келмейтін, бірақ нақты файлдарды немесе каталогтарды кім оқи/жаза/орындай алатынын анықтайтын ACL тізімдерінде (қолжетімділікті басқару тізімдері) әлі де пайда болуы мүмкін синтетикалық SID идентификаторларын жасауға да мүмкіндік береді. Бұл SID идентификаторларын біздің Codex оқшаулау ортамыз үшін пайдалы негізгі элементке айналдырады: біз компьютердегі басқа ешнәрсеге кедергі келтірмей, тек Codex оқшаулау ортасы пайдалануы үшін SID идентификаторларын жасай аламыз.

Процесс токендері — Windows жүйесінде орындалып жатқан процестің сәйкестігі мен артықшылықтарын анықтайтын қауіпсіздік объектілері. Олар процестің қандай әрекеттерді орындай алатынын анықтайды. Жазуға шектелген токен — Windows жүйесінде жазу операцияларында қосымша қол жеткізуді тексеруді орындататын процесс токенінің ерекше түрі.

Жазу сәтті орындалуы үшін екі тексеру сәтті өтуі керек:

1. Қалыпты пайдаланушы сәйкестігіне («иелік» токені) мұны орындауға рұқсат берілуі керек
2. Токеннің шектелген SID тізіміндегі кемінде бір SID-ке кіру рұқсаты берілуі керек

Іс жүзінде бұл тексерулер бізге ACL-дерді пайдаланып, оқшауланған ортаның файлдық жүйені нақты қай жерде өзгерте алатынын дәл анықтауға мүмкіндік берді, бұл жазу операциялары үшін бізге қажет болған түйіршіктілік деңгейін қамтамасыз етті.

SID-тер мен жазуға шектелген токендер арқылы біздің деңгейсіз оқшауланған ортамыз былай жұмыс істеді:

1. Оқшауланған орта орнатуы sandbox-write деп аталатын синтетикалық SID жасады.
2. sandbox-write SID идентификаторына келесі нысанға жазу, орындау және жою рұқсаты берілді
   1. Ағымдағы жұмыс каталогі
   2. config.toml ішінде бапталған кез келген қосымша writable_roots.
3. Оқшауланған ортаның орнатуы дәл сол SID үшін «жазылатын аймақ ішіндегі тек оқуға арналған» орындарға жазу рұқсатын нақты түрде бұғаттады, мысалы:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex пәрмендерді жазуға шектелген токен арқылы іске қосты, оның шектелген SID тізіміне Everyone, ағымдағы жүйеге кірген сеанстың SID-і және sandbox-write синтетикалық SID-і кіреді.

Бұл ағын файл жазу операцияларын шектеу мәселесін тиімді шешіп, үміт күттіретіндей көрінді. Енді оқшауланған ортаның желіге қолжетімділігін шектеуге арналған шешім қажет болды.

Желіге қолжетімділікті шектеудің оқшауланған орта үшін маңызды бөлік; онсыз зиянды код құрылғыдағы деректерді интернетке шығарып жіберуі мүмкін. Жоғарылатуды талап етпеуді көздегендіктен, желілік трафикті қатаң бұғаттау мүмкіндіктеріміз шектеулі болды. Windows Firewall сияқты қолданғымыз келген құралдарды, әдетте, әкімші рұқсаттарынсыз орнату мүмкін емес еді.

Windows Firewall қосымшасынсыз біз басқара алатын нәрселерімізді шектедік. Біз әзірлеушілер шын мәнінде пайдаланатын желілік құралдар үшін еншілес ортаны жабық күйде істен шығатындай етуге тырыстық, осылайша Git командалары, пакет орнатқыштар және т.б. оқшауланған ортада орындалмай, интернетпен байланысатын кез келген операцияны пайдаланушы мақұлдауы қажет болады. Идея айқын айналып өту жолдарын жарамсыз ету болды: проксиді ескеретін трафикті істемейтін соңғы нүктеге жіберу, Git-тің HTTP(S) тасымалын да солай жасау және SSH арқылы Git-тің бірден сәтсіз аяқталуын қамтамасыз ету. Бұған қоса, PATH басына шағын denybin каталогын қостық және PATHEXT ретін өзгерттік. Осылайша stub SSH және SCP скрипттері нақты екілік файлдарынан бұрын табылатын болды.

Мысалы, желіге қолжетімділікті шектеу үшін біз қолданған нақты орта параметрлерін қайта анықтау баптауларының кейбірі мыналар:

• 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=жергілікті хост,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd/c 1-шығу

Бұл әдеттегі құралдар арқылы өтетін трафиктің көп бөлігін қамтыды, бірақ бәрібір тек ұсынымдық сипатта қалды. Процесс ортаны елемеуі, PATH-ты айналып өтуі немесе сокеттерді тікелей ашуы мүмкін — бұл өте қауіпті.

Кез келген қызықты бағдарламалық жасақтаманы енгізудегідей, алғашқы прототиптің кейбір артықшылықтары мен кемшіліктері болды. Ол бірнеше стандартты Windows мүмкіндігімен-ақ міндетті орындап, файл жүйесіне өте нақты әрі ұсақ деңгейде жазу рұқсаттарын беруге мүмкіндік жасады және жоғары құқықтарсыз жұмыс істеді. Бұл пайдаланушыларға шамадан тыс жоғарылау көмексөздерін қабылдау немесе жергілікті құрылғысында әкімші болу қажеттігін азайтты. Дегенмен оның нақты кемшіліктері болды, олардың кейбірі оны соңғы дизайн ретінде таңдауға мүмкіндік бермеді:

• Орнату жылдамдығы: Жұмыс кеңістігінің ACL-дерін қолдану жұмыс кеңістігі каталогының топологиясына байланысты қымбатқа түсуі мүмкін.
• Әсер ауқымы: Біз әзірлеушінің жүйесіне нақты қолжетімділік басқару тізімдерін (ACL) қолдандық. Алайда бұл аса терең араласуды қажет етпейді, себебі қолданылған барлық ACL тек оқшауланған орта пайдаланатын арнайы жасалған синтетикалық қауіпсіздік идентификаторына (SID) қатысты.
• Өзгертуі қиын семантика: Файлға негізделген шектеулер үшін қол жеткізуді басқару тізімдеріне (ACLs) сүйену оқшауланған орта семантикасын өзгертуді күрделі әрі көп шығынды етеді. macOS жүйесінде Seatbelt баптауға арналған .sbplфайлын жасау тәсілін динамикалық түрде өзгерте аламыз, ал Windows оқшауланған орта жүйесінде ACL рұқсаттарын реттеу үшін баяу әрі ресурсты көп қажет ететін операция қажет болуы мүмкін.
• Желі қорғанысы әлсіз. Бұрын айтылғандай, бұл тек «ұсыныстық» сипатта болды, сондықтан өз желілік стегін қолданатын кейбір бағдарламалар оны міндетті түрде айналып өте алатын, әрі қарсылас (зиянды) кодқа төтеп беруге арналып жасалмаған.

Алғашқы үш мәселе агенттік ағындарды қолдауға жеткілікті икемді арнайы оқшауланған ортаны іске асыруға тән. Дегенмен, желіні басу оқиғасы өзгеше болды.

Зиянды агент қоршаған ортаға негізделген желіні басуды оңай айналып өте алуымен қатар, көптеген жақсы ниеттегі код/екілік файлдар қоршаған орта прокси айнымалыларын ескермесе немесе өздерінің сокетке негізделген желілік кодын енгізсе, оны айналып өте алады. Біз осы аспектінің өзі жақсырақ оқшауланған орта (sandbox) режиміне инвестиция салуды қарастыруға жеткілікті деп санадық.

Желіні тиімдірек басу үшін біз Windows брандмауэрін пайдаланғымыз келді, ол пайдаланушылар немесе бағдарламалар үшін шығыс желі трафигін бұғаттауға мүмкіндік береді. Өкінішке қарай, бірнеше себепке байланысты Codex harness-і іске қосқан пәрмендерге ғана қолданылатын жұмыс істейтін брандмауэр ережесін тиімді түрде жасай алмадық:

• Windows шектелген токеннің негізгі емес идентификаторына брандмауэр ережесін сәйкестендіруге мүмкіндік бермейді. Бұл «шектелген SID тізімінде біздің синтетикалық SID-імізді қамтитын кез келген токенге» брандмауэр ережесін қолдана алмадық дегенді білдіреді.
• Белгілі бір екілік файлға сәйкес келетін брандмауэр ережесін жасай алсақ та, бұл тек codex.exe файлының желілік қатынасын шектеуге мүмкіндік береді. Бұл агент пайдаланушының атынан іске қосатын процестерге, мысалы, Git немесе Python процестеріне, қолданылмайды.
• Брандмауэрдің басқа сәйкестік өлшемдерінің де пішіні дұрыс болмады. Пайдаланушы ауқымындағы ережелер деңгейсіз құрылымда тек шектелген еншілес процеске ғана емес, Windows жүйесіндегі нақты пайдаланушыға да әлі де сәйкес келді. Бағдарлама жолына қатысты ережелер тым жалпылама болды: олар codex.exe немесе python.exe файлдарын жалпы түрде бұғаттай алатын, бірақ python.exe файлының оқшауланған ортадағы дәл осы бір іске қосылуын бұғаттай алмайтын. Портқа немесе мекенжайға негізделген ережелер де мүлде қате саясат болды. Мысалы, біз 443 портты бұғаттағымыз келген жоқ; біз осы нақты шектелген процестер ағашы үшін кез келген сыртқа бағытталған қолжетімділікті бұғаттағымыз келді.

Брандмауэр ережесін нақты біздің оқшауланған командаларымызға қолдану үшін, оларды «нақты» пайдаланушы ретінде емес, бөлек қауіпсіздік субъектісі ретінде іске қосуымыз қажет болды. Бұл тәсіл бізді жаңа бағытқа алып келді, бұл бағытта біз «жоғарылатпау» шектеуін жұмсарттық.

Біздің қазіргі іске асыру нұсқамыз болып табылатын оқшауланған ортаның келесі итерациясын орнату кезінде жоғарылатылған әкімші рұқсаттарын талап етеді. Сондықтан мен оны «жоғарылатылған оқшауланған орта» деп атаймын. Codex жүйеде пәрменді іске қосатын шекара тұсында, жоғарылатылған оқшауланған орта деңгейсізімен бірдей болып көрінеді. Ол әлі де еншілес процестерді шектеулі токенмен—сол сияқты write_restricted деген бірдей шектеулі SID тізімі бар [Everyone, Logon, Synthetic]—дегенмен бұл токеннің қауіпсіздік субъектісі енді нақты Windows пайдаланушысы емес, Codex өзі жасаған екі жергілікті пайдаланушының бірі болып табылады:

• CodexSandboxOffline (брандмауэр ережелері қолданылатын нұсқа)
• CodexSandboxOnline (брандмауэр ережелері қолданылмайтын нұсқа)

Бір қарағанда шағын деталь болып көрінетін бұл жайт шын мәнінде оқшауланған ортаға (sandbox), оны кім пайдалана алатынына, сондай-ақ оны баптау мен орындалу кезіндегі іске асыру күрделілігіне айтарлықтай әсер етеді.

Ол визуалды тұрғыдан деңгейсіз прототипке ұқсайды, оған брандмауэр ережелері мен командаларды іс жүзінде орындайтын арнайы Windows пайдаланушысы енгізілген. (Алайда, бұл жаңа ұғымдардың енгізілуі оқшауланған ортаға командаларды іске қосып, қорғауды бастамас бұрын көбірек баптау жұмысын орындау қажет екенін білдіреді.)

Деңгейсіз оқшауланған ортаның дизайнында бір қарапайым баптау қадамы болды, бірақ ол салыстырмалы түрде шағын еді:

• Қажет болса, синтетикалық SID жасаңыз
• Sandbox-write синтетикалық SID-і үшін ACL-дерді қолдану

Жоғарылатылған оқшауланған орта, алайда, атқаратын жұмыс әлі де көп.

• Егер әлі жасалмаған болса, синтетикалық SID жасаңыз
• Егер әлі жасалмаған болса, оқшауланған ортаның онлайн және офлайн пайдаланушыларын жасаңыз
• Жаңадан жасалған пайдаланушылардың тіркелгі деректерін жергілікті түрде сақтаңыз және оларды оқшауланған орта (sandbox) пайдаланушылары оқи алмайтын жерде Windows деректерді қорғау API-і (DPAPI) арқылы шифрлаңыз
• CodexSandboxOffline пайдаланушысы үшін барлық шығыс желілік қолжетімділікті бұғаттайтын брандмауэр ережелерін жасаңыз немесе олар бұрыннан бар болса, олардың дұрыстығын тексеріңіз

Орнату кезеңінде тағы бір күрделі тұс бар. Codex-тің оқшауланған ортасында нақты Windows пайдаланушысымен бірдей оқуға қол жеткізу құқығы болады деп күтіледі. Деңгейсіз оқшауланған орта ішінде, шектелген токеннің негізгі SID-і Windows пайдаланушысы болғанда, осыған қол жеткізілді. Дегенмен, принципал CodexSandbox жаңа пайдаланушысы болған кезде бұл тегін болмайды. Windows жүйесіндегі көптеген тиісті каталогтар «Аутентификацияланған пайдаланушыларға» оқу/орындау рұқсаттарын береді. Назар аударарлық бір мысал — пайдаланушы профилінің каталогы. Әдепкі бойынша, Windows пайдаланушылары басқа Windows пайдаланушыларының профиль каталогтарын оқи алмайды, сондықтан көптеген жағдайларда тіпті қарапайым файлды оқу әрекеттері де сәтсіз аяқталады.

Мұны шешу үшін оқшауланған ортаны орнату процесіне тағы бір қабат қостық — ол мұндай ACL рұқсаттары әлі болмауы мүмкін жерлерде оқшауланған орта пайдаланушыларына read ACL рұқсаттарын береді. Мысалы, жиі пайдаланылатын кейбір Windows каталогтарына:

• C:\Users\<нақты пайдаланушы>
• C:\Windows\
• C:\Program Files\
• C:\Program Files (x86)\
• C:\ProgramData\

Бұл каталогтар тізімі ең жақсы күш-жігерді сипатта болғандықтан және олардың әрқайсысына қатынасты басқару тізімдерін (ACL) орнату айтарлықтай қымбатқа түсуі мүмкін болғандықтан, біз бұл логиканы асинхронды түрде іске қосамыз, осылайша пайдаланушылар үшін бұғаттаушы болып табылатын оқшауланған ортаны орнату қадамы олардың аяқталуын күтпеуі керек.

Біз орнату логикасын жеке екілік файлға инкапсуляцияладық, бұл UAC шекарасынан тек қажет болған кезде ғана өту үшін жасалды. Алайда тереңірек себеп архитектуралық сипатта болды: оқшауланған ортаны орнатудың міндеті codex.exe бағдарламасының міндетінен түбегейлі өзгеше. Оқшауланған ортаны орнату логикасын арнайы екілік файлда сақтау codex.exe файлына қалыпты, деңгейсіз harness болып қалуға мүмкіндік берді; тек Windows-қа арналған орнату тетіктерінің басқа платформаларда codex.exe файлын қажетсіз үлкейтуіне жол бермеді; ұзаққа созылатын орнату жұмыстарын негізгі процестің өмірлік циклінен ажыратты; сондай-ақ оқшауланған ортаға қажет әртүрлі орнату жолдарын өңдеуге арналған бір ортақ орын берді.

Windows жүйесінде пайдаланушы мен токенге арналған жүйеге кіру шекараларының жұмыс істеу ерекшелігіне байланысты, біз деңгейсіз оқшауланған ортамен істей алғанымыздай, шектелген токен жасап, оның аясында процесті іске қосуды жалғастыра алмадық. Windows жүйесінің басқа пайдаланушысы ретінде пәрмендерді іс жүзінде іске қосу үшін, біздің алғашқы идеямыз мынадай реттілік болды:

• codex.exe нақты Windows пайдаланушысы ретінде іске қосылады. Содан кейін Codex ретімен мыналарды орындайды:
  • Оқшауланған (sandbox) ортадағы пайдаланушы үшін LogonUserW(...) функциясын шақырады.
  • Оқшауланған орта пайдаланушысының токенінде CreateRestrictedToken(...) функциясын шақырады.
  • Сол шектелген оқшауланған орта пайдаланушысының токенін пайдаланып, соңғы еншілес процесті іске қосу үшін CreateProcessAsUserW(...) шақырады.

Іс жүзінде, қалаған ағым CreateProcessAsUserW(...) шақыруындағы артықшылық кедергісіне байланысты жұмыс істемеді. Бұл codex.exe оқшауланған орта пайдаланушысы үшін шектеулі токен жасай алатынын, бірақ сол токенмен нақты пайдаланушы жағынан еншілес процесті сенімді түрде іске қоса алмайтынын білдіреді. Бізге оқшауланған орта пайдаланушысы ретінде жұмыс істеп тұрған процесс қажет болды — бұл шектеу қадамы мен соңғы іске қосудың нақты пайдаланушы жағында емес, оқшауланған орта пайдаланушысы жағында орындалуына мүмкіндік берер еді.

Осы талап codex-command-runner.exe жасауға алып келді. Бұл — жалғыз міндеті шектелген токен жасап, сұралған команданы іске қосу болатын жаңа екілік файл. codex.exe бүкіл ағынды өзі орындауын сұраудың орнына (нақты пайдаланушы → оқшауланған орта пайдаланушысы → шектеулі токен → еншілес процесс), біз ағынды екіге бөлдік:

1-бөлім

• codex.exe codex-command-runner.exe файлын оқшауланған (sandbox) ортаның пайдаланушысы ретінде іске қосу үшін CreateProcessWithLogonW(...) функциясын шақырады, әзірге шектелген токенді пайдаланбайды.

2-бөлім

• Орындаушы ішінде OpenProcessToken(GetCurrentProcess(), ...) өзінің токенін ашады, ол бұрыннан оқшауланған орта пайдаланушысына тиесілі.
• Орындаушы оқшауланған ортаға кіру SID-ін анықтау үшін GetTokenInformation(...) функциясын, ал соңғы шектелген токенді жасау үшін CreateRestrictedToken(...) функциясын қолданады.
• Әлі де орындаушының ішінде, ол нақты еншілес процесті іске қосу үшін сол шектелген токенмен CreateProcessAsUserW(...) функциясын шақырады.

Альберт Эйнштейн: «Әр нәрсе мүмкіндігінше қарапайым болуы керек, бірақ одан артық қарапайымдатылмауы тиіс», — деген. Осы ұстанымға сай, дизайнымыз әрбір мәселені тиісті деңгейде шешті. Соңғы архитектура бұрын қарастырған төрт қабаттан тұрады:

• codex.exe файлының өзі
• codex-windows-sandbox-setup.exe барлық жоғарылатылған орнату жұмыстарына арналған
• codex-command-runner.exe — шектелген токен командаларын орындауға арналған
• Еншілес процесс

Бұл жобаға алғаш кіріскенімде, оның немен аяқталатынын нақты елестете алмадым. Менің тәсілім Codex пен операциялық жүйе арасындағы шекарада оқшаулау мүмкіндігін бақылау тетіктерін енгізуден басталды. Бұл тәсіл Codex-тің оқшауланған ортасының macOS және Linux жүйелерінде іске асырылу тәсіліне өте ұқсас.

Windows ұсынатын нақты құралдар туралы көбірек білген сайын және қауіпсіздік пен пайдаланудың қарапайымдылығы арасындағы тепе-теңдікті сақтауға бағытталған ондаған шешімдердің нәтижесінде жүйе қазіргі түріне дейін дамыды: бірнеше екілік файлдар, арнайы пайдаланушылар, брандмауэр ережелері, жоғарылатылған орындалатын орнату қадамы, асинхронды процестер және тағы басқалар.

Бұл аса қарапайым жүйе емес, бірақ қауіпсіз әрі пайдаланушының жұмысына мүмкіндігінше кедергі келтірмейтін оқшауланған орта құру үшін күрделіліктің әрбір элементі қажеттіліктен қосылған.

Windows жүйесіндегі Codex пайдаланушылары үшін жақсы пайдаланушы тәжірибесін ұсыну жолында жұмыс істей отырып, мақсатымыз пайдалылығын төмендетпейтін қауіпсіз шешім жасау болды — өйткені Codex-ті пайдаланудың басты мәні агенттердің сіздің тұрақты назарыңызсыз жұмыс істей алуында.

Бұл жобадан алынған ең маңызды сабақтардың бірі — Windows бізге «қауіпсіз автономды кодтау агенті» ұғымына дәл сәйкес келетін бірде-бір негізгі элемент ұсынбады. Біз бірнеше құрал мен ұғымды біріктіріп, тұтас әрі үйлесімді нәрсе жасадық. Алғашқы идеялардың кейбірі болашағы жоқ болып шықты. Соңғы дизайн мәселенің бір бөлігін шешкен бұрынғы прототиптердің гибриді болды.

Тағы бір сабақ — кодтау агентінің қауіпсіздігі классикалық қосымша қауіпсіздігінен өзгеше мәселе. Codex нақты әзірлеуші жұмыс процестері үшін жұмыс істеуі керек. Инженерлік жұмыс агенттерге негізделген жұмыс жүктемелерімен үйлесімділік пен нақты орындату арасындағы тепе-теңдікті табуға арналды. Сол шиеленіс қорытынды дизайндағы ымыралы шешімдерді қалыптастырды.

Codex-тің оқшауланған ортасының қалай жұмыс істейтінін көргіңіз келе ме? Қолданып көріңіз⁠.