OpenAI تكشف كيف بنت بيئة معزولة آمنة لـ Codex على نظام Windows

أوضحت OpenAI كيف بنت بيئة معزولة متكاملة لـ Codex على Windows، بحيث يستطيع الوكيل تنفيذ الأوامر محليًا دون وصول كامل إلى النظام. كان الهدف بسيطًا: الحفاظ على راحة البرمجة المستقلة، مع منع النموذج من الكتابة في أي مكان يشاء أو الخروج إلى الإنترنت دون إذن صريح من المستخدم.

لماذا لم ينجح النهج الأول؟

في البداية، كان أمام مستخدمي Windows خياران سيئان. إما الموافقة على كل أمر تقريبًا، بما في ذلك قراءة الملفات البسيطة، وإما تفعيل Full Access، أي منح الوكيل فعليًا مستوى الصلاحيات نفسه الذي يملكه المطوّر. وهذا حساس بوجه خاص في حالة Codex، فالوكيل يعمل عبر CLI وIDE وتطبيق سطح المكتب، ويمكنه تشغيل الاختبارات وتعديل الشيفرة وإنشاء فروع Git واستدعاء أدوات التطوير المعتادة.

جرّبت OpenAI أولًا آليات العزل القياسية في Windows، لكن أيًّا منها لم يناسب دون تنازلات جسيمة. يوفر AppContainer حدًا أمنيًا قويًا، لكنه مصمم لتطبيق موصوف مسبقًا، لا لمجموعة مفتوحة من السيناريوهات تشمل Git وPython ومديري الحزم والملفات التنفيذية الخارجية. أما Windows Sandbox فتبيّن أنه عالم «منفصل» أكثر من اللازم: يحتاج Codex إلى العمل مع checkout الفعلي للمستخدم، لا مع آلة افتراضية تُستخدم لمرة واحدة، فضلًا عن أن هذا الوضع غير متاح في Windows Home. وبدت آلية مستويات السلامة (integrity levels) جذابة على الورق فقط، لأنها تغيّر نموذج الثقة في نظام الملفات الفعلي للمضيف.

المخطط الأول للحماية

بنت OpenAI النموذج الأولي العامل الأول دون اشتراط صلاحيات المسؤول. استخدم هذا النموذج معرّف SID اصطناعيًا ورمز write-restricted token، وهو رمز خاص لا يسمح بكتابة البيانات إلا حيث تتطابق صلاحيات المستخدم المعتادة مع إذن منفصل خاص بالـ sandbox. وهكذا كان Codex يقرأ تقريبًا من أي مكان، لكنه لا يكتب إلا في جذور المشروع المحددة بدقة.

• إنشاء معرّف SID منفصل باسم `sandbox-write`
• منح هذا المعرّف صلاحيات الكتابة والتنفيذ والحذف في الدليل العامل الحالي وفي `writable_roots`
• إمكانية منع الكتابة، داخل هذه الأدلة، في `.git` و`.codex` و`.agents` كلٌّ على حدة
• تشغيل كل أمر برمز مقيّد يأخذ في الحسبان `Everyone` ومعرّف SID للجلسة الحالية و`sandbox-write`

نجح هذا النهج بشكل جيد مع الملفات، لكن الشبكة بقيت نقطة الضعف. حاول الفريق «كسر» مسارات الشبكة المعتادة عبر متغيرات البيئة مثل `HTTPS_PROXY` و`ALL_PROXY` و`GIT_SSH_COMMAND`، وكذلك عبر استبدال الملفات التنفيذية لـ `ssh` و`scp` بملفات وهمية (stub). وكان ذلك كافيًا في الغالب لأوامر Git العادية ومثبّتات الحزم، لكن الحماية بقيت أقرب إلى التوصية منها إلى الإلزام: إذ يمكن لأي عملية تجاهل متغيرات البيئة أو تجاوز PATH أو فتح مقبس (socket) مباشرة.

كيف صُمّم الإصدار النهائي؟

بسبب قيود الشبكة، تخلّت OpenAI عن فكرة بيئة معزولة بلا صلاحيات مسؤول بالكامل، وانتقلت إلى المخطط الحالي الأكثر صرامة. فعند مرحلة الإعداد، ينشئ Codex الآن مستخدمَين محليَّين: `CodexSandboxOffline` للعمليات التي لا تحتاج إلى شبكة، و`CodexSandboxOnline` للسيناريوهات التي يلزم فيها الوصول. ما زالت الأوامر تُشغَّل برمز مقيّد، لكنها لم تعد تعمل باسم المستخدم الحقيقي، بل باسم مستخدم sandbox مخصص يمكن ربط قواعد Windows Firewall به.

تطلّب ذلك عملية إعداد (setup) منفصلة. تنشئ هذه العملية معرّف SID اصطناعيًا، وتُنشئ حسابات الـ sandbox، وتشفّر بيانات اعتمادها عبر DPAPI، وتضع قواعد جدار ناري تحجب الحركة الصادرة للمستخدم غير المتصل (offline). وبالتوازي، يمنح النظام مستخدمي الـ sandbox صلاحيات قراءة في الأدلة المعتادة مثل `C:\Users\<real-user>` و`C:\Windows` و`C:\Program Files` و`C:\ProgramData`، وإلا لما استطاع الوكيل حتى قراءة ملفات المستخدم وأدواته قراءة سليمة. ويجري جزء من ضبط ACL بشكل غير متزامن كي لا يؤخر التثبيت الأولي.

ونشأت مشكلة منفصلة عند حدود تشغيل العمليات. فقد تبيّن أن `codex.exe` لا يستطيع بشكل موثوق قطع المسار كله، من تسجيل الدخول باسم مستخدم الـ sandbox حتى `CreateProcessAsUserW(...)`، انطلاقًا من سياق المستخدم الحقيقي. لذلك نقلت OpenAI تشغيل الأوامر إلى ملف تنفيذي مستقل هو `codex-command-runner.exe`: يشغّله `codex.exe` أولًا بصفة مستخدم الـ sandbox، ثم ينشئ المشغّل (runner) داخل جلسته رمزًا مقيّدًا ويطلق العملية الابنة النهائية. وتشارك في البنية النهائية أربع طبقات: `codex.exe` نفسه، وملف الإعداد التنفيذي ذو الصلاحيات المرتفعة، ومشغّل الأوامر، والعملية المستهدفة.

ماذا يعني ذلك؟

بالنسبة لمطوّري Windows، هذا تحوّل مهم: فوكلاء البرمجة المحليون يصبحون أكثر راحة، وأيضًا أكثر قابلية للتنبؤ من ناحية الأمان. وقد أظهرت OpenAI عمليًا أن البرمجة الوكيلية على Windows لا يكفيها «API سحري» واحد، وأن حل المشكلة يستلزم الجمع بين ACL والرموز والمستخدمين المنفصلين وقواعد الجدار الناري وملفات تنفيذية إضافية. ويرفع ذلك تعقيد التنفيذ، لكنه يقرّب نموذج عمل Codex من المتطلبات الفعلية للفرق التي تريد أتمتة المهام الروتينية دون التخلي الكامل عن السيطرة.