عرضت OpenAI كيف بنت sandbox آمنة لـ Codex على Windows

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

لماذا لم ينجح

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

تحققت OpenAI في البداية من آليات العزل القياسية في Windows، لكن لم تناسب أي منها دون تنازلات كبيرة. يوفر AppContainer حدًا أمنيًا قويًا، لكنه مصمم للتطبيقات المحددة مسبقًا وليس لمجموعة مفتوحة من السيناريوهات مع Git وPython ومديري الحزم والملفات الثنائية من جهات خارجية. أثبتت بيئة Windows Sandbox أنها عالم "منفصل" جدًا: يحتاج Codex للعمل مع الفحص الفعلي للمستخدم وليس آلة افتراضية مؤقتة، بالإضافة إلى أن هذا الوضع غير متاح على Windows Home. بدت آلية مستويات النزاهة جيدة فقط على الورق لأنها غيرت نموذج الثقة لنظام الملفات الفعلي للمضيف.

نظام الحماية الأول

تم بناء أول نموذج أولي عامل من OpenAI بدون متطلبات حقوق المسؤول. استخدم معرفًا أمنيًا قياسيًا اصطناعيًا وعلامة مقيدة للكتابة—علامة خاصة تسمح بكتابة البيانات فقط حيث تتطابق أذونات المستخدم العادية والإذن الحماية المنفصل في نفس الوقت. سمح هذا لـ Codex بالقراءة في أي مكان تقريبًا لكن الكتابة فقط في جذور المشروع المحددة بدقة.

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

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

كيف يعمل الإصدار النهائي

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

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

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

في الهندسة المعمارية النهائية، تشارك أربع طبقات: `codex.exe` نفسه، وملف ثنائي إعداد مرفوع، ومشغل الأوامر، والعملية الهدف.

ما يعنيه هذا

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