Windows پر Codex کو فعال کرنے کے لیے ایک محفوظ, مؤثر سینڈ باکس بنانا

ستمبر 2025 میں جب میں Codex انجینئرنگ ٹیم میں شامل ہوا، تو Windows کے لیے Codex میں سینڈ باکس کا نفاذ موجود نہیں تھا، یعنی Windows صارفین کو OpenAI کے کوڈنگ ایجنٹس استعمال کرتے وقت دو کمتر اختیارات میں سے ایک چننے پر مجبور ہونا پڑتا تھا:

1. تقریباً ہر کمانڈ کی منظوری دینا (حتٰی کہ reads کمانڈز کی بھی) جسے کوئی کوڈنگ ایجنٹ چلانا چاہتا تھا، جو غیر مؤثر اور جھنجھلا دینے والا تھا. Codex استعمال کرنے کا ایک بڑا فائدہ یہ ہے کہ آپ کو اکتا دینے والا سارا کام خود نہیں کرنا پڑتا.
2. فل ایکسیس موڈ کو فعال کرنا: Codex کو بغیر منظوری یا پابندیوں کے تمام کمانڈز چلانے دینا، جس سے نگرانی کم ہو جاتی ہے لیکن رکاوٹ ختم ہو جاتی ہے.

Codex⁠، ہمارا کوڈنگ ایجنٹ، ڈویلپرز کے لیپ ٹاپس پر چلتا ہے—چاہے وہ CLI کے ذریعے ہو، IDE ایکسٹینشن کے ذریعے یا ڈیسک ٹاپ ایپ کے ذریعے. یہ اِنفرنس کو ہینڈل کرنے کے لیے کی بورڈ پر موجود انسان اور کلاؤڈ میں چلنے والے ماڈل کے درمیان گفتگو کو منظم کرتا ہے.

Codex بطورِ ڈیفالٹ ایک حقیقی صارف کی اجازتوں کے ساتھ چلتا ہے، یعنی یہ وہ سب کچھ کر سکتا ہے جو صارف خود کر سکتا ہے. یہ طاقتور بھی ہے اور ممکنہ طور پر خطرناک بھی. کوڈنگ ماڈل ہارنیس کو یہ ہدایت دے سکتا ہے کہ وہ لوکل کمانڈز چلائے، جیسے ٹیسٹس چلانا، فائل کو پڑھنا یا ایڈٹ کرنا، یا 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 سینڈ باکس ہے، جو ایک capability-based isolation ماڈل ہے اور ان ایپس کے لیے بنایا گیا ہے جو پہلے سے واضح طور پر جانتی ہیں کہ انہیں کس چیز تک رسائی درکار ہے.
• کیوں: یہ اس لیے پُرکشش ہے کیونکہ یہ بہترین کوشش پر مبنی پابندیوں کے بجائے ایک حقیقی OS باؤنڈری فراہم کرتا ہے.
• کیوں نہیں: Codex ایک محدود دائرۂ کار والی واحد ایپ نہیں ہے. یہ اوپن-اینڈڈ ڈویلپر ورک فلوز کو چلاتا ہے: شیلز، Git، Python، پیکیج مینیجرز، بلڈ ٹولز اور کوئی بھی دوسری بائنریز جن کی ایجنٹ کو ضرورت محسوس ہو. عملی طور پر، اس وجہ سے AppContainer اس مسئلے کے لیے ناموزوں ثابت ہوا. یہ مضبوط آئسولیشن تھی، لیکن یہ "کسی ایجنٹ کو ڈویلپر کی طرح کام کرنے دیں" کے مقابلے میں ورک لوڈز کی کہیں زیادہ محدود قسم کے لیے تھی.

Windows Sandbox

• کیا: Windows Sandbox Microsoft کی قابلِ ترک، ہلکی پھلکی VM ہے. آپ کو ایک نیا Windows ڈیسک ٹاپ ملتا ہے جس کے ساتھ مضبوط آئیسولیشن باؤنڈری ہوتی ہے اور آپ اس کے اندر جو کچھ بھی کرتے ہیں وہ سیشن ختم ہونے پر ختم ہو جاتا ہے.
• کیوں: واضح وجوہات کی بنا پر یہ دلچسپ ہے—یہ AppContainer کے مقابلے میں کسی بھی قسم کے سافٹ ویئر کے ساتھ کہیں زیادہ ہم آہنگ ہے اور سیکیورٹی کے لحاظ سے یہ ایک بہت زیادہ مضبوط حد فراہم کرتا ہے.
• کیوں نہیں: Codex کو صارف کے اصل چیک آؤٹ، ٹولز اور انوائرنمنٹ پر براہِ راست کام کرنا ہوتا ہے، نہ کہ ایک الگ عارضی ڈیسک ٹاپ کے اندر، جس کے لیے سیٹ اپ اور ہوسٹ/گیسٹ بریجنگ درکار ہوتی. اس میں ایک بنیادی پروڈکٹ مسئلہ بھی تھا: Windows Sandbox تو Windows Home SKUs پر دستیاب ہی نہیں ہے.

Mandatory Integrity Control (MIC) انٹیگریٹی لیبلنگ

• کیا: ونڈوز میں ایک تصور ہوتا ہے جسے "سالمیت کی سطحیں" (integrity levels) کہا جاتا ہے، جیسے کم، درمیانہ اور زیادہ، جو یہ طے کرتی ہیں کہ سسٹم آبجیکٹس اور پروسیسز پر کتنا اعتماد کرتا ہے. بنیادی اصول یہ ہے کہ کم سالمیت والا پروسیس زیادہ سالمیت کی سطح والے آبجیکٹ پر لکھ نہیں سکتا، خواہ عام ACL بصورتِ دیگر اس کی اجازت دیتی ہو. مثال کے طور پر، کم-انٹیگریٹی پروسیس کو کم قابلِ اعتماد سمجھا جاتا ہے، اس لیے Windows اسے عام میڈیم-انٹیگریٹی آبجیکٹس پر لکھنے سے روک دیتا ہے، الا یہ کہ ان آبجیکٹس کو واضح طور پر دوبارہ لیبل کیا گیا ہو تاکہ اسے اس کی اجازت مل سکے.
• کیوں: MIC کاغذ پر نہایت خوب صورت لگتا تھا—Codex کو لو انٹیگریٹی پر چلانا، قابلِ تحریر روٹس کو لو انٹیگریٹی کے طور پر دوبارہ لیبل کرنا اور Windows کو باقی جگہوں پر لکھنے پر پابندی نافذ کرنے دینا. اس سے ہمیں ایک غیر ایڈمن طریقہ مل جاتا، جس کی بنیاد ایک حقیقی OS میکانزم پر ہوتی.
• کیوں نہیں: ACLs کی طرح، سالمیت کے لیبلز حقیقی ہوسٹ فائل سسٹم میں ترمیم کرتے ہیں اور اس صورت میں معنوی تبدیلی خاص طور پر وسیع ہوتی ہے. ورک اسپیس کو کم سالمیت کے طور پر نشان زد کرنے کا مطلب صرف یہ نہیں ہے کہ "Codex یہاں لکھ سکتا ہے." اس کا مطلب ہے کہ کم سالمیت والے پروسیسز عام طور پر وہاں لکھ سکتے ہیں. ایک حقیقی ڈویلپر مشین پر، یہ صارف کے اصل چیک آؤٹ کو ہوسٹ کے لیے ایک کم سالمیتی سنک میں بدل دیتا ہے، جو ایک سینڈباکس ڈیزائن کو احتیاط سے ہدف بنائے گئے ACLs دینے کے مقابلے میں کہیں زیادہ خطرناک ہے. چاہے میڈیم-انٹیگریٹی ڈویلپر ٹولز کام کرتے رہیں، ورک اسپیس کا بنیادی اعتماد ماڈل اس طرح بدل چکا ہے جسے محدود رکھنا مشکل اور جس کا جواز پیش کرنا اس سے بھی زیادہ مشکل ہے.

تمام آپشنز کو غیر موزوں قرار دینے کے بعد، ہم نے Windows صارفین کے لیے ایک اچھا Codex تجربہ فراہم کرنے کے لیے اپنا خود کا حل ڈیزائن کرنا شروع کیا.

ہمارے پہلے کارآمد پروٹو ٹائپ نے جس آئسولیشن کی ہمیں ضرورت تھی اسے عمل میں لانے کے لیے Windows کے تصورات اور ٹولز کے امتزاج کا استعمال کیا. شروع ہی سے، ایک مقصد یہ تھا کہ اسے اعلٰی اختیارات درکار کیے بغیر کام کرنے کے قابل بنایا جائے، یعنی Codex کو صرف سینڈ باکس سیٹ اپ کرنے یا چلانے کے لیے صارف سے ایڈمنسٹریٹر اختیارات کے لیے پرومپٹ کرنے کی ضرورت نہ ہو. اس کا مطلب یہ تھا کہ دو چیزوں پر معقول حدیں کیسے لگائی جائیں: فائل میں لکھنے کے عمل اور نیٹ ورک تک رسائی.

اگر ہم فائل لکھنے کی اجازت کو بالکل بھی محدود نہ کرتے، تو ہمیں ایک سیکیورٹی مسئلہ پیش آ جاتا. اور اگر ہم اسے بہت زیادہ محدود کر دیتے، تو سینڈ باکس صارف کی پروڈکٹیوٹی صلاحیت کو متاثر کرتا اور بار بار منظوری لینی پڑتی. اس مسئلے کو حل کرنے کے لیے ہم نے Windows کے دو اہم بلڈنگ بلاکس پر انحصار کیا: SIDs اور رائٹ-ریسٹرکٹڈ ٹوکنز.

SID، یا سیکیورٹی آئیڈینٹیفائر، وہ شناخت ہے جسے Windows اجازتوں سے منسلک کرتا ہے. ہر صارف کا ایک SID ہوتا ہے، گروپس کے SIDs ہوتے ہیں اور حتٰی کہ ایک واحد لاگ اِن سیشن کو بھی اپنا SID ملتا ہے. مثال کے طور پر، فی الحال لاگ اِن سیشن کا SID S-1-5-5-X-Y جیسا ہو سکتا ہے. مقامی منتظمین گروپ کو تفویض کردہ SID S-1-5-32-544 ہو سکتا ہے.

Windows آپ کو سنتھیٹک SIDs بنانے کی بھی اجازت دیتا ہے جو کسی حقیقی صارف سے تعلق نہیں رکھتے، لیکن پھر بھی ACLs (رسائی کنٹرول لسٹس) میں ظاہر ہو سکتے ہیں، جو یہ طے کرتی ہیں کہ کون مخصوص فائلز یا ڈائریکٹریز کو پڑھ، لکھ یا ایگزیکیوٹ کر سکتا ہے. اس سے SIDs ہمارے سینڈ باکس کے لیے ایک مفید پریمیٹو بن جاتے ہیں: ہم Codex سینڈ باکس کے لیے مخصوص SIDs بنا سکتے ہیں، جو صرف اسی کے استعمال کے لیے ہوں اور مشین پر کسی اور چیز کو متاثر نہ کریں.

پروسیس ٹوکن Windows میں سیکیورٹی آبجیکٹس ہوتے ہیں جو چلتے ہوئے پروسیس کے لیے شناخت اور مراعات کی وضاحت کرتے ہیں. یہ طے کرتے ہیں کہ کوئی پروسیس کون سی کارروائیاں انجام دے سکتا ہے. ایک تحریر-محدود ٹوکن پروسیس ٹوکن کی ایک خاص قسم ہے جو تحریری کارروائیوں پر Windows سے رسائی کی ایک اضافی جانچ کرواتا ہے.

کسی لکھنے (write) کے کامیاب ہونے کے لیے دو چیکس کو پاس کرنا ضروری ہے:

1. نارمل یوزر آئیڈینٹی (ٹوکن "اونر") کو ایسا کرنے کی اجازت ہونی چاہیے
2. ٹوکن کی محدود SID فہرست میں کم از کم ایک SID کو بھی رسائی دی گئی ہونی چاہیے

عملی طور پر، یہ چیک ہمیں ACLs کے ذریعے یہ بالکل واضح طور پر طے کرنے دیتے ہیں کہ سینڈ باکس فائل سسٹم میں کہاں تبدیلی کر سکتا ہے، جس نے ہمیں رائٹ آپریشنز (write operations) کے حوالے سے مطلوبہ باریک بینی فراہم کی.

SIDs اور رائٹ-ریسٹرکٹڈ ٹوکنز کے ساتھ، ہمارا اَن ایلیویٹڈ سینڈ باکس اس طرح کام کرتا تھا:

1. سینڈ باکس سیٹ اپ نے ایک سنتھیٹک SID بنایا جسے سینڈباکس-رائٹ کہا جاتا ہے.
2. سینڈباکس-رائٹ SID کو لکھنے، چلانے اور حذف کرنے کی رسائی دی گئی تھی
   1. موجودہ ورکنگ ڈائریکٹری
   2. کوئی بھی اضافی writable_roots جو config.toml میں ترتیب دی گئی ہوں.
3. سینڈ باکس سیٹ اپ نے واضح طور پر اسی SID کو "تحریر کے اندر صرف پڑھنے کے قابل" مقامات پر رائٹ ایکسس سے منع کیا، جیسے:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex نے کمانڈز ایک رائٹ-ریسٹرکٹڈ ٹوکن کے تحت لانچ کیں جس کی ریسٹرکٹڈ SID لسٹ میں ہر ایک، موجودہ لاگ اِن سیشن کا SID اور سینڈباکس-رائٹ سنتھیٹک SID شامل ہیں.

اس فلو نے فائل لکھنے کو محدود کرنے کا مسئلہ مؤثر طور پر حل کر دیا اور امید افزا معلوم ہوا. اب ہمیں سینڈ باکس کی نیٹ ورک رسائی محدود کرنے کے لیے ایک حل درکار تھا.

نیٹ ورک ایکسس کو محدود کرنا سینڈ باکس کا ایک اہم حصہ ہے; اس کے بغیر میلیشس کوڈ مشین سے ڈیٹا کو انٹرنیٹ پر ایکسفلٹریٹ کر سکتا ہے. چونکہ ہم ایلیویشن کی ضرورت سے بچنا چاہتے تھے، اس لیے ہمارے پاس نیٹ ورک ٹریفک کو مضبوطی سے بلاک کرنے کے محدود آپشنز تھے. جن ٹولز کو ہم استعمال کرنا چاہتے تھے، جیسے Windows فائر وال، انہیں عموماً ایڈمن پرمیشنز کے بغیر انسٹال نہیں کیا جا سکتا تھا.

Windows فائر وال کے بطور اختیار دستیاب نہ ہونے سے، ہم اس بات تک محدود ہو گئے کہ ہم کیا کنٹرول کر سکتے تھے. ہم نے کوشش کی کہ ذیلی ماحول کو ان نیٹ ورکڈ ٹولز کے لیے فیل-کلوزڈ بنایا جائے جنہیں ڈیولپرز حقیقتاً استعمال کرتے ہیں، یعنی خرابی کی صورت میں بند/محفوظ رہے، تاکہ Git کمانڈز، پیکیج انسٹالرز وغیرہ سینڈ باکس میں ناکام ہو جائیں اور صارف کو انٹرنیٹ سے متعلقہ کسی بھی کارروائی کی منظوری دینی پڑے. خیال یہ تھا کہ فرار کے واضح راستوں کو ناکارہ بنا دیا جائے: پراکسی سے آگاہ ٹریفک کو ایک غیر فعال اینڈپوائنٹ پر بھیجنا، Git کے HTTP(S) ٹرانسپورٹ سے بھی یہی کروانا اور SSH پر Git کو فوراً ناکام بنا دینا. اس کے علاوہ، ہم نے ایک چھوٹی 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 ایک کسٹم-کریئیٹڈ سنتھیٹک SID سے متعلق ہیں جو صرف سینڈ باکس کے ذریعے استعمال ہوتا ہے.
• تبدیل کرنے میں مشکل معنویات: فائل پر مبنی پابندیوں کے لیے ACLs پر انحصار کا مطلب ہے کہ سینڈ باکس کی معنویات کو تبدیل کرنا مہنگا اور پیچیدہ ہے. جبکہ macOS پر، ہم متحرک طور پر یہ بدل سکتے ہیں کہ ہم .sbpl کیسے تیار کرتے ہیں Seatbelt کو کنفیگر کرنے کے لیے استعمال ہونے والی فائل، Windows sandbox کو ACLs ایڈجسٹ کرنے کے لیے ایک سست اور وسائل طلب کارروائی درکار ہو سکتی ہے.
• نیٹ ورک پروٹیکشن کمزور ہے. جیسا کہ پہلے بتایا گیا، یہ "مشورہ" تھا، کچھ پروگرامز جو اپنا خود کا نیٹ ورکنگ اسٹیک امپلیمنٹ کرتے ہیں، اس کو یقینی طور پر بائی پاس کر سکتے تھے اور یہ ایڈورسیرئل کوڈ کے خلاف مضبوط رہنے کے لیے ڈیزائن نہیں کیا گیا تھا.

پہلے تین مسائل ایک کسٹم سینڈ باکس امپلیمنٹیشن کے لازمی حصے ہیں جو ایجنٹک فلووز کے لیے کافی لچکدار ہے. تاہم، نیٹ ورک سپریشن کی کہانی مختلف تھی.

اس کے علاوہ، نہ صرف ایک بدنیتی پر مبنی ایجنٹ آسانی سے انوائرمنٹ بیسڈ نیٹ ورک سپریشن کو بائی پاس کر سکتا تھا، بلکہ بہت سا اچھے ارادے والا کوڈ/بائنریز بھی اسے بائی پاس کر لیتے اگر وہ انوائرمنٹ پراکسی ویری ایبلز کو فالو نہ کرتے، یا اگر وہ اپنا خود کا ساکٹ بیسڈ نیٹ ورک کوڈ امپلیمنٹ کرتے. ہمیں محسوس ہوا کہ یہ پہلو اتنا اہم تھا کہ ایک بہتر سینڈ باکس موڈ میں انویسٹ کرنا ضروری ہے.

بہتر نیٹ ورک سپریشن حاصل کرنے کے لیے، ہم Windows فائر وال استعمال کرنا چاہتے تھے، جو ہمیں صارفین یا پروگراموں کے لیے آؤٹ باؤنڈ نیٹ ورک ٹریفک بلاک کرنے دیتا ہے. بدقسمتی سے، ہم مؤثر طور پر ایسا مؤثر فائر وال رول نہیں بنا سکتے تھے جو صرف Codex ہارنیس کی طرف سے شروع کی گئی کمانڈز پر لاگو ہو، اس کی چند وجوہ تھیں:

• Windows محدود ٹوکن کی غیر پرنسپل شناخت سے فائر وال رول کو ملانے کی اجازت نہیں دیتا. اس کا مطلب یہ ہے کہ ہم فائر وال رول کو "ایسا کوئی بھی ٹوکن جس کی ریسٹرکٹڈ SID فہرست میں ہمارا سنتھیٹک SID شامل ہو" پر لاگو نہیں کر سکتے تھے.
• اگرچہ ہم ایسا فائر وال رول بنا سکتے تھے جو کسی خاص بائنری سے میچ کرے، مگر اس سے صرف codex.exe کی اپنی نیٹ ورکنگ محدود ہو سکتی تھی. یہ ان پروسیسز پر لاگو نہیں ہوگا جنہیں ایجنٹ صارف کی جانب سے شروع کرتا ہے، جیسے Git یا Python پروسیسز.
• دیگر فائر وال میچ ڈائمینشنز کی ساخت بھی غلط تھی. بغیر بلند مراعات والے ڈیزائن میں صارف کے دائرۂ کار والے اصول اب بھی حقیقی Windows صارف سے مطابقت رکھتے تھے، صرف محدود چائلڈ سے نہیں. پروگرام پاتھ کے قواعد بہت عمومی تھے: وہ عموماً codex.exe یا python.exe کو بلاک کر سکتے تھے، لیکن python.exe کے اس ایک سینڈ باکسڈ اجرا کو نہیں. پورٹ یا ایڈریس پر مبنی اصول بھی سراسر غلط پالیسی تھے. مثال کے طور پر، ہم پورٹ 443 کو بلاک نہیں کرنا چاہتے تھے؛ ہم اس مخصوص محدود پروسیس ٹری کے لیے من مانی آؤٹ باؤنڈ رسائی کو بلاک کرنا چاہتے تھے.

اپنی سینڈ باکسڈ کمانڈز پر خاص طور پر فائر وال رول لاگو کرنے کے لیے، ہمیں انہیں "حقیقی" صارف کے طور پر نہیں بلکہ ایک الگ پرنسپل کے طور پر چلانا تھا. اس طریقے نے ہمیں ایک نئے راستے پر ڈال دیا، جس میں ہم نے "کوئی ایلیویشن نہیں" کی اپنی پابندی نرم کر دی.

سینڈ باکس کی اگلی تکرار، جو ہماری موجودہ عمل آوری ہے، سیٹ اَپ کے وقت بلند سطح کی ایڈمن اجازتوں کا تقاضا کرتی ہے. لہٰذا میں اس کے لیے "ایلیویٹڈ سینڈ باکس" کی اصطلاح استعمال کی ہے. اس حد پر جہاں Codex سسٹم پر کوئی کمانڈ شروع کرتا ہے، بلند اختیارات والا سینڈ باکس غیر بلند اختیارات والے سینڈ باکس جیسا نظر آتا ہے. یہ اب بھی چائلڈ پروسیسز کو ایک محدود ٹوکن کے تحت چلاتا ہے—اسی طرح ایک write_restricted ٹوکن، جس میں [Everyone، Logon، سنتھیٹک]کی وہی محدود SID فہرست ہوتی ہے—تاہم، اس ٹوکن کا پرنسپل اب اصل Windows صارف نہیں رہتا بلکہ Codex کے ذریعے خود بنائے گئے دو مقامی صارفین میں سے ایک ہوتا ہے:

• CodexSandboxOffline (وہ جس پر فائر وال رولز لاگو ہوتے ہیں)
• CodexSandboxOnline (وہ جس پر فائر وال رولز لاگو نہیں ہوتے)

یہ بظاہر چھوٹی سی تفصیل دراصل سینڈ باکس، اسے کون استعمال کر سکتا ہے اور اس کے سیٹ اپ اور رن ٹائم ایگزیکیوشن کی پیچیدگی پر بہت بڑے اثرات ڈالتی ہے.

ظاہری طور پر یہ اَن ایلیویٹڈ پروٹوٹائپ سے مشابہ ہے، بس اس میں فائر وال رولز اور ایک مخصوص Windows یوزر شامل کیا گیا ہے، جو دراصل کمانڈز چلاتا ہے. (تاہم، ان نئے تصورات کے شامل ہونے کا مطلب ہے کہ سینڈ باکس کے کمانڈز چلانے اور ان کی حفاظت کرنے سے پہلے سیٹ اپ کا مزید کام کرنا پڑتا ہے.)

اَن ایلیویٹڈ سینڈ باکس ڈیزائن میں سیٹ اپ کا مرحلہ سادہ تھا، مگر نسبتاً چھوٹا:

• ضرورت پڑنے پر سنتھیٹک SID بنائیں
• سینڈ باکس-رائٹ سنتھیٹک SID کے لیے ACLs اپلائی کریں

تاہم، ایلیویٹڈ سینڈ باکس کو اس سے زیادہ کام کرنا ہوتا ہے.

• ایک سنتھیٹک SID بنائیں، اگر پہلے سے نہیں بنا ہوا ہے
• آن لائن اور آف لائن سینڈ باکس صارفین بنائیں، اگر پہلے سے نہیں بنائے گئے ہیں
• نئے بنائے گئے یوزرز کی کریڈینشلز مقامی طور پر محفوظ کریں اور Windows Data Protection API (DPAPI) کو استعمال کرتے ہوئے انہیں ایسی جگہ انکرپٹ کریں جہاں سینڈ باکس یوزرز حقیقت میں پڑھ نہ سکیں
• ایسے فائر وال رولز بنائیں جو CodexSandboxOffline صارف کے لیے تمام آؤٹ باؤنڈ نیٹ ورک ایکسس کو بلاک کریں یا اگر وہ پہلے سے موجود ہوں تو تصدیق کریں کہ وہ درست ہیں

سیٹ اَپ کے مرحلے میں ایک اضافی پیچیدگی ہے. توقع ہے کہ Codex کے سینڈ باکس کو اصل Windows صارف کے مساوی پڑھنے کی رسائی حاصل ہوگی. غیر بلند اختیارات والے سینڈ باکس میں، جہاں محدود ٹوکن کا اصل SID Windows صارف تھا، یہ حاصل کر لیا گیا. تاہم، جب پرنسپل ایک نیا CodexSandbox صارف بن جاتا ہے تو یہ مفت میں نہیں ملتا. ونڈوز پر کئی متعلقہ ڈائریکٹریز "تصدیق شدہ صارفین" کو پڑھنے/عمل درآمد کی اجازتیں دیتی ہیں. ایک نمایاں مثال صارف کی پروفائل ڈائریکٹری ہے. بطورِ ڈیفالٹ، Windows صارفین دوسرے Windows صارفین کی پروفائل ڈائریکٹریز نہیں پڑھ سکتے، اس لیے بہت سے منظرناموں میں فائل پڑھنے جیسی سادہ کارروائیاں بھی ناکام ہو جائیں گی.

اس مسئلے کے حل کے لیے، ہم نے سینڈ باکس سیٹ اپ پروسس میں ایک اور لیئر شامل کی—ایک ایسی لیئر جو سینڈ باکس یوزرز کو ریڈ ACLs دینے کے لیے تھی، جہاں ایسے ACLs پہلے سے موجود نہ ہوں. مثال کے طور پر، Windows کی عام طور پر استعمال ہونے والی کچھ ڈائریکٹریز میں:

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

چونکہ ڈائریکٹریز کی یہ فہرست بہترین کوشش ہے اور ہر ایک پر ACLs انسٹال کرنا کافی مہنگا ہو سکتا ہے، اس لیے ہم اس لاجک کو غیر ہم وقتی طور پر چلاتے ہیں تاکہ سینڈ باکس سیٹ اپ کا مرحلہ، جو صارفین کے لیے بلاکنگ ہوتا ہے، کو ان کے مکمل ہونے کا انتظار نہ کرنا پڑے.

ہم نے سیٹ اپ لاجک کو جزوی طور پر اس کی اپنی بائنری میں انکیپسولیٹ کیا، تاکہ UAC کی حد کو صرف ضرورت پڑنے پر ہی عبور کیا جائے. لیکن اس کی گہری وجہ معماری سے متعلق تھی: سینڈ باکس سیٹ اپ کا کام بنیادی طور پر codex.exe سے مختلف ہے. سینڈ باکس سیٹ اپ لاجک کو ایک مخصوص بائنری میں رکھنے سے codex.exe ایک نارمل، اَن ایلیویٹڈ ہارنس کے طور پر رہتا ہے؛ Windows-only سیٹ اپ مشینری کو دوسرے پلیٹ فارمز پر codex.exe کے اندر بلوٹنگ سے بچایا جاتا ہے؛ لمبے وقت تک چلنے والے سیٹ اپ کام کو مین پروسیس کی لائف ٹائم سے الگ کیا جاتا ہے؛ اور ہمیں سینڈ باکس کے مختلف سیٹ اپ پاتھز کو ہینڈل کرنے کے لیے ایک واحد جگہ مل جاتی ہے.

Windows یوزر اور ٹوکن لاگ اِن باؤنڈریز کے کام کرنے کے انداز کی وجہ سے، ہم ریسٹرکٹڈ ٹوکن بنا کر اس کے تحت پروسس شروع کرنے کا وہی طریقہ جاری نہیں رکھ سکتے تھے جو اَن ایلیویٹڈ سینڈ باکس میں ممکن تھا. درحقیقت کمانڈز کو ایک مختلف Windows یوزر کے طور پر شروع کرنے کے لیے، ہمارا پہلا خیال یہ فلو تھا:

• codex.exe حقیقی Windows صارف کے طور پر چلتا ہے. پھر، ترتیب وار، Codex:
  • سینڈ باکس صارف کے لیے LogonUserW(...) کو کال کرتا ہے.
  • اس سینڈ باکس-یوزر ٹوکن پر CreateRestrictedToken(...) کو کال کرتا ہے.
  • اس محدود سینڈ باکس-یوزر ٹوکن کا استعمال کرتے ہوئے، حتمی چائلڈ کو لانچ کرنے کے لیے CreateProcessAsUserW(...) کال کرتا ہے.

عملی طور پر، وہ مطلوبہ فلو CreateProcessAsUserW(...) پر اختیارات کی ایک رکاوٹ کی وجہ سے کام نہیں کر سکا. اس کا مطلب ہے کہ codex.exe سینڈ باکس صارف کے لیے ایک محدود ٹوکن بنا سکتا تھا، لیکن وہ حد کے حقیقی صارف والی طرف سے اس ٹوکن کے ساتھ کسی چائلڈ پروسیس کو قابلِ اعتماد طور پر شروع نہیں کر سکتا تھا. ہمیں ایک ایسے پروسیس کی ضرورت تھی جو پہلے ہی سینڈ باکس صارف کے طور پر چل رہا ہو—اس سے پابندی کا مرحلہ اور حتمی پروسیس کا آغاز، حد کے حقیقی صارف والی جانب کے بجائے سینڈ باکس صارف والی جانب انجام پا سکتے تھے.

اسی ضرورت کے نتیجے میں codex-command-runner.exe وجود میں آیا، ایک نئی بائنری جس کا واحد کام ایک محدود ٹوکن جاری کرنا اور درخواست کردہ کمانڈ شروع کرنا ہے. اس کے بجائے کہ ہم codex.exe سے پورا فلو خود کرواتے (حقیقی صارف → سینڈ باکس یوزر → ریسٹرکٹڈ ٹوکن → چائلڈ پروسس)، ہم نے اس فلو کو دو حصوں میں تقسیم کر دیا:

حصہ 1

• codex.exe، CreateProcessWithLogonW(...) کال کر کے codex-command-runner.exe کو سینڈ باکس یوزر کے طور پر شروع کرتا ہے، ابھی ریسٹرکٹڈ ٹوکن استعمال کیے بغیر.

حصہ 2

• رنر کے اندر، OpenProcessToken(GetCurrentProcess(), ...) رنر کا اپنا ٹوکن کھولتا ہے، جو پہلے سے ہی سینڈ باکس یوزر کا ہوتا ہے.
• رنر، سینڈ باکس لاگ ان SID اخذ کرنے کے لیے GetTokenInformation(...) کال کرتا ہے، پھر حتمی ریسٹرکٹڈ ٹوکن بنانے کے لیے CreateRestrictedToken(...) کال کرتا ہے.
• اب بھی رنر کے اندر رہتے ہوئے، وہ اسی ریسٹرکٹڈ ٹوکن کے ساتھ حقیقی چائلڈ شروع کرنے کے لیے CreateProcessAsUserW(...) کال کرتا ہے.

البرٹ آئن سٹائن نے کہا تھا، "ہر چیز کو زیادہ سے زیادہ سادہ ہونا چاہیے، لیکن اس سے زیادہ سادہ نہیں." اسی جذبے کے ساتھ، ہمارے ڈیزائن نے ہر مسئلے کو مناسب طور پر حل کیا. فائنل آرکیٹیکچر میں وہ چار لیئرز شامل ہیں جن پر ہم پہلے بات کر چکے ہیں:

• codex.exe خود
• codex-windows-sandbox-setup.exe تمام ایلیویٹڈ سیٹ اپ سے متعلق کام کو ہینڈل کرنے کے لیے
• codex-command-runner.exe ریسٹرکٹڈ ٹوکن کمانڈز چلانے کے لیے
• چائلڈ پروسس

جب میں نے پہلی بار اس پروجیکٹ پر کام شروع کیا، تو مجھے مضبوط اندازہ نہیں تھا کہ یہ کہاں جا کر ٹھہرے گا. میرا طریقہ یہ تھا کہ Codex اور آپریٹنگ سسٹم کے درمیان موجود باؤنڈری میں سینڈ باکسنگ کیپبیلیٹی کو انسٹرومنٹ کیا جائے. یہ طریقہ اس بات سے قریبی مطابقت رکھتا ہے کہ MacOs اور Linux پر Codex کا سینڈ باکس کیسے نافذ کیا جاتا ہے.

جوں جوں میں نے Windows کے فراہم کردہ مخصوص ٹولز کے بارے میں زیادہ سیکھا اور سیکیورٹی اور استعمال میں آسانی کے درمیان درجنوں فیصلے کیے، یہ سسٹم اپنی موجودہ شکل تک بڑھتا گیا—متعدد بائنریز، کسٹم یوزرس، فائر وال رولز، ایک ایلیویٹڈ سیٹ اپ اسٹیپ، ایسینکرونس پروسیسز اور مزید بہت کچھ.

یہ کوئی خاص طور پر سادہ سسٹم نہیں، مگر پیچیدگی کا ہر جز ضرورت کے تحت شامل کیا گیا، تاکہ ایسا سینڈ باکس بنایا جا سکے جو محفوظ بھی ہو اور حتی الامکان صارف کی راہ میں رکاوٹ بھی نہ بنے.

Windows پر Codex صارفین کے لیے اچھا تجربہ فراہم کرنے کی کوشش میں، ہمارا مقصد کچھ ایسا بنانا تھا جو محفوظ ہو مگر اس سے افادیت کو کوئی خطرہ نہ ہو—Codex استعمال کرنے کا اصل مقصد ہی یہ ہے کہ ایجنٹس آپ کی مسلسل توجہ کے بغیر کام کر سکیں.

اس پروجیکٹ سے ملنے والے سب سے بڑے اسباق میں سے ایک یہ تھا کہ Windows نے ہمیں کوئی ایک ایسا پرمیٹو نہیں دیا جو صاف طور پر "محفوظ خودمختار کوڈنگ ایجنٹ" سے مطابقت رکھتا ہو. ہم نے کئی ٹولز اور تصورات کو ملا کر ایک مربوط چیز بنائی. کچھ ابتدائی خیالات بے نتیجہ ثابت ہوئے. فائنل ڈیزائن دراصل پہلے کے پروٹوٹائپس کے ایک ہائبرڈ کی صورت تھا، جہاں ہر ایک نے مسئلے کے کسی حصے کو حل کیا تھا.

دوسرا سبق یہ تھا کہ کوڈنگ ایجنٹ کے لیے سیکیورٹی، روایتی ایپلیکیشن سیکیورٹی سے مختلف نوعیت رکھتی ہے. Codex کو حقیقی ڈویلپر ورک فلوز کے لیے کارآمد ہونا ہے. انجینئرنگ کا کام ایجنٹک ورک لوڈز کے ساتھ مطابقت اور حقیقی انفورسمنٹ کے درمیان توازن قائم کرنے کے بارے میں تھا. اسی کشمکش نے فائنل ڈیزائن میں سمجھوتوں کی شکل متعین کی.

Codex سینڈ باکس کو کام کرتے دیکھنے کے لیے پُرجوش ہیں؟ اسے آزمائیں⁠.