Windows дээр Codex-ийг идэвхжүүлэхийн тулд аюулгүй, үр дүнтэй sandbox үүсгэх

Намайг 2025 оны 9 сард Codex инженерийн багт элсэхэд Windows-д зориулсан Codex нь sandbox хэрэгжилтгүй байсан бөгөөд энэ нь Windows хэрэглэгчид OpenAI-н код бичих агентуудыг ашиглахдаа хоёр муу сонголтын аль нэгийг сонгохоос өөр аргагүй болсон гэсэн үг юм:

1. Код бичих агентын ажиллуулахыг хүссэн бараг бүх командыг (бүр уншдаг) батлах нь үр ашиггүй бөгөөд залхуутай. Codex-г ашиглахын нэг том давуу тал нь бүх уйтгартай ажлыг өөрөө хийх шаардлагагүй байдаг.
2. Бүрэн хандалтын горимыг идэвхжүүлэх: Codex-д бүх командыг зөвшөөрөл, хязгаарлалтгүйгээр ажиллуулах боломж олгох бөгөөд энэ нь хяналтыг сулруулж, саад бэрхшээлийг арилгадаг.

Манай код бичих агент Codex⁠ нь CLI, IDE өргөтгөл эсвэл дэлгэцийн аппын аль аль нь хөгжүүлэгчийн зөөврийн компьютер дээр шууд ажилладаг. Энэ нь компьютерийн гар дээрх хүн болон үүлэн орчинд ажиллаж буй загварын хоорондох харилцааг зохицуулж, дүгнэлтийг боловсруулдаг.

Codex нь анхдагчаар жинхэнэ хэрэглэгчийн зөвшөөрлөөр ажилладаг бөгөөд энэ нь хэрэглэгчийн хийж чадах бүх зүйлийг хийж чадна гэсэн үг юм. Энэ нь хүчирхэг бөгөөд магадгүй аюултай. Кодлох загвар нь бэхэлгээнд тест ажиллуулахаас эхлээд файл унших эсвэл засварлах, Git салбар үүсгэх хүртэлх командуудыг орон нутагт ажиллуулахыг хэлж өгч болох тул Codex-ийн анхдагч горим нь үр ашиг ба аюулгүй байдлын хоорондох зөв тэнцвэрийг олохыг оролддог. Энэ анхдагч горим нь Codex-д бараг хаана ч файл унших, таны ажлын талбарт (өөрөөр хэлбэл таны Codex ажиллаж байгаа сан дотор) файл бичих боломжийг олгодог бөгөөд хэрэв та үүнийг хүсэж байгаагаа заагаагүй бол интернетэд холбогдох шаардлагагүй. Аюулгүй хязгаарт файл бичих, сүлжээнд нэвтрэх энэхүү автомат хязгаарлалтыг хэрэгжүүлэхийн тулд Codex нь эдгээр хязгаарлалтыг үнэхээр хэрэгжүүлдэг хамгаалагдсан орчны орчинтой байх шаардлагатай.

Sandbox нь хязгаарлагдмал гүйцэтгэлийн орчин юм. Хөгжүүлэгч Codex ашиглах үед тэдний компьютерын үйлдлийн систем нь хязгаарлагдмал эрхтэй командыг ажиллуулдаг бөгөөд эдгээр хязгаарлалтууд нь процессын модоор дамжин тархдаг. Codex команд бүр эхнээсээ л хамгаалагдсан байдаг бөгөөд дараагийн процесс бүр ижил хил хязгаар дотор үлддэг.

Codex нь үр дүнтэй sandbox хэрэгжүүлэхийн тулд компьютерын үйлдлийн системээр хэрэгжсэн тусгаарлах функцуудыг шаарддаг. Зарим үйлдлийн системүүд үүнийг сайн хийдэг хэрэгслүүдийг хангадаг (жишээ нь, MacOs дээрх Seatblown, Linux дээрх seccomp эсвэл bubblewrap); Гэсэн хэдий ч Windows одоогоор энэ төрлийн боломжийг шууд хангадаггүй.

Codex-ийг бусад газар байгаа шигээ Windows дээр ашиглахад аюулгүй, тааламжтай болгохын тулд бид өөрсдийн sandbox-оо хэрэгжүүлэх шаардлагатай байсан.

Windows нь тусгаарлах зарим хэрэгсэл болон энгийн зүйлсийг санал болгодог. ᠲᠡᠳᠡᠭᠡᠷ ᠦᠨ ᠠᠯᠢ ᠨᠢ ᠴᠤ ᠪᠢᠳᠡᠨ ᠦ ᠱᠠᠭᠠᠷᠳᠠᠯᠭ᠎ᠠ ᠶᠢ ᠪᠦᠷᠢᠨ ᠬᠠᠩᠭᠠᠭ᠎ᠠ ᠦᠭᠡᠢ ᠪᠣᠯᠪᠠᠴᠤ᠂ ᠪᠢᠳᠡ ᠬᠡᠳᠦ ᠬᠡᠳᠦᠨ ᠪᠣᠯᠣᠮᠵᠢᠲᠤ ᠰᠢᠢᠳᠦᠯ ᠢ ᠠᠪᠴᠤ ᠦᠵᠡᠭᠰᠡᠨ — ᠲᠤᠬᠠᠶᠢᠯᠠᠪᠠᠯ AppContainer᠂ Windows Sandbox ᠪᠣᠯᠤᠨ Mandatory Integrity Control ᠱᠣᠰᠢᠭᠠᠯᠠᠯ᠃

АппКонтейнер

• Юу: AppContainer бол Windows-ийн уугуул sandbox бөгөөд юунд хандах шаардлагатайгаа урьдчилан мэддэг аппликейшнуудад зориулан бүтээгдсэн чадамжид суурилсан тусгаарлах загвар юм.
• Яагаад: Хамгийн сайн хүчин чармайлтын хязгаарлалтын оронд жинхэнэ үйлдлийн системийн хил хязгаарыг санал болгодог тул сэтгэл татам.
• Яагаад болохгүй гэж: Codex бол нягт хамрах хүрээтэй апп биш. Энэ нь урьдчилан хязгаарлагдаагүй хөгжүүлэгчийн ажлын урсгалуудыг ажиллуулдаг: shell-үүд, Git, Python, багцын менежерүүд, бүтээх хэрэгслүүд болон агент өөрт хэрэгтэй гэж шийдсэн бусад ямар ч хоёртын гүйцэтгэх файлууд. Практикт энэ нь AppContainer-ийг тухайн асуудалд тохиромжгүй хэлбэртэй болгосон. Энэ нь хүчтэй тусгаарлалт байсан ч "агентыг хөгжүүлэгч шиг ажиллуулах"-аас хамаагүй нарийвчилсан ажлын ачааллын ангилалд зориулагдсан байв.

Windows-н Sandbox

• Юу: Windows Sandbox бол Microsoft-ын нэг удаагийн хөнгөн жинтэй виртуал машин юм. Та хүчтэй тусгаарлах хил хязгаартай шинэ Windows ширээний компьютер авах бөгөөд дотор нь хийсэн бүх зүйл сесс дуусахад алга болно.
• Яагаад: Тодорхой шалтгааны улмаас сонирхолтой - AppContainer-ээс дурын програм хангамжтай хамаагүй илүү нийцтэй бөгөөд аюулгүй байдлын үүднээс авч үзвэл илүү хүчирхэг хайрцаг юм.
• Яагаад болохгүй гэж: Codex нь тохиргоо болон хост/зочин хоорондын гүүр шаардлагатай тусдаа ширээний компьютерт биш, харин хэрэглэгчийн бодит төлбөр тооцоо, хэрэгслүүд болон орчинд шууд нөлөөлөх шаардлагатай. Мөн бүтээгдэхүүний үндсэн асуудалтай байсан: Windows Sandbox нь Windows Home SKU дээр ч байхгүй.

Заавал биелүүлэх бүрэн бүтэн байдлын хяналт (MIC) бүрэн бүтэн байдлын шошгололт

• Юу: Windows нь систем нь объект болон процессуудад хэр их итгэдэгийг тодорхойлдог бага, дунд, өндөр гэх мэт "бүрэн бүтэн байдлын түвшин" гэсэн ойлголттой байдаг. Үндсэн дүрэм бол хэвийн ACL үүнийг зөвшөөрсөн байсан ч гэсэн бүрэн бүтэн байдал багатай процесс нь илүү өндөр бүрэн бүтэн байдлын түвшинтэй объект руу бичиж чадахгүй. Жишээлбэл, бүрэн бүтэн байдал багатай процессыг бага итгэл үнэмшилтэй гэж үздэг тул Windows нь ердийн дунд бүрэн бүтэн байдлын объектууд руу бичихийг хориглодог, хэрэв эдгээр объектуудыг үүнийг зөвшөөрөхийн тулд шууд дахин шошголоогүй бол.
• Яагаад: MIC цаасан дээр гоёмсог харагдаж байсан - Codex-ийг бүрэн бүтэн байдал багатай ажиллуулж, бичих боломжтой үндсэн кодуудыг бүрэн бүтэн байдал багатай гэж дахин тэмдэглэж, Windows-ийг бусад газарт бичихгүй байхыг хэрэгжүүлэхийг зөвшөөрсөн. Энэ нь бидэнд жинхэнэ үйлдлийн системийн механизмтай админ бус замыг өгөх байсан.
• Яагаад болохгүй гэж: ACL-үүдийн нэгэн адил бүрэн бүтэн байдлын шошго нь жинхэнэ хост файлын системийг өөрчилдөг бөгөөд энэ тохиолдолд семантик өөрчлөлт нь ялангуяа өргөн хүрээтэй байдаг. Ажлын талбарыг бүрэн бүтэн байдал багатай гэж тэмдэглэх нь зүгээр л "Codex энд бичиж болно" гэсэн үг биш юм. Энэ нь ерөнхийдөө бүрэн бүтэн байдал багатай процессууд тэнд бичиж чадах гэсэн үг юм. Жинхэнэ хөгжүүлэгч машин дээр энэ нь хэрэглэгчийн бодит төлбөрийг хостын хувьд бага бүрэн бүтэн байдлын угаалтуур болгон хувиргадаг бөгөөд энэ нь нэг хамгаалагдсан хязгаарлагдмал орчинд сайтар чиглүүлсэн ACL-үүдийг өгөхөөс хамаагүй эрсдэлтэй юм. Хэдийгээр дунд түвшний бүрэн бүтэн байдлын хөгжүүлэгчийн хэрэгслүүд үргэлжлэн ажилласаар байж болох ч ажлын талбарын суурь итгэлцлийн загвар хянаж барихад хэцүү, зөвтгөхөд бүр ч хэцүү байдлаар өөрчлөгдсөн.

Бүх сонголтыг эхлэл биш гэж үнэлсний дараа бид Windows хэрэглэгчдэд Codex-ийн сайн туршлагыг авчрахын тулд өөрсдийн шийдлийг боловсруулж эхэлсэн.

Бидний анхны ажиллаж буй туршилтын загвар нь бидэнд шаардлагатай тусгаарлалтыг хэрэгжүүлэхийн тулд Windows-ийн концепц болон хэрэгслүүдийн хослолыг ашигласан. Эхнээсээ нэг зорилго нь үүнийг elevation шаарддаггүйгээр ажиллуулах явдал байсан бөгөөд энэ нь Codex нь зөвхөн sandbox-г тохируулах эсвэл ажиллуулахын тулд хэрэглэгчээс администраторын эрх хүсэх шаардлагагүй гэсэн үг юм. Энэ нь хоёр зүйлд зохистой хязгаар тогтоох аргыг олох хэрэгтэй гэсэн үг байв: файлд бичих болон сүлжээнд хандах.

Хэрэв бид файл бичихийг огт хязгаарлаагүй бол аюулгүй байдлын асуудал гарах байсан. Хэрэв бид файл бичих хугацааг хэт их хязгаарлавал хамгаалагдсан хязгаарлагдмал орчин нь хэрэглэгчийн бүтээмжид сөргөөр нөлөөлж, байнга зөвшөөрөл авах шаардлагатай болно. Энэ асуудлыг шийдэхийн тулд бид Windows-ийн хоёр чухал бүтцийн блок дээр тулгуурласан: SID болон бичих хязгаарлагдмал токенууд.

SID буюу аюулгүй байдлын танигч нь Windows-н зөвшөөрлүүдийг холбогч таних тэмдэг юм. Хэрэглэгч бүр SID-тэй, бүлгүүд SID-тэй байдаг бөгөөд нэг удаагийн нэвтрэх хандалт хүртэл өөрийн гэсэн SID-тэй байдаг. Жишээлбэл, одоогийн нэвтэрсэн хандалт нь S-1-5-5-XY гэх мэт SID-тэй байж болно. Дотоод администраторуудын бүлэгт оноосон SID нь S-1-5-32-544 байж болно.

Windows нь танд жинхэнэ хэрэглэгчтэй тохирохгүй боловч хэн тодорхой файл эсвэл санг уншиж/бичих/гүйцэтгэж болохыг тодорхойлдог ACL (хандалтын хяналтын жагсаалт)-д гарч ирэх боломжтой синтетик SID-үүдийг үүсгэх боломжийг олгодог. Энэ нь SID-үүдийг бидний хамгаалагдсан хязгаарлагдмал орчинд хэрэгтэй энгийн зүйл болгодог: бид машин дээрх бусад зүйлд саад учруулахгүйгээр зөвхөн Codex хамгаалагдсан хязгаарлагдмал орчинд ашиглах SID-үүдийг үүсгэж чадна.

Процессын токен нь ажиллаж буй процессын таних мэдээлэл болон эрхийг тодорхойлдог Windows дахь аюулгүй байдлын объект юм. Тэд процесс ямар үйлдлийг гүйцэтгэж болохыг тодорхойлдог. бичих эрхийг хязгаарласан токен нь Windows-ээр бичих үйлдлүүд дээр хандалтын нэмэлт шалгалт хийлгэдэг процессын токены тодорхой нэг төрөл юм.

Бичих ажил амжилттай болохын тулд хоёр шалгалтыг давах ёстой:

1. Энгийн хэрэглэгчийн таних тэмдэг (токен "эзэмшигч") үүнийг хийхийг зөвшөөрөх ёстой
2. Токенын хязгаарлагдмал SID жагсаалтад байгаа дор хаяж нэг SID-д хандах эрх олгох ёстой

Практикт эдгээр шалгалтууд нь бидэнд ACL-үүдийг ашиглан хамгаалагдсан хязгаарлагдмал орчин файлын системийг яг хаана өөрчилж болохыг тодорхойлох боломжийг олгодог бөгөөд энэ нь бичих үйлдлүүдийн талаар бидэнд шаардлагатай нарийн ширийн зүйлийг санал болгодог.

SIDs болон бичих эрх хязгаарлагдсан токенуудтай үед манай эрх дээшлүүлээгүй сэндбокс ингэж ажилладаг байсан:

1. sandbox тохиргоо нь sandbox-write гэж нэрлэгддэг синтетик SID үүсгэсэн.
2. sandbox-write SID-д бичих, гүйцэтгэх болон устгах эрх олгосон
   1. Одоо ажиллаж буй лавлах
   2. config.toml файлд тохируулсан нэмэлт writable_roots.
3. Sandbox тохиргоо нь дараах зэрэг «зөвхөн унших боломжтой» байршлууд руу SID бичих хандалтыг шууд хориглосон:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex нь Everyone, одоогийн нэвтэрсэн сессийн SID болон sandbox-write синтетик SID-ыг агуулсан хязгаарлагдмал SID жагсаалттай, бичих эрхээр хязгаарлагдсан токеноор командуудыг ажиллуулсан.

Энэ урсгал нь файл бичих хязгаарлалтыг үр дүнтэйгээр шийдвэрлэсэн бөгөөд ирээдүйтэй мэт санагдаж байв. Одоо бидэнд хамгаалагдсан хязгаарлагдмал орчны сүлжээний хандалтыг хязгаарлах шийдэл хэрэгтэй байсан.

Сүлжээний хандалтыг хязгаарлах нь хамгаалагдсан хязгаарлах системийн чухал хэсэг юм; үүнгүйгээр хортой код нь машинаас интернет рүү өгөгдлийг шүүрч авах боломжтой. Бид өндрийн шаардлагаас зайлсхийхийг хүссэн тул сүлжээний урсгалыг хүчтэй хаах хязгаарлагдмал сонголттой байсан. Windows Firewall гэх мэт бидний ашиглахыг хүссэн хэрэгслүүдийг ерөнхийдөө админы зөвшөөрөлгүйгээр суулгах боломжгүй байсан.

Windows Firewall сонголтгүйгээр бид хянах боломжтой зүйлсээ хязгаарласан. Хөгжүүлэгчдийн бодитоор ашигладаг сүлжээнд холбогддог хэрэгслийн төрлүүдийн хувьд дэд орчныг алдаа гарвал хаалттай төлөвт үлдэхээр болгохыг бид оролдсон. Ингэснээр Git командууд, багц суулгагчид гэх мэт нь sandbox дотор амжилтгүй болж, хэрэглэгч интернет рүү чиглэсэн аливаа үйлдлийг зөвшөөрөх шаардлагатай болно. Санаа нь илэрхий тойрох гарцуудыг хордуулах явдал байв: проксиг харгалздаг траффикийг ажиллахгүй эцсийн цэг рүү илгээж, Git-ийн HTTP(S) дамжуулалтаар ч мөн адил хийлгэж, SSH-ээр дамжих Git-ийг шууд алдаатай болгох. Үүнээс гадна бид жижиг denybin санг PATH-д нэмж, stub SSH болон SCP скриптүүд жинхэнэ хоёртын файлуудаас өмнө шийдэгдэхийн тулд PATHEXT дахин дараалуулсан.

Жишээлбэл, сүлжээний хандалтыг хязгаарлахад бидний ашигласан зарим тодорхой орчны дарж тохируулгууд энд байна:

• 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 exit 1

Энэ нь багаж хэрэгслээр удирдуулсан ердийн урсгалыг их хэмжээгээр татсан боловч энэ нь зөвхөн зөвлөгөө өгөх шинж чанартай хэвээр байв. Аливаа процесс орчныг үл тоомсорлож, PATH-г тойрч гарах эсвэл сокетуудыг шууд нээж болзошгүй—энэ нь хэтэрхий эрсдэлтэй.

Бусад сонирхолтой програм хангамжийн нэгэн адил анхны загвар нь давуу болон сул талуудтай байсан. Энэ нь Windows-н цөөн хэдэн стандарт боломжуудыг ашиглан ажлаа хийж, маш тодорхой, нарийвчилсан файлын системд бичих боломжийг олгосноос гадна администратор эрхгүйгээр ажилласан—ингэснээр хэрэглэгчид хэт олон эрх нэмэгдүүлэх өгөгдлийг хүлээн авах эсвэл дотоод машин дээрээ админ байх шаардлагыг багасгасан—гэхдээ эцсийн загвар болгоход саад болсон хэд хэдэн бодит сул талуудтай байсан:

• Тохиргооны хурд: Ажлын талбарын ACL-г ашиглах нь ажлын талбарын сангийн топологиос хамааран үнэтэй байж болно.
• Ул мөр: Бид хөгжүүлэгчийн системд жинхэнэ ACL-үүдийг хэрэглэсэн боловч бүх хэрэглэсэн ACL-үүд нь зөвхөн хамгаалагдсан орчинд ашиглагддаг захиалгаар үүсгэсэн синтетик SID-тэй холбоотой тул ул мөр нь тийм ч их биш юм.
• Өөрчлөхөд хэцүү семантик: Файл дээр суурилсан хязгаарлалтуудад ACL-үүдээс хамааралтай байх нь хамгаалагдсан орчны семантикийг өөрчлөхөд үнэтэй бөгөөд төвөгтэй гэсэн үг юм. macOS дээр бид .sbpl файлыг хэрхэн үүсгэхээ динамикаар өөрчилж чадна. Суудлын бүсийг тохируулахад ашигладаг файлаас харахад Windows-ийн хамгаалагдсан хязгаарлагдмал орчин нь ACL-г тохируулахын тулд удаан бөгөөд эрчимтэй ажиллагаа шаардаж магадгүй юм.
• Сүлжээний хамгаалалт сул байна. Өмнө дурдсанчлан, энэ нь "зөвлөгөө" байсан бөгөөд өөрийн сүлжээний стекийг хэрэгжүүлсэн зарим програмууд үүнийг тойрч гарах нь гарцаагүй бөгөөд өрсөлдөгч кодыг тэсвэрлэх зориулалттай биш байв.

Эхний гурван асуудал нь агентын урсгалд хангалттай уян хатан байдаг өөрчлөн тохируулсан sandbox хэрэгжүүлэлттэй холбоотой юм. Гэхдээ сүлжээг дарах түүх өөр байсан.

Хортой агент нь хүрээлэн буй орчинд суурилсан сүлжээний даралтыг амархан тойрч гарах чадвартайгаас гадна олон сайн санаатай код/хоёртын файлууд нь орчны прокси хувьсагчдыг хүндэтгэхгүй эсвэл өөрсдийн сокет дээр суурилсан сүлжээний кодыг хэрэгжүүлсэн тохиолдолд үүнийг тойрч гарах болно. Энэ тал нь илүү сайн хамгаалагдсан хязгаарлагдмал орчинд хөрөнгө оруулах талаар бодоход хангалттай гэж бид үзсэн.

Сүлжээний даралтыг сайжруулахын тулд бид хэрэглэгчид эсвэл програмуудын гадагш чиглэсэн сүлжээний урсгалыг хаах боломжийг олгодог Windows Firewall ашиглахыг хүссэн. Харамсалтай нь бид хэд хэдэн шалтгааны улмаас зөвхөн Codex-ийн үүсгэсэн командуудад хамаарах функциональ галт ханын дүрмийг үр дүнтэй үүсгэж чадаагүй:

• Windows нь галт ханын дүрмийг хязгаарлагдмал токены үндсэн бус таних тэмдэгтэй тохируулахыг зөвшөөрдөггүй. Энэ нь бид "хязгаарлагдмал SID жагсаалтад маань синтетик SID агуулсан аливаа токен"-д галт ханын дүрмийг хэрэглэж болохгүй гэсэн үг юм.
• Бид тодорхой хоёртын файлтай тохирох галт ханын дүрмийг үүсгэж болох ч энэ нь зөвхөн codex.exe файлын өөрийнх нь сүлжээг хязгаарлах боломжийг олгодог. Энэ нь Git эсвэл Python процессууд гэх мэт хэрэглэгчийн өмнөөс агент үүсгэдэг процессуудад хамаарахгүй.
• Бусад галт ханын хэмжээсүүд нь бас буруу хэлбэртэй байсан. Хэрэглэгчийн хүрээтэй дүрмүүд нь зөвхөн хязгаарлагдмал хүүхэдтэй төдийгүй, өөрчлөгдөөгүй загварт жинхэнэ Windows хэрэглэгчтэй таарч байсан. Програмын замын дүрмүүд хэтэрхий бүдүүлэг байсан: тэдгээр нь codex.exe эсвэл python.exe ерөнхийдөө хааж болох байсан ч python.exe файлын энэ удаагийн хамгаалалтын горимд дуудахыг хориглож байсан. Порт эсвэл хаягт суурилсан дүрэм нь бүрэн буруу бодлого байсан. Жишээлбэл, бид 443 дугаар портыг хаахыг хүсээгүй; харин энэ тодорхой хязгаарлагдсан процессийн модны гадагш чиглэсэн бүх хандалтыг хаахыг хүссэн.

Галт ханын дүрмийг тусгайлан хамгаалагдсан хамгаалалтын командууддаа хэрэгжүүлэхийн тулд бид тэдгээрийг "жинхэнэ" хэрэглэгч биш харин тусдаа удирдагч болгон ажиллуулах шаардлагатай байсан. Энэ арга барил биднийг шинэ зам руу хөтөлсөн бөгөөд энэ замаар бид "дээшлэхгүй" гэсэн хязгаарлалтаа сулруулсан.

Бидний одоогийн хэрэгжүүлэлт болох sandbox-н дараагийн хувилбар нь тохируулах үед администратор эрх шаарддаг. Тиймээс би үүнийг “администратор эрхтэй sandbox” гэж нэрлэдэг. Codex систем дээр командыг ажиллуулдаг зааг дээр администратор эрхтэй sandbox, администратор эрхгүй sandbox шиг харагддаг. Энэ нь дэд процессуудыг хязгаарлагдсан токен дор ажиллуулдаг хэвээр байна—үүнтэй адил write_restricted токен нь [Everyone, Logon, Synthetic]гэсэн ижил хязгаарлагдсан SID жагсаалттай—гэхдээ энэ токены үндсэн хэрэглэгч нь одоо жинхэнэ Windows хэрэглэгч биш, харин Codex өөрөө үүсгэсэн хоёр дотоод хэрэглэгчийн нэг юм:

• CodexSandboxOffline (гал ханын дүрмээр онилогдсон)
• CodexSandboxOnline (гал ханын дүрмээр зорилтот бус)

Энэхүү жижиг мэт санагдах нарийн ширийн зүйл нь үнэндээ хамгаалагдсан хязгаарлагдмал орчин, хэн үүнийг ашиглаж болох, тохиргоо болон ажиллах хугацааны гүйцэтгэлийн нарийн төвөгтэй байдалд томоохон нөлөө үзүүлдэг.

Энэ нь галт ханын дүрмүүд болон тусгай Windows хэрэглэгчийн оруулсан тушаалуудыг ажиллуулдаг тул харааны хувьд сайжруулаагүй туршилтын загвартай төстэй юм. (Гэсэн хэдий ч эдгээр шинэ ойлголтуудыг нэвтрүүлснээр sandbox ажиллаж эхлэхээс өмнө хийх шаардлагатай тохиргооны ажил их байна гэсэн үг юм.)

Дээврийн давхаргагүй хамгаалагдсан хайрцгийн загвар нь энгийн тохиргооны алхамтай байсан ч харьцангуй бага байв:

• Шаардлагатай бол синтетик SID үүсгэнэ үү
• ACL-үүдийг sandbox-write синтетик SID-д ашиглах

Гэсэн хэдий ч өндөрлөг газрын элс хадгалах хайрцагт хийх зүйл их байна.

• Хэрэв аль хэдийн үүсгээгүй бол синтетик SID үүсгэнэ үү
• Хэрэв өмнө нь үүсгээгүй бол онлайн болон офлайн sandbox хэрэглэгчдийг үүсгэх
• Шинээр үүсгэсэн хэрэглэгчдийн итгэмжлэлийг орон нутагт хадгалж, Windows Data Protection API (DPAPI) ашиглан хамгаалагдсан хязгаарлагдмал орчинд хэрэглэгчид уншиж чадахгүй газар шифрлэнэ үү.
• CodexSandboxOffline хэрэглэгчийн бүх гадагш чиглэсэн сүлжээний хандалтыг хаах галт ханын дүрмийг үүсгэх эсвэл хэрэв тэдгээр нь аль хэдийн байгаа бол тэдгээрийн зөв эсэхийг баталгаажуулах

Суурилуулалтын шатанд нэмэлт асуудал гарч ирдэг. Codex-ын sandbox нь Windows-ийн бодит хэрэглэгчтэй тэнцэх хэмжээний унших хандалттай байх төлөвтэй байна. Хязгаарлагдмал токены үндсэн SID нь Windows хэрэглэгч байсан түвшний өөрчлөлтгүй хамгаалагдсан орчинд үүнийг биелүүлсэн. Гэсэн хэдий ч, үндсэн хэрэглэгч CodexSandbox шинэ хэрэглэгч болоход энэ нь үнэгүй ирдэггүй. Windows дээрх олон холбогдох сангууд нь "Баталгаажсан хэрэглэгчид"-д унших/гүйцэтгэх зөвшөөрөл олгоно. Үүний нэг тод жишээ бол хэрэглэгчийн профайлын лавлах юм. Анхдагчаар Windows хэрэглэгчид бусад Windows хэрэглэгчдийн профайлын санг уншиж чадахгүй тул олон тохиолдолд энгийн файл унших нь ч амжилтгүй болно.

Үүнийг шийдвэрлэхийн тулд бид sandbox тохиргооны процесст өөр нэг давхарга нэмсэн бөгөөд энэ нь sandbox хэрэглэгчдэд унших ACL-үүд аль хэдийн байхгүй байж болох давхаргад унших ACL-үүдийг олгох давхарга юм. Жишээлбэл, зарим түгээмэл хэрэглэгддэг Windows сангууд руу:

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

Энэ лавлахын жагсаалт нь хамгийн сайн хүчин чармайлт бөгөөд ACL-үүдийг тус бүр дээр суулгах нь нэлээд үнэтэй байж болох тул бид энэ логикийг асинхрон байдлаар ажиллуулдаг тул хэрэглэгчдийг хааж буй хамгаалагдсан хязгаарлагдмал орчны тохиргооны алхам нь тэднийг дуусахыг хүлээх шаардлагагүй болно.

Бид тохиргооны логикийг зөвхөн шаардлагатай үед UAC хил хязгаарыг давахын тулд өөрийн хоёртын файлд хэсэгчлэн оруулсан. Гэхдээ илүү гүнзгий шалтгаан нь архитектурт байсан: sandbox тохиргоо нь codex.exe ээс үндсээрээ өөр ажилтай. Sandbox тохиргооны логикийг зориулалтын хоёртын файлд хадгалснаар codex.exe хэвийн, ямар ч түвшинд байлгаж, зөвхөн Windows дээр суурилсан тохиргооны машиныг бусад платформууд дээр codex.exe гацахаас сэргийлж, удаан хугацаанд ажиллаж байсан тохиргооны ажлыг үндсэн процессын ашиглалтын хугацаанаас салгаж, бидэнд sandbox-д шаардлагатай өөр өөр тохиргооны замуудыг зохицуулах нэг газрыг олгосон.

Windows хэрэглэгчийн болон токен нэвтрэх хил хязгаар хэрхэн ажилладагаас шалтгаалан бид хязгаарлагдмал токен үүсгэж, түүний доор процессыг өргөтгөхгүй sandbox-той адил ажиллуулж чадаагүй. Өөр Windows хэрэглэгчийн нэрээр командуудыг ажиллуулахын тулд бидний анхны санаа бол дараах урсгал байсан:

• codex.exe жинхэнэ Windows хэрэглэгчийн нэрээр ажилладаг. Дараа нь, дарааллаар нь Codex:
  • sandbox хэрэглэгчийн хувьд LogonUserW(...) функцийг дууддаг.
  • Тухайн sandbox-user токен дээр CreateRestrictedToken(...) функцийг дууддаг.
  • Хязгаарлагдмал хамгаалагдсан хязгаарлагдмал орчинд ажилладаг хэрэглэгчийн токеныг ашиглан CreateProcessAsUserW(...) -г дуудаж, эцсийн хүүхдийг ажиллуулна.

Практикт хүссэн урсгал нь CreateProcessAsUserW(...) дээрх давуу эрхийн хананаас болж ажиллаагүй. Энэ нь codex.exe sandbox хэрэглэгчийн хувьд хязгаарлагдмал токен үүсгэж чадна гэсэн үг боловч хил хязгаарын бодит хэрэглэгчийн талаас уг токентой хүүхдийг найдвартай ажиллуулж чадахгүй гэсэн үг юм. Бидэнд аль хэдийн хамгаалагдсан хязгаарын хэрэглэгчийн талд ажиллаж байсан процесс хэрэгтэй байсан бөгөөд энэ нь хязгаарлалтын алхам болон эцсийн үүсэлтийг бодит хэрэглэгчийн талд биш харин хилийн хамгаалагдсан хязгаарын хэрэглэгчийн талд хийх боломжийг олгоно.

Энэ шаардлага нь хязгаарлагдмал токен үүсгэж, хүссэн командыг ажиллуулах цорын ганц үүрэгтэй шинэ хоёртын файл болох codex-command-runner.exe г бий болгосон. codex.exe бүх урсгалыг өөрөө хийхийг хүсэхийн оронд (жинхэнэ хэрэглэгч → sandbox хэрэглэгч → хязгаарлагдмал токен → хүүхдийн процесс) бид урсгалыг хоёр хуваадаг:

1-р хэсэг

• codex.exe хязгаарлагдмал токен ашиглалгүйгээр codex-command-runner.exe sandbox хэрэглэгчээр ажиллуулахын тулд CreateProcessWithLogonW(...) -г дууддаг.

2-р хэсэг

• Runner дотор OpenProcessToken(GetCurrentProcess(), ...) runner-ийн өөрийн токеныг нээдэг бөгөөд энэ нь аль хэдийн sandbox хэрэглэгчийн мэдэлд байдаг.
• Ажиллуулагч нь sandbox нэвтрэх SID-г гаргаж авахын тулд GetTokenInformation(...) г дуудаж, дараа нь эцсийн хязгаарлагдмал токеныг үүсгэхийн тулд CreateRestrictedToken(...) дууддаг.
• Runner дотор байгаа ч гэсэн энэ нь жинхэнэ хүүхдийг ажиллуулахын тулд хязгаарлагдмал токеноор CreateProcessAsUserW(...) -г дууддаг.

Альберт Эйнштейн "Бүх зүйлийг аль болох энгийн болгох хэрэгтэй, гэхдээ илүү хялбар болгох ёсгүй" гэж хэлсэн. Энэ утгаараа бидний дизайн асуудал бүрийг хангалттай шийдсэн. Эцсийн архитектур нь бидний өмнө нь авч үзсэн дөрвөн давхаргатай:

• codex.exe өөрөө
• codex-windows-sandbox-setup.exe нь өндөр түвшний тохиргоотой холбоотой бүх ажлыг зохицуулахад зориулагдсан
• хязгаарлагдмал токен командуудыг ажиллуулахын тулд codex-command-runner.exe ашиглана уу
• Хүүхдийн үйл явц

Энэ төсөлд анх орохдоо би юугаар төгсөхийг сайн мэдэхгүй байсан. Миний арга барил нь Codex болон үйлдлийн системийн хоорондох хил хязгаарт sandboxing чадварыг хэмжихээс эхлэх байсан. Энэ арга нь Codex-ийн sandbox-ийг MacOs болон Linux дээр хэрхэн хэрэгжүүлж байгаатай маш сайн тохирч байна.

Windows-ийн хангадаг тодорхой хэрэгслүүдийн талаар илүү ихийг мэдэж авахын хэрээр, аюулгүй байдал болон ашиглахад хялбар байдлыг тэнцвэржүүлсэн олон арван шийдвэрийн тусламжтайгаар систем одоогийн хэлбэртээ хүрсэн - олон хоёртын файл, өөрчлөн тохируулсан хэрэглэгчид, галт ханын дүрмүүд, өндөржүүлсэн тохиргооны алхам, асинхрон процессууд гэх мэт.

Энэ нь онцгойлон энгийн систем биш ч, аюулгүй бөгөөд аль болох хэрэглэгчийн ажилд саад болохгүй sandbox орчныг бүтээхийн тулд төвөгтэй байдлын бүрэлдэхүүн бүрийг зайлшгүй шаардлагаар нэмсэн.

Windows дээрх Codex хэрэглэгчдэд сайн хэрэглэгчийн туршлагыг хүргэхийн тулд бидний зорилго бол ашиг тусыг нь алдагдуулахгүй аюулгүй зүйлийг бий болгох явдал байв. Codex-ийг ашиглахын гол зорилго нь агентууд таны байнгын анхааралгүйгээр ажлаа хийх боломжтой байх явдал юм.

Энэ төслөөс авсан хамгийн том сургамжуудын нэг нь Windows бидэнд "аюулгүй бие даасан код бичих агент"-тай цэвэрхэн холбогдсон нэг энгийн програмыг өгөөгүй явдал байв. Бид уялдаа холбоотой зүйл бүтээхийн тулд хэд хэдэн хэрэгсэл, ойлголтыг боловсруулсан. Зарим эхэн үеийн санаанууд нь бүтэлгүйтсэн. Эцсийн загвар нь асуудлын нэг хэсгийг шийдсэн өмнөх туршилтуудын эрлийз байв.

Нөгөө нэг сургамж бол код бичих агентын аюулгүй байдал нь сонгодог програмын аюулгүй байдлаас өөр зүйл юм. Codex нь жинхэнэ хөгжүүлэгчийн ажлын урсгалд ажиллах ёстой. Инженерийн ажил нь агентлагийн ажлын ачаалалтай нийцтэй байдлыг бодит хэрэгжилттэй тэнцвэржүүлэх тухай байв. Энэ хурцадмал байдал эцсийн загварт тэнцвэрийг бий болгосон.

Codex sandbox хэрхэн ажилладгийг хармаар байна уу? Туршаад үз⁠.