بناء صندوق حماية آمن وفعّال لتمكين Codex على Windows

إبان انضمامي إلى فريق تطوير Codex في سبتمبر 2025، كانت نسخة Codex المخصصة لنظام التشغيل Windows تفتقر إلى بيئة عزل برمجية مدمجة (sandbox)، الأمر الذي كان يجبر مستخدمي Windows على المفاضلة بين خيارين دون المستوى عند تشغيل وكلاء البرمجة التابعين لـ OpenAI:

1. إقرار كل أمر تنفيذي تقريبًا (بما يشمل عمليات قراءة البيانات) يسعى وكيل البرمجة لتشغيله، وهو إجراء يتسم بعدم الكفاءة ويثير الضيق. وتكمن الميزة الكبرى في اعتماد Codex في إعفائك من مشقة تولي المهام الرتيبة بنفسك.
2. تمكين وضع الوصول الكامل: فتح المجال أمام Codex لتنفيذ كافة الأوامر دون اشتراط موافقة مسبقة أو فرض قيود، مما يقضي على العقبات التشغيلية ولكن على حساب آليات الرقابة والإشراف.

يتم تشغيل Codex⁠، وكيل البرمجة المعتمد لدينا، محليًا على الأجهزة المحمولة للمطورين، وذلك عبر واجهة سطر الأوامر (CLI)، أو ملحقات بيئات التطوير المتكاملة (IDE)، أو تطبيق الأجهزة المكتبية. ويقوم بإدارة وبناء مسار الحوار المتبادل بين المستخدم البشري أمام لوحة المفاتيح والنموذج المستضاف سحابيًا لإتمام عمليات الاستدلال.

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

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

يتطلب Codex إتاحة خصائص عزل تدعمها بنية نظام التشغيل محليًا لإنشاء بيئة عزل برمجية مدمجة تتسم بالكفاءة. وفي حين تتيح بعض أنظمة التشغيل برمجيات مساعدة تؤدي هذه المهمة باقتدار (مثل Seatbelt على نظام التشغيل MacOs، وseccomp أو bubblewrap في نظام التشغيل Linux)؛ فإن نظام التشغيل 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.

تصنيفات السلامة لنظام Mandatory Integrity Control

• المفهوم: يرتكز Windows على بنية تصنيفية تُعرف باسم "مستويات السلامة" (منخفضة، ومتوسطة، ومرتفعة)، وهي التي تقرر درجة وثوقية النظام بالكائنات والعمليات. وتقضي القاعدة الجوهرية هنا بأن أي عملية تقع ضمن نطاق السلامة المنخفض تُحرم تمامًا من الكتابة داخل كائن يتمتع بمستوى سلامة أعلى، حتى وإن قضت بنود قائمة التحكم في الوصول (ACL) القياسية بخلاف ذلك. وتوضيحًا لذلك، تُعامل العمليات منخفضة السلامة باعتبارها مجهولة الموثوقية، ومن ثم يصدها Windows عن التعديل في الكائنات العادية ذات السلامة المتوسطة، ما لم تتم إعادة وسم تلك الكائنات صراحةً لتمرير هذا الإجراء.
• سبب الاختيار: بدا نظام Mandatory Integrity Control نموذجًا مثاليًا على الورق؛ عبر تشغيل Codex بصلاحيات سلامة منخفضة، وتعديل وسوم مجلدات العمل الأساسية لتصبح منخفضة السلامة، ومن ثم تفويض Windows لمنع حركات الكتابة في سائر المسارات الأخرى. وكان من شأن هذا المسار تأمين بيئة عمل معزولة لا تستلزم صلاحيات المسؤول، بدعم مباشر من دفاعات نظام التشغيل الأصيلة.
• سبب الاستبعاد: على غرار قوائم ACL، تتداخل وسوم السلامة مع بنية نظام الملفات الفعلي للجهاز المضيف، بل إن التحول الإجرائي في هذه الحالة يتسع نطاقه بشكل حاد. فحينما نضع وسم السلامة المنخفضة على مساحة عمل معينة، فذلك لا يحمل دلالة مجردة بأن 'Codex مخول بالكتابة هنا' حصرًا، بل يفتح الباب أمام العمليات منخفضة السلامة بشكل عام في النظام للكتابة داخل المجلد. وعلى حاسوب المطور الفعلي، يحول هذا الإجراء مستودع الأكواد الحقيقي إلى ثغرة تجميع منخفضة السلامة على مستوى الجهاز المضيف، وهو ما يفرض مخاطر جسيمة تتجاوز بمراحل إجراءات منح صلاحيات ACL الموجهة بدقة لتصميم فردي من بيئة عزل برمجية مدمجة. وحتى مع فرضية استمرار أدوات التطوير متوسطة السلامة في أداء مهامها، فإن نموذج الثقة البنيوي لمساحة العمل يكون قد تبدل كليًا بصورة يستعصي تحجيمها ولا يمكن تبريرها هندسيًا.

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

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

إن إغفال تقييد حركات كتابة الملفات كان سيضعنا أمام ثغرة أمنية حقيقية، وفي المقابل، فإن المبالغة في حظر عمليات الكتابة كانت ستعطل إنتاجية المطورين وتصيب بيئة العزل البرمجية بالشلل نتيجة الاضطرار لطلب موافقات تكرارية مشتتة. وبغية حل هذه المشكلة، استندنا إلى ركيزتين أمنيتين مدمجتين في نظام Windows: وهما معرفات الأمان (SIDs) والرموز المقيدة للكتابة.

يمثل معرف الأمان حجر الزاوية البنيوي الذي يربطه نظام Windows بالحقوق والأذونات الرقمية. فلكل مستخدم معرف أمان مستقل، وللمجموعات التنفيذية معرفات أمان مخصصة، بل إن جلسة الولوج المفردة تُمنح معرف SID فريدًا بها. وتوضيحًا لذلك، قد تحمل جلسة تسجيل الدخول النشطة حاليًا معرف أمان بصيغة S-1-5-5-X-Y، في حين يأخذ معرف أمان تابع لمجموعة مسؤولي النظام المحليين قالبًا ثابتًا مثل S-1-5-32-544.

وعلاوة على ذلك، يتيح Windows إمكانية توليد معرفات أمان اصطناعية لا ترتبط بمستخدم بشري حقيقي، ورغم ذلك تملك أهليّة الإدراج ضمن قوائم التحكم في الوصول (ACLs) التي تدير عمليات القراءة والكتابة والتنفيذ لملفات أو مجلدات محددة. وجعلت هذه المرونة من معرفات الأمان ركيزة مثالية لهندسة بيئة عزل برمجية مدمجة لدينا؛ إذ مكنتنا من صياغة معرفات أمان حصرية لنطاق عزل Codex، بمعزل تام عن سائر مكونات المنظومة البرمجية للجهاز.

تُمثل رموز العمليات كائنات أمنية مدمجة في Windows لصياغة الهوية الرقمية والامتيازات التشغيلية لأي عملية نشطة في النظام؛ إذ تقرر طبيعة وحجم التحركات التي يملك البرنامج صلاحية تنفيذها. ويُعد الرمز المقيد للكتابة نمطًا فريدًا من هذه الرموز، يُلزم نظام Windows بإنفاذ تدقيق إضافي وعبر مرحلة ثانية على كافة حركات إدخال وكتابة البيانات.

وبناءً عليه، يشترط نجاح أي حركة كتابة اجتياز مرحلتي تحقق متتاليتين:

1. أن يمتلك حساب المستخدم القياسي (الجهة 'المالكة' للرمز) الصلاحية الأصلية لإتمام الإجراء
2. أن تُمنح صلاحية النفاذ صراحةً لمعرف أمان واحد على الأقل من بين قائمة معرفات الأمان المقيدة والمدمجة داخل الرمز نفسه.

ومن الناحية العملية، مكنتنا مراحل التحقق هذه من توظيف قوائم التحكم في الوصول (ACLs) لرسم خريطة دقيقة تحدد النطاقات المسموح فيها لبيئة العزل البرمجية المدمجة بتعديل نظام الملفات، وهو ما منحنا مستوى التحكم تفصيلي الأبعاد الذي استلزمته إدارة حركات الكتابة.

بالاعتماد على معرفات الأمان والرموز المقيدة للكتابة، دارت آلية عمل بيئة العزل البرمجية المدمجة غير ممتدة الصلاحيات وفق الخطوات التالية:

1. نتج عن إعداد بيئة العزل توليد معرف أمان اصطناعي يحمل اسم sandbox-write.
2. جرت إتاحة صلاحيات الكتابة والتنفيذ والحذف لمعرف الأمان sandbox-write حصرًا على النطاقات التالية:
   1. دليل العمل الحالي
   2. أي عناصر writable_roots إضافية يجري إعدادها في config.toml.
3. قضت إعدادات بيئة العزل بحجب صلاحيات الكتابة صراحةً عن معرف الأمان ذاته ومنعه من التعديل في مسارات "القراءة فقط الواقعة ضمن النطاقات القابلة للكتابة"، مثل:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. تولى تطبيق Codex تشغيل الأوامر مستندًا إلى رمز مقيد للكتابة، بحيث تشتمل قائمة معرفات الأمان المقيدة المدمجة فيه على: مجموعة Everyone (الكل)، ومعرف الأمان الخاص بجلسة الوصول النشطة حاليًا، بجانب معرف الأمان الاصطناعي sandbox-write.

وفّر هذا المسار الإجرائي معالجة حقيقية لقيود كتابة الملفات وبدا واعدًا للغاية. وبات لزامًا علينا الانتقال لصياغة حل موازٍ يستهدف تحجيم صلاحيات الوصول إلى الشبكة لبيئة العزل.

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

ونتيجة لخروج خيار Windows Firewall من الحسابات، عمدنا إلى تسييج النطاقات التي تقع تحت طائل تحكمنا الفعلي. وحرصنا على تصميم البيئة التابعة لتعتمد نظام الإغلاق التلقائي الآمن عند الفشل مع حزم الأدوات الشبكية التي يعتمد عليها المطورون واقعيًا؛ وبذلك تتعطل أوامر Git وبرامج تثبيت الحزم وتطبيقاتها المماثلة تلقائيًا داخل بيئة العزل البرمجية المدمجة، مما يفرض على المطور التصريح صراحةً بأي عمليات تتطلب النفاذ للشبكة الخارجية. وتلخصت الإستراتيجية في إفساد منافذ الهروب البارزة: عبر إعادة توجيه حزم البيانات المهيأة للعمل عبر خادم وكيل إلى نقطة نهاية ميتة، وتطويع بروتوكول النقل HTTP(S) في نظام Git ليفعل الشيء ذاته، مع فرض فشل فوري ومطلق لاتصالات Git المعتمدة على بروتوكول SSH. وفوق ذلك، بادرنا بوضع مجلد مخصص للحظر يحمل اسم denybin في صدارة متغير البيئة PATH، مع إعادة تنظيم لاحقة الامتدادات PATHEXT لضمان استدعاء نصوص السكربتات البديلة لأدوات 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=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

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

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

• سرعة الإعداد: قد تستهلك عملية تطبيق أذونات وقوائم التحكم في الوصول (ACLs) على مساحة العمل موارد النظام وتستغرق وقتًا طويلًا، ويتوقف ذلك على الطبيعة الهيكلية وتفرع المجلدات لدليل مساحة العمل.
• البصمة والأثر الهيكلي: تسبب هذا النهج في إدراج قوائم التحكم في الوصول (ACLs) فعلية على بيئة نظام المطور، ورغم أن هذه البصمة لا تعد تداخلية أو مفرطة الحساسية نظرًا لأن كافة القوائم المفروضة ترتبط حصرًا بمعرف الأمان الاصطناعي الذي جرى تخليقه خصيصًا لخدمة بيئة العزل دون سواها.
• جمود المعايير الدلالية والإجرائية: إن الركون إلى قوائم التحكم في الوصول (ACLs) لفرض المحددات على مستوى الملفات يعني أن تعديل آليات عمل وسياسات بيئة العزل سيكون مسارًا معقدًا ومكلفًا هندسيًا. فبينما نتمتع على نظام التشغيل macOS بمرونة التعديل الديناميكي الفوري لآلية توليد ملف التكوين ‎.sbpl الحاكم لأداة Seatbelt، فإن ضبط معايير العزل في نظام Windows قد يستلزم إنفاذ عمليات بطيئة ومعالجات مكثفة لتعديل قيم ومصفوفات قوائم التحكم في الوصول (ACLs).
• قصور الحماية الأمنية للشبكة: تماشيًا مع ما أشرنا إليه سلفًا، لم يتعدَّ الحظر تصنيف التدابير "التوجيهية"، وكان عرضة لالتفاف حتمي من قِبل بعض التطبيقات والبرمجيات التي توظف بنية شبكية ذاتية ومستقلة، فضلًا عن عدم تأهيله هيكليًا لصد الهجمات البرمجية المتقدمة والأكواد المعادية.

تُصنف المشكلات الثلاث الأولى بأنها سمات بنيوية ملازمة لأي مشروع تطوير داخلي يستهدف بناء بيئة العزل البرمجية المدمجة غير ممتدة الصلاحيات تتسم بالمرونة المطلوبة لتمكين المسارات الذكية للوكلاء. بيد أن سيناريو كبح واعتراض الشبكة كان يقع في حيز تقني مغاير تمامًا.

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

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

• يقيد نظام Windows حركات المطابقة في قواعد جدار الحماية؛ إذ يمنع ربطها بالهوية غير الأساسية للرمز المقيد، مما يعني عجزنا عن فرض قاعدة جدار حماية تستهدف "أي رمز يشتمل على معرف الأمان الاصطناعي لبيئتنا ضمن قائمة معرفات الأمان المقيدة الخاصة به".
• رغم قدرتنا على صياغة قاعدة جدار حماية تتطابق مع ملف تنفيذي محدد، فإن هذا التكتيك ينحصر أثره في تحجيم صلاحيات الشبكة لتطبيق codex.exe ذاته، دون أن يمتد ليشمل شجرة العمليات التي يبثها الوكيل نيابةً عن المطور، مثل عمليات Git أو Python التابعة.
• علاوة على ذلك، اتسمت بقية أبعاد مطابقة جدار الحماية بعدم ملاءمتها لهيكل التصميم الفني؛ فالقواعد المحددة بنطاق حساب المستخدم ظلت تنطبق على مستخدم Windows الفعلي والحقيقي في هذا النهج غير ممتد الصلاحيات، لا على العملية التابعة المقيدة حصرًا. وجاءت القواعد المستندة إلى مسار البرامج فضفاضة وشديدة العمومية؛ إذ تملك صلاحية حظر تطبيق codex.exe أو بيئة python.exe كليًا، لكنها تعجز عن استهداف فك عزل استدعاء مفرد ومحدد لملف python.exe. وفي السياق ذاته، اعتبرت القواعد القائمة على المنافذ أو العناوين الرقمية بمثابة مقاربة خاطئة كليًا لاستراتيجيتنا الأمنية؛ فحينما غابت حاجتنا لحظر المنفذ 443 مثلاً، تمثل هدفنا في كبح النفاذ الصادر العشوائي لشجرة العمليات المقيدة بعينها.

ومن أجل إنفاذ قاعدة جدار حماية موجهة بدقة لصالح الأوامر المعزولة، بات لزامًا علينا إدارتها وتشغيلها تحت غطاء مستخدم رئيسي مستقل، بدلاً من الارتباط بحساب المستخدم 'الفعلي'. وحملتنا هذه المقاربة نحو توجه جديد كليًا، تعمدنا فيه تخفيف حدة قيدنا الصارم القاضي بـ 'عدم رفع امتيازات الحساب'.

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

• CodexSandboxOffline (المستخدم الذي تستهدفه قواعد جدار الحماية)
• CodexSandboxOnline (المستخدم غير المستهدف من قواعد جدار الحماية)

وفي الحقيقة، يترتب على هذا التفصيل الهيكلي الذي يبدو بسيطًا في ظاهره انعكاسات بالغة الأهمية على بنيوية بيئة العزل، وتحديد فئات المستخدمين المؤهلين للاستفادة منها، فضلًا عن تأثيره المباشر على مستويات تعقيد عمليات التشغيل.

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

انحصرت خطوة الإعداد في تصميم بيئة العزل غير ممتدة الصلاحيات ضمن نطاق إجرائي بسيط ومحدود الأثر نسبيًا:

• إنشاء معرف أمان اصطناعي عند الحاجة لتفعيله
• تطبيق قوائم التحكم في الوصول (ACLs) لصالح معرف الأمان الاصطناعي sandbox-write

وفي المقابل، تتسع خارطة مهام الإعداد في بيئة العزل ممتدة الصلاحيات لتشمل مسارات تشغيلية أكثر عمقًا:

• إنشاء معرف أمان اصطناعي، في حال خلو النظام من وجوده مسبقًا
• إنشاء حسابات مستخدمي بيئة العزل بنمطيها المتصل والمنفصل عن الشبكة، ما لم يكن قد تم إنشاؤها سلفًا
• حفظ وتخزين بيانات الاعتماد الخاصة بالحسابات المستحدثة محليًا مع تشفيرها عبر واجهة Windows Data Protection API ‏(DPAPI) في نطاق رقمي آمن يحظر على حسابات بيئة العزل ذاتها قراءته
• صياغة قواعد جدار حماية صارمة تقضي بحظر كافة حزم الوصول إلى الشبكة الصادرة والتابعة لحساب المستخدم CodexSandboxOffline، مع مراجعة القواعد والتحقق من سلامتها الهيكلية في حال وجودها مسبقًا

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

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

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

ولما كانت معالجة قائمة المجلدات هذه تجري وفق مبدأ بذل أفضل المحاولات المتاحة، فضلاً عن الكلفة التشغيلية الباهظة لتطبيق قوائم التحكم في الوصول (ACLs) على كل منها، فقد عمدنا إلى تنفيذ هذه البرمجية بشكل غير متزامن؛ لضمان عدم إعاقة خطوة تهيئة بيئة العزل لسرعة تجربة المستخدم واضطرارها لانتظار انتهاء حركات التثبيت.

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

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

• يتم تشغيل تطبيق codex.exe مستندًا إلى صلاحيات مستخدم Windows الفعلي. وإثر ذلك، وعبر تسلسل بنيوي، يتولى محرك Codex إجراء الآتي
  • استدعاء واجهة الربط LogonUserW(...)‎ لصالح حساب مستخدم بيئة العزل.
  • استدعاء واجهة CreateRestrictedToken(...)‎ لتطبيق القيود على رمز حساب بيئة العزل المستدعى.
  • تطويع هذا الرمز المقيد لحساب بيئة العزل في استدعاء CreateProcessAsUserW(...)‎ لبدء العملية التابعة الختامية.

بيد أن هذا المسار الإجرائي المستهدف اصطدم في التطبيق العملي بعائق وجدار امتيازات أمني عند استدعاء CreateProcessAsUserW(...)‎. ومفاد ذلك أن تطبيق codex.exe، وإن كان قادرًا هيكليًا على توليد رمز مقيد لحساب مستخدم بيئة العزل، فإنه يعجز عن بدء عملية تابعة بموثوقية مستندًا إلى هذا الرمز من الجانب التابع لنطاق المستخدم الفعلي. واستلزم الحل الهندسي وجود عملية برمجية نشطة مسبقًا وتعمل حصرًا بصلاحيات حساب مستخدم بيئة العزل؛ مما يكفل نقل خطوة فرض القيود والبث النهائي وإنفاذها بالكامل على الجانب التابع لحساب مستخدم بيئة العزل، بدلاً من إدارتها من منطلق حساب المستخدم الحقيقي.

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

المرحلة الأولى

• يتولى تطبيق codex.exe استدعاء CreateProcessWithLogonW(...) لبدء codex-command-runner.exe بصلاحيات حساب مستخدم بيئة العزل، بمعزل عن تطبيق أي رموز مقيدة في هذه الخطوة.

المرحلة الثانية

• من داخل أداة تشغيل الأوامر، تعمد OpenProcessToken(GetCurrentProcess(), ...)‎ إلى فتح الرمز ذاته الخاص بأداة تشغيل الأوامر، والمندرج أصلاً تحت مظلة حساب مستخدم بيئة العزل.
• تبادر أداة التشغيل باستدعاء GetTokenInformation(...)‎ لاستخلاص رمز الأمان الخاص بالوصول إلى بيئة العزل، ومن ثم تفعيل CreateRestrictedToken(...)‎ لتشييد الرمز المقيد الختامي.
• ضمن ذات المحيط البرمجي لأداة التشغيل، يجري استدعاء CreateProcessAsUserW(...)‎ مستندًا إلى ذلك الرمز المقيد لبدء العملية التابعة الحقيقية والمستهدفة.

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

• تطبيق codex.exe نفسه
• تطبيق codex-windows-sandbox-setup.exe للتعامل مع كل الأعمال المرتبطة بالإعداد ممتد الصلاحيات
• تطبيق codex-command-runner.exe لتشغيل أوامر الرمز المقيّد
• العملية التابعة

حينما باشرت العمل على هذا المشروع في مراحله الأولى، لم تكن لدي رؤية جازمة حول النتيجة النهائية التي ستؤول إليها المعمارية. واقتصرت مقاربتي حينئذٍ على زرع وتهيئة آليات العزل البرمجي عند النقطة البينية الفاصلة بين تطبيق Codex ونظام التشغيل؛ وهي مقاربة تحاكي بدقة هندسة بناء بيئة عزل Codex المعتمدة على نظامي التشغيل macOS وLinux.

وبمرور الوقت، ومع تعميق فهمي للأدوات النوعية التي يتيحها نظام Windows، وعبر سلسلة طويلة من القرارات المتزنة للمفاضلة بين الأمان وسلاسة تجربة الاستخدام، تطور النظام وتعاظم إلى بنيته الحالية؛ التي قوامها ملفات تنفيذية متعددة، وحسابات مستخدمين مخصصة، وقواعد جدار حماية، ومرحلة تهيئة وتأسيس ممتدة الصلاحيات، بجانب العمليات المعالجة بشكل غير متزامن، وغيرها من التقنيات.

ولا يصنف هذا البناء كمنظومة بسيطة على وجه الخصوص، بيد أن كل مظهر من مظاهر التعقيد الهيكلي قد أُدرِج بداعي الضرورة القصوى فقط؛ بهدف صياغة بيئة عزل كفيلة بتحقيق الحماية المطلقة، شريطة ألا تعيق مسارات المطور أو تقف عقبةً في طريقه قدر المستطاع.

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

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

وانبثق الدرس الآخر من حقيقة أن أمن وكلاء البرمجة يمثل نمطًا مغايرًا كليًا لآليات أمن التطبيقات التقليدية؛ إذ يُشترط في Codex مواءمة ومواكبة مسارات العمل الفعلية للمطورين. وانحصرت الجهود الهندسية في معايرة التوافق مع الأنماط التشغيلية المستقلة للوكلاء ضد محددات الإنفاذ الأمني الحقيقي، وهو التجاذب البنيوي الذي صاغ ملامح المقايضات الحاكمة للتصميم النهائي.

هل تتطلع لمشاهدة بيئة عزل Codex قيد التشغيل الفعلي؟ بادر بتجربتها الآن⁠.