Windows-এ Codex চালু করতে একটি নিরাপদ, কার্যকর sandbox তৈরি করা

আমি যখন 2025 সালের সেপ্টেম্বর মাসে Codex ইঞ্জিনিয়ারিং টিমে যোগ দিই, তখন Windows-এর জন্য Codex-এ কোনো স্যান্ডবক্স ইমপ্লিমেন্টেশন ছিল না. ফলে OpenAI-এর কোডিং এজেন্ট ব্যবহার করার সময় Windows ব্যবহারকারীদের দুটি অপ্রতুল বিকল্পের একটিকে বেছে নিতে বাধ্য হতে হতো:

1. কোডিং এজেন্ট যে প্রায় প্রতিটি কমান্ড (এমনকি রিড কমান্ডও) চালাতে চাইত, তা অনুমোদন করা হতো, যা অদক্ষ এবং বিরক্তিকর. Codex ব্যবহার করার একটি বড় সুবিধা হলো, আপনাকে সব একঘেয়ে কাজ নিজে করতে হয় না.
2. Full Access মোড সক্রিয় করা: এর মাধ্যমে Codex-কে কোনো অনুমোদন বা বিধিনিষেধ ছাড়াই সমস্ত কমান্ড চালানোর অনুমতি দেওয়া হয়, যা তদারকির বিনিময়ে জটিলতা দূর করে.

Codex⁠, আমাদের কোডিং এজেন্ট, ডেভেলপারদের ল্যাপটপে চলে—সেটা CLI, IDE এক্সটেনশন বা ডেস্কটপ অ্যাপের মাধ্যমেই হোক না কেন. এটি ইনফারেন্স পরিচালনা করতে কীবোর্ডের সামনে থাকা একজন মানুষ এবং ক্লাউডে চলমান একটি মডেলের মধ্যে কথোপকথন পরিচালনা করে.

ডিফল্টরূপে Codex একজন প্রকৃত ব্যবহারকারীর অনুমতি নিয়ে চলে, যার অর্থ হলো ব্যবহারকারী যা যা করতে পারে, Codex তার সবই করতে পারে. এটি শক্তিশালী এবং সম্ভাব্য বিপজ্জনক. কোডিং মডেলটি হারনেসকে স্থানীয়ভাবে বিভিন্ন কমান্ড চালানোর নির্দেশ দিতে পারে, যেমন—টেস্ট চালানো, কোনো ফাইল পড়া বা সম্পাদনা করা, কিংবা একটি গিট ব্রাঞ্চ তৈরি করা. তাই Codex-এর ডিফল্ট মোড কার্যকারিতা এবং নিরাপত্তার মধ্যে সঠিক ভারসাম্য খুঁজে বের করার চেষ্টা করে. এই ডিফল্ট মোড Codex-কে প্রায় যেকোনো জায়গা থেকে ফাইল পড়তে এবং আপনার ওয়ার্কস্পেসের (অর্থাৎ, যে ডিরেক্টরিতে আপনি Codex চালাচ্ছেন) মধ্যে ফাইল লিখতে দেয়; তবে আপনি বিশেষভাবে ইন্টারনেট ব্যবহারের অনুমতি না দিলে এর কোনো ইন্টারনেট সংযোগ থাকে না. নিরাপদ সীমার মধ্যে ফাইল লেখা এবং নেটওয়ার্ক ব্যবহারের এই স্বয়ংক্রিয় সীমাবদ্ধতা অর্জন করতে, Codex-এর একটি স্যান্ডবক্স পরিবেশ প্রয়োজন যা প্রকৃতপক্ষে এই সীমাবদ্ধতাগুলো কার্যকর করে.

স্যান্ডবক্স হলো একটি সীমাবদ্ধ এক্সিকিউশন পরিবেশ. যখন কোনো ডেভেলপার Codex ব্যবহার করেন, তখন তার কম্পিউটারের অপারেটিং সিস্টেম সীমিত অনুমতিসহ একটি কমান্ড চালু করে এবং সেই সীমাবদ্ধতাগুলো প্রসেস ট্রি-এর নিচের দিকেও ছড়িয়ে পড়ে. প্রতিটি Codex কমান্ড শুরু থেকেই স্যান্ডবক্স করা থাকে এবং প্রতিটি অধস্তন প্রসেস একই সীমানার ভেতরে থাকে.

একটি কার্যকর স্যান্ডবক্স বাস্তবায়নের জন্য Codex-এর কম্পিউটারের অপারেটিং সিস্টেম দ্বারা বলবৎকৃত আইসোলেশন বৈশিষ্ট্যের প্রয়োজন হয়. কিছু অপারেটিং সিস্টেম এই কাজটি ভালোভাবে করার জন্য ইউটিলিটি সরবরাহ করে (যেমন, MacOs-এর সিটবেল্ট, Linux-এর সেকম্প বা বাবলর‍্যাপ); তবে, Windows বর্তমানে ডিফল্টভাবে এই ধরনের সক্ষমতা প্রদান করে না.

অন্যান্য সব জায়গার মতো Windows-এও Codex-কে ব্যবহারের জন্য ঠিক ততটাই নিরাপদ ও আনন্দদায়ক করে তুলতে, আমাদের নিজস্ব স্যান্ডবক্স তৈরি করার প্রয়োজন ছিল.

Windows আইসোলেশনের জন্য কিছু টুল এবং প্রিমিটিভ প্রদান করে. যদিও সেগুলোর কোনোটিই আমাদের প্রয়োজনীয়তা পুরোপুরি মেটাতে পারেনি, আমরা বেশ কিছু সম্ভাব্য সমাধান খতিয়ে দেখেছি—যেমন, AppContainer, Windows Sandbox এবং Mandatory Integrity Control লেবেলিং.

AppContainer

• পরিচিতি: AppContainer হলো Windows-এর নিজস্ব স্যান্ডবক্স, যা এমন অ্যাপের জন্য তৈরি একটি ক্যাপাবিলিটি-ভিত্তিক আইসোলেশন মডেল, যারা আগে থেকেই জানে তাদের ঠিক কী অ্যাক্সেস করতে হবে.
• কেন: আকর্ষণীয়, কারণ এটি সর্বাত্মক সীমাবদ্ধতার পরিবর্তে একটি প্রকৃত OS সীমানা প্রদান করে.
• কেন নয়: Codex একটি নির্দিষ্ট সীমিত পরিসরের অ্যাপ নয়. এটি উন্মুক্ত-ধাঁচের ডেভেলপার ওয়ার্কফ্লো পরিচালনা করে: শেল, Git, Python, প্যাকেজ ম্যানেজার, বিল্ড টুল এবং এজেন্টের প্রয়োজন বলে মনে করা অন্য যেকোনো বাইনারি. বাস্তবে, এর ফলে AppContainer সমস্যাটির জন্য ঠিক উপযুক্ত কাঠামো ছিল না. এটি শক্তিশালী আইসোলেশন ছিল, তবে “কোনো এজেন্টকে ডেভেলপারের মতো কাজ করতে দেওয়ার” তুলনায় অনেক বেশি সীমিত শ্রেণির ওয়ার্কলোডের জন্য.

Windows Sandbox

• কী: Windows Sandbox হলো Microsoft-এর ব্যবহার শেষে বাতিলযোগ্য হালকা ভার্চুয়াল মেশিন (VM). আপনি একটি শক্তিশালী আইসোলেশন বাউন্ডারি সহ একটি নতুন Windows ডেস্কটপ পাবেন এবং সেশন শেষ হয়ে গেলে এর ভেতরে করা সমস্ত কাজ অদৃশ্য হয়ে যাবে.
• কেন: সুস্পষ্ট কারণেই এটি আকর্ষণীয়—এটি AppContainer-এর চেয়ে যেকোনো সফটওয়্যারের সাথে অনেক বেশি সামঞ্জস্যপূর্ণ, এবং নিরাপত্তার দৃষ্টিকোণ থেকে এটি একটি অনেক বেশি শক্তিশালী কাঠামো.
• কেন নয়: Codex-কে ব্যবহারকারীর প্রকৃত চেকআউট, টুলস এবং এনভায়রনমেন্টের উপর সরাসরি কাজ করতে হবে, কোনো আলাদা, ফেলে দেওয়ার মতো ডেস্কটপের ভেতরে নয়, যেটির জন্য সেটআপ এবং হোস্ট/গেস্ট ব্রিজিংয়ের প্রয়োজন হবে. এটির আরও একটি মৌলিক পণ্যগত সমস্যা ছিল: Windows Sandbox এমনকি Windows Home SKU-গুলোতেও উপলভ্য নয়.

অপরিহার্য আস্থা নিয়ন্ত্রণ (MIC) আস্থা লেবেলিং

• কী: Windows-এ “ইন্টেগ্রিটি লেভেল” নামে একটি ধারণা রয়েছে, যেমন নিম্ন, মাঝারি ও উচ্চ, যা নির্ধারণ করে সিস্টেম অবজেক্ট ও প্রসেসগুলোকে কতটা বিশ্বাস করবে. মৌলিক নিয়ম হলো, একটি নিম্ন-ইন্টেগ্রিটি প্রসেস উচ্চতর ইন্টেগ্রিটি স্তরযুক্ত কোনো অবজেক্টে লিখতে পারে না, এমনকি স্বাভাবিক ACL অন্যথায় সেটি অনুমোদন করলেও. উদাহরণস্বরূপ, একটি নিম্ন-ইন্টেগ্রিটি প্রসেসকে কম বিশ্বস্ত হিসেবে বিবেচনা করা হয়, তাই Windows সেটিকে সাধারণ মাঝারি-ইন্টেগ্রিটি অবজেক্টে লিখতে বাধা দেয়, যদি না ঐ অবজেক্টগুলোকে সেটিকে অনুমতি দেওয়ার জন্য স্পষ্টভাবে পুনরায় লেবেল করা হয়.
• কারণ: কাগজে-কলমে MIC বেশ চমৎকার মনে হয়েছিল—Codex-কে নিম্ন ইন্টিগ্রিটিতে চালানো, লেখার যোগ্য রুটগুলোকে নিম্ন ইন্টিগ্রিটি হিসেবে পুনরায় লেবেল করা এবং বাকি সব জায়গায় Windows-কে নো-রাইট প্রয়োগ করতে দেওয়া. এতে আমরা একটি নন-অ্যাডমিন উপায় পেতাম, যার পেছনে বাস্তব OS মেকানিজম থাকত.
• কেন নয়: ACL-এর মতো, ইন্টেগ্রিটি লেবেলগুলো প্রকৃত হোস্ট ফাইলসিস্টেমকে পরিবর্তন করে এবং এই ক্ষেত্রে অর্থগত পরিবর্তনটি বিশেষভাবে ব্যাপক. কোনো ওয়ার্কস্পেসকে নিম্ন ইন্টেগ্রিটি হিসেবে চিহ্নিত করার অর্থ শুধু “Codex এখানে লিখতে পারে” নয়. এর মানে হলো, নিম্ন-ইন্টেগ্রিটি প্রসেসগুলো সাধারণভাবে সেখানে লিখতে পারে. প্রকৃত ডেভেলপার মেশিনে, এটি ব্যবহারকারীর আসল চেকআউটকে হোস্টের জন্য একটি লো-ইন্টেগ্রিটি সিঙ্কে পরিণত করে, যা একটি নির্দিষ্ট স্যান্ডবক্স ডিজাইনে সতর্কভাবে লক্ষ্যযুক্ত ACL মঞ্জুর করার চেয়ে অনেক বেশি ঝুঁকিপূর্ণ. মিডিয়াম-ইন্টেগ্রিটি ডেভেলপার টুলগুলো কাজ করতে থাকলেও, ওয়ার্কস্পেসের অন্তর্নিহিত ট্রাস্ট মডেল এমনভাবে বদলে গেছে যা নিয়ন্ত্রণে রাখা কঠিন এবং যার পক্ষে যুক্তি দেওয়া আরও কঠিন.

সমস্ত বিকল্প অকার্যকর বলে মূল্যায়ন করার পর, আমরা Windows ব্যবহারকারীদের একটি ভালো Codex অভিজ্ঞতা দেওয়ার জন্য আমাদের নিজস্ব সমাধান ডিজাইন করতে শুরু করলাম.

আমাদের প্রথম কার্যকর প্রোটোটাইপে আমাদের প্রয়োজনীয় আইসোলেশন বাস্তবায়ন করতে Windows-এর ধারণা ও টুলের সমন্বয় ব্যবহার করা হয়েছিল. শুরু থেকেই একটি লক্ষ্য ছিল এলিভেশনের প্রয়োজন ছাড়াই এটি কার্যকর করা, যার অর্থ হলো, শুধুমাত্র স্যান্ডবক্স সেট আপ বা চালানোর জন্য Codex-কে ব্যবহারকারীর কাছে অ্যাডমিনিস্ট্রেটর প্রিভিলেজের অনুমতি চাইতে হবে না. এর অর্থ ছিল দুটি বিষয়ে যুক্তিসংগত সীমা কিভাবে আরোপ করা যায় তা নির্ধারণ করা: ফাইল লেখা এবং নেটওয়ার্ক অ্যাক্সেস.

যদি আমরা ফাইল রাইট একেবারেই সীমিত না করতাম, তাহলে একটি নিরাপত্তাজনিত সমস্যা দেখা দিত. আবার যদি আমরা ফাইল রাইট খুব বেশি সীমিত করে দিতাম, তাহলে ক্রমাগত অনুমোদনের প্রয়োজন হওয়ায় স্যান্ডবক্সটি ব্যবহারকারীর কর্মদক্ষতায় বাধা সৃষ্টি করত. এই সমস্যাটি সমাধান করার জন্য, আমরা Windows-এর দুটি গুরুত্বপূর্ণ মৌলিক উপাদানের উপর নির্ভর করেছি: SID এবং রাইট-রেস্ট্রিক্টেড টোকেন.

SID বা নিরাপত্তা শনাক্তকারী, হলো সেই পরিচয় যা Windows অনুমতিগুলোর সঙ্গে যুক্ত করে. প্রত্যেক ব্যবহারকারীর একটি SID থাকে, গ্রুপগুলোর SID থাকে এবং এমনকি একটি একক লগইন সেশনও নিজস্ব SID পায়. উদাহরণস্বরূপ, বর্তমানে লগইন করা কোনো সেশনে S-1-5-5-X-Y-এর মতো একটি SID থাকতে পারে. স্থানীয় প্রশাসক গোষ্ঠীর জন্য নির্ধারিত SID হতে পারে S-1-5-32-544.

Windows আপনাকে সিন্থেটিক SID তৈরি করার সুযোগও দেয়, যা কোনো প্রকৃত ব্যবহারকারীর সাথে সম্পর্কিত নয়, কিন্তু ACL (অ্যাক্সেস কন্ট্রোল লিস্ট)-এ অন্তর্ভুক্ত হতে পারে. এই ACL নির্ধারণ করে দেয় যে, কে নির্দিষ্ট ফাইল বা ডিরেক্টরি পড়তে, লিখতে বা এক্সিকিউট করতে পারবে. এই কারণে SID আমাদের স্যান্ডবক্সের জন্য একটি কার্যকরী প্রাথমিক উপাদান: আমরা মেশিনের অন্য কোনো কিছুতে হস্তক্ষেপ না করেই, শুধুমাত্র Codex স্যান্ডবক্সের ব্যবহারের জন্য SID তৈরি করতে পারি.

প্রসেস টোকেন হলো Windows-এর নিরাপত্তা অবজেক্ট, যা একটি চলমান প্রসেসের পরিচয় ও বিশেষাধিকার নির্ধারণ করে. এগুলো নির্ধারণ করে যে একটি প্রসেস কোন কোন কাজ করতে পারে. একটি রাইট-রেস্ট্রিক্টেড টোকেন হলো এক বিশেষ ধরনের প্রসেস টোকেন, যার ফলে Windows লিখন অপারেশনগুলিতে একটি অতিরিক্ত অ্যাক্সেস পরীক্ষা সম্পাদন করে.

একটি রাইট সফল হওয়ার জন্য, দুটি যাচাই অবশ্যই উত্তীর্ণ হতে হবে:

1. সাধারণ ব্যবহারকারীর পরিচয় (টোকেন “মালিক”) এটি করার জন্য অনুমোদিত হতে হবে.
2. টোকেনের সীমাবদ্ধ SID তালিকার অন্তত একটি SID-কেও অ্যাক্সেস দেওয়া থাকতে হবে

বাস্তবে, এই চেকগুলো আমাদেরকে ACL ব্যবহার করে সুনির্দিষ্টভাবে নির্ধারণ করতে দেয় যে স্যান্ডবক্সটি ফাইলসিস্টেম কোথায় পরিবর্তন করতে পারবে, যা রাইট অপারেশনের ক্ষেত্রে আমাদের প্রয়োজনীয় সূক্ষ্ম নিয়ন্ত্রণ প্রদান করে.

SID এবং রাইট-রেস্ট্রিকটেড টোকেন ব্যবহার করে আমাদের আনএলিভেটেড স্যান্ডবক্সটি এইভাবে কাজ করত:

1. স্যান্ডবক্স সেটআপটি স্যান্ডবক্স-রাইট নামে একটি সিন্থেটিক SID তৈরি করেছে.
2. স্যান্ডবক্স-রাইট SID-কে রাইট, এক্সিকিউট এবং ডিলিট অ্যাক্সেস দেওয়া হয়েছিল.
   1. বর্তমান ওয়ার্কিং ডিরেক্টরি
   2. config.toml -এ কনফিগার করা যেকোনো অতিরিক্ত writable_roots.
3. স্যান্ডবক্স সেটআপটি স্পষ্টভাবে সেই একই SID-কে “লেখার যোগ্য স্থানের মধ্যে শুধুমাত্র পঠনযোগ্য” স্থানগুলিতে লেখার অ্যাক্সেস অস্বীকার করেছে, যেমন:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex একটি রাইট-রেস্ট্রিক্টেড টোকেনের অধীনে কমান্ড চালু করেছে, যার রেস্ট্রিক্টেড SID লিস্টে Everyone, বর্তমান লগ-ইন করা সেশনের SID এবং স্যান্ডবক্স-রাইট সিন্থেটিক SID অন্তর্ভুক্ত রয়েছে.

এই কার্যপ্রবাহটি ফাইল রাইট সীমিত করার সমস্যার কার্যকর সমাধান করেছিল এবং আশাব্যঞ্জক বলে মনে হচ্ছিল. এখন আমাদের স্যান্ডবক্সের নেটওয়ার্ক অ্যাক্সেস সীমিত করার জন্য একটি সমাধান প্রয়োজন ছিল.

নেটওয়ার্ক অ্যাক্সেস সীমিত করা স্যান্ডবক্সের একটি গুরুত্বপূর্ণ অংশ; এটি ছাড়া ক্ষতিকারক কোড মেশিন থেকে ডেটা পাচার করে ইন্টারনেটে পাঠিয়ে দিতে পারত. যেহেতু আমরা এলিভেশন রিকোয়ারমেন্ট এড়াতে চেয়েছিলাম, তাই নেটওয়ার্ক ট্র্যাফিক কঠোরভাবে ব্লক করার জন্য আমাদের কাছে সীমিত বিকল্প ছিল. আমরা যে টুলগুলো ব্যবহার করতে চেয়েছিলাম, যেমন Windows Firewall, সেগুলো সাধারণত অ্যাডমিন পারমিশন ছাড়া ইনস্টল করা যেত না.

Windows Firewall বিকল্প হিসেবে না থাকায়, আমরা যা নিয়ন্ত্রণ করতে পারতাম তা সীমিত করে ফেলেছিলাম. আমরা চেষ্টা করেছি চাইল্ড এনভায়রনমেন্টটিকে এমন ধরনের নেটওয়ার্ক-নির্ভর টুলের জন্য ফেইল-ক্লোজড করতে, যেগুলো ডেভেলপাররা বাস্তবে ব্যবহার করেন, যাতে Git কমান্ড, প্যাকেজ ইনস্টলার ইত্যাদি স্যান্ডবক্সে ব্যর্থ হয় এবং ব্যবহারকারীকে যেকোনো ইন্টারনেটমুখী অপারেশন অনুমোদন করতে হয়. ধারণাটি ছিল স্পষ্ট পালানোর পথগুলো ইচ্ছাকৃতভাবে অকার্যকর করে দেওয়া: প্রক্সি-সচেতন ট্র্যাফিককে একটি অকার্যকর এন্ডপয়েন্টে পাঠানো, Git-এর HTTP(S) ট্রান্সপোর্টকেও একই কাজ করতে বাধ্য করা এবং SSH-এর মাধ্যমে Git যেন তৎক্ষণাৎ ব্যর্থ হয় তা নিশ্চিত করা. এর পাশাপাশি, আমরা PATH-এর শুরুতে ছোট একটি denybin ডিরেক্টরি যোগ করেছি এবং 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-এর কয়েকটি সাধারণ ক্ষমতা ব্যবহার করেই কাজ সারত, ফাইলসিস্টেমে অত্যন্ত সুস্পষ্ট ও সুনির্দিষ্টভাবে লেখার সুযোগ দিত এবং কোনো বিশেষ অনুমতি ছাড়াই চলত—যার ফলে ব্যবহারকারীদের অতিরিক্ত এলিভেশন প্রম্পট গ্রহণ করতে বা তাদের লোকাল মেশিনে অ্যাডমিন হওয়ার প্রয়োজন পড়ত না—তবুও এর কিছু প্রকৃত অসুবিধা ছিল, যার কয়েকটির কারণে এটি আমাদের চূড়ান্ত নকশা হওয়ার যোগ্যতা হারিয়েছিল:

• সেটআপের গতি: ওয়ার্কস্পেস ACL প্রয়োগ করা ওয়ার্কস্পেস ডিরেক্টরির টপোলজির উপর নির্ভর করে ব্যয়বহুল হতে পারে.
• ফুটপ্রিন্ট: আমরা ডেভেলপারের সিস্টেমে আসল ACL প্রয়োগ করেছি, যদিও এর ফুটপ্রিন্ট খুব বেশি হস্তক্ষেপমূলক নয়, কারণ প্রয়োগকৃত সমস্ত ACL একটি বিশেষভাবে তৈরি সিন্থেটিক SID-এর সাথে সম্পর্কিত যা শুধুমাত্র স্যান্ডবক্স দ্বারা ব্যবহৃত হয়.
• পরিবর্তন করা কঠিন সেমান্টিকস: ফাইল-ভিত্তিক বিধিনিষেধের জন্য ACL-এর উপর নির্ভরশীলতার অর্থ হলো স্যান্ডবক্স সেমান্টিকস পরিবর্তন করা ব্যয়বহুল এবং জটিল. যেখানে macOS-এ আমরা Seatbelt কনফিগার করার জন্য ব্যবহৃত .sbpl ফাইলটি যেভাবে তৈরি হয় তা ডাইনামিকভাবে পরিবর্তন করতে পারি, সেখানে Windows স্যান্ডবক্সের ক্ষেত্রে ACL-গুলি অ্যাডজাস্ট বা সমন্বয় করার জন্য একটি ধীরগতির এবং জটিল প্রক্রিয়ার প্রয়োজন হতে পারে.
• নেটওয়ার্ক সুরক্ষা দুর্বল. যেমনটি আগে উল্লেখ করা হয়েছে, এটি ছিল একটি “পরামর্শমূলক” ব্যবস্থা, যা নিজস্ব নেটওয়ার্কিং স্ট্যাক প্রয়োগকারী কিছু প্রোগ্রাম দ্বারা অবশ্যই এড়িয়ে যাওয়া যেত এবং এটি প্রতিপক্ষীয় কোডের মোকাবিলা করার জন্য ডিজাইন করা হয়নি.

প্রথম তিনটি সমস্যা একটি কাস্টম স্যান্ডবক্স বাস্তবায়নের সহজাত বৈশিষ্ট্য, যা এজেন্টিক ফ্লো-এর জন্য যথেষ্ট নমনীয়. তবে, নেটওয়ার্ক দমনের বিষয়টি ছিল ভিন্ন.

একটি ক্ষতিকারক এজেন্ট যেমন সহজেই পরিবেশ-ভিত্তিক নেটওয়ার্ক দমন ব্যবস্থা এড়িয়ে যেতে পারে, তেমনি অনেক সৎ উদ্দেশ্য প্রণোদিত কোড/বাইনারিও এটিকে সহজেই এড়িয়ে যেতে পারত, যদি তারা এনভায়রনমেন্ট প্রক্সি ভেরিয়েবলগুলো মেনে না চলত অথবা যদি তারা তাদের নিজস্ব সকেট-ভিত্তিক নেটওয়ার্ক কোড প্রয়োগ করত. আমরা মনে করেছি যে, একটি উন্নততর স্যান্ডবক্স মোডে বিনিয়োগ করার কথা বিবেচনা করার জন্য এই দিকটিই যথেষ্ট ছিল.

আরও ভালো নেটওয়ার্ক দমন ব্যবস্থা পাওয়ার জন্য, আমরা Windows Firewall ব্যবহার করতে চেয়েছিলাম, যা ব্যবহারকারী বা প্রোগ্রামের জন্য বহির্গামী নেটওয়ার্ক ট্র্যাফিক ব্লক করার সুযোগ দেয়. দুর্ভাগ্যবশত, কয়েকটি কারণে আমরা এমন কোনো কার্যকরী ফায়ারওয়াল নিয়ম তৈরি করতে পারিনি যা শুধুমাত্র Codex হারনেস দ্বারা উৎপাদিত কমান্ডগুলোর ক্ষেত্রেই প্রযোজ্য হবে:

• Windows একটি সীমাবদ্ধ টোকেনের অপ্রধান পরিচয়ের সাথে কোনো ফায়ারওয়াল নিয়ম মেলানোর অনুমতি দেয় না. এর মানে হলো, আমরা এমন কোনো টোকেনে ফায়ারওয়াল নিয়ম প্রয়োগ করতে পারিনি, যার সীমাবদ্ধ SID তালিকায় আমাদের সিন্থেটিক SID অন্তর্ভুক্ত রয়েছে.
• যদিও আমরা একটি নির্দিষ্ট বাইনারির সাথে মেলে এমন একটি ফায়ারওয়াল নিয়ম তৈরি করতে পারি, তবে সেটি কেবল codex.exe জন্যই নেটওয়ার্কিং সীমিত করার সুযোগ দেয়. এটি ব্যবহারকারীর পক্ষ থেকে এজেন্ট যে প্রসেসগুলো চালু করে—যেমন Git বা Python প্রসেস—সেগুলোর ক্ষেত্রে প্রযোজ্য হবে না.
• অন্যান্য ফায়ারওয়াল ম্যাচ ডাইমেনশনগুলোও ভুল কাঠামোর ছিল. আনএলিভেটেড ডিজাইনে ইউজার-স্কোপড রুলগুলো শুধু রেস্ট্রিকটেড চাইল্ড ইউজারের সাথেই নয়, বরং আসল Windows ইউজারের সাথেও ম্যাচ করত. প্রোগ্রাম-পাথের নিয়মগুলো অতিরিক্ত মোটা দাগের ছিল: সেগুলো সাধারণভাবে codex.exe বা python.exe ব্লক করতে পারত, কিন্তু python.exe-এর এই নির্দিষ্ট স্যান্ডবক্স করা ইনভোকেশনটি ব্লক করতে পারত না. পোর্ট- বা ঠিকানা-ভিত্তিক নিয়মগুলোও ছিল পুরোপুরি ভুল নীতি. উদাহরণস্বরূপ, আমরা পোর্ট 443 ব্লক করতে চাইনি; আমরা এই নির্দিষ্ট সীমাবদ্ধ প্রসেস ট্রির জন্য নির্বিচার বহির্গামী অ্যাক্সেস ব্লক করতে চেয়েছিলাম.

আমাদের স্যান্ডবক্স করা কমান্ডগুলোতে বিশেষভাবে একটি ফায়ারওয়াল নিয়ম প্রয়োগ করার জন্য, সেগুলোকে "আসল" ব্যবহারকারী হিসেবে নয়, বরং একটি পৃথক প্রিন্সিপাল হিসেবে চালানোর প্রয়োজন ছিল. এই পদ্ধতিটি আমাদের একটি নতুন পথে চালিত করে, যেখানে আমরা আমাদের "এলিভেশন নেই" এই সীমাবদ্ধতাটি শিথিল করেছিলাম.

স্যান্ডবক্সের পরবর্তী ইটারেশনটি, যা আমাদের বর্তমান বাস্তবায়ন, সেটআপের সময় উচ্চতর অ্যাডমিন অনুমতির প্রয়োজন হয়. তাই আমি একে “এলিভেটেড স্যান্ডবক্স” বলে উল্লেখ করি. সিস্টেমে Codex যেখানে একটি কমান্ড স্পন করে, সেই সীমানায় উচ্চতর-সুবিধাপ্রাপ্ত স্যান্ডবক্সটি উচ্চতর-সুবিধাহীন স্যান্ডবক্সের মতোই দেখায়. এটি এখনও চাইল্ড প্রসেসগুলো একটি সীমাবদ্ধ টোকেনের অধীনে চালায়—একইভাবে একটি write_restricted টোকেন, যার [Everyone, Logon, Synthetic]একই সীমাবদ্ধ SID তালিকা আছে—তবে, এই টোকেনের প্রিন্সিপাল আর প্রকৃত Windows ব্যবহারকারী নয়, বরং Codex নিজেই তৈরি করা দুটি স্থানীয় ব্যবহারকারী অ্যাকাউন্টের একটি:

• CodexSandboxOffline (যেটি ফায়ারওয়াল নিয়ম দ্বারা লক্ষ্যবস্তু করা হয়)
• CodexSandboxOnline (যেটি ফায়ারওয়াল নিয়মের আওতাভুক্ত নয়)

এই আপাতদৃষ্টিতে ছোট বিবরণটি আসলে স্যান্ডবক্স, কারা এটি ব্যবহার করতে পারবে এবং এর সেটআপ ও রানটাইম এক্সিকিউশনের জটিলতার উপর বড় প্রভাব ফেলে.

এটি দেখতে সাধারণ প্রোটোটাইপের মতোই, তবে এতে ফায়ারওয়াল নিয়ম এবং একটি ডেডিকেটেড উইন্ডোজ ইউজার যুক্ত করা হয়েছে, যেটি আসলে কমান্ডগুলো চালায়. (তবে, এই নতুন ধারণাগুলোর সংযোজনের ফলে, স্যান্ডবক্সটি চালানো এবং কমান্ডগুলোকে সুরক্ষিত করা শুরু করার আগে আরও বেশি সেটআপের কাজ করতে হবে.)

সাধারণ স্যান্ডবক্স ডিজাইনটির সেটআপ ধাপটি সহজ ছিল, কিন্তু সেটি তুলনামূলকভাবে ছোট ছিল:

• প্রয়োজন হলে একটি সিন্থেটিক SID তৈরি করা
• স্যান্ডবক্স-রাইট সিন্থেটিক SID-এর জন্য ACL প্রয়োগ করা

তবে, উন্নীত স্যান্ডবক্সটিতে আরও অনেক কিছু করার আছে.

• আগে থেকে তৈরি না থাকলে একটি সিন্থেটিক SID তৈরি করা
• অনলাইন এবং অফলাইন স্যান্ডবক্স ব্যবহারকারী তৈরি করা, যদি আগে থেকে তৈরি করা না থাকে
• নতুন তৈরি করা ব্যবহারকারীদের ক্রেডেনশিয়ালগুলি স্থানীয়ভাবে সংরক্ষণ করা এবং Windows Data Protection API (DPAPI) ব্যবহার করে এমন একটি জায়গায় এনক্রিপ্ট করা যেখানে স্যান্ডবক্স ব্যবহারকারীরা আসলে তা পড়তে পারবে না.
• এমন ফায়ারওয়াল নিয়ম তৈরি করা যা CodexSandboxOffline ব্যবহারকারীর জন্য সমস্ত বহির্গামী নেটওয়ার্ক অ্যাক্সেস ব্লক করে, অথবা যদি সেগুলি আগে থেকেই বিদ্যমান থাকে, তবে সেগুলি সঠিক কিনা তা যাচাই করা.

সেটআপ পর্যায়ে আরও একটি জটিলতা রয়েছে. Codex-এর স্যান্ডবক্সে প্রকৃত Windows ব্যবহারকারীর সমতুল্য রিড অ্যাক্সেস থাকবে বলে প্রত্যাশিত. উচ্চতর অনুমতিবিহীন স্যান্ডবক্সে, যেখানে সীমাবদ্ধ টোকেনের প্রিন্সিপাল SID ছিল Windows ব্যবহারকারী, এটি অর্জন করা হয়েছিল. তবে, প্রিন্সিপাল যখন নতুন CodexSandbox ব্যবহারকারী হয়ে যায়, তখন সেটি বিনা খরচে আসে না. Windows-এ অনেক প্রাসঙ্গিক ডিরেক্টরি “Authenticated Users”-কে পড়া/চালানোর অনুমতি দেবে. একটি উল্লেখযোগ্য উদাহরণ হলো ব্যবহারকারীর প্রোফাইল ডিরেক্টরি. ডিফল্টভাবে, Windows ব্যবহারকারীরা অন্য Windows ব্যবহারকারীদের প্রোফাইল ডিরেক্টরিগুলো পড়তে পারেন না, তাই অনেক পরিস্থিতিতে সাধারণ ফাইল পড়ার অপারেশনও ব্যর্থ হবে.

এর সমাধান করতে, আমরা স্যান্ডবক্স সেটআপ প্রক্রিয়ায় আরেকটি স্তর যুক্ত করেছি—যাতে স্যান্ডবক্স ব্যবহারকারীদের রিড ACL প্রদান করা যায়, যেখানে এই ধরনের ACL আগে থেকে বিদ্যমান নাও থাকতে পারে. যেমন, সাধারণত ব্যবহৃত কিছু Windows ডিরেক্টরিতে:

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

যেহেতু ডিরেক্টরিগুলোর এই তালিকাটি বেস্ট-এফোর্ট পদ্ধতিতে তৈরি এবং প্রতিটিতে ACL ইনস্টল করা বেশ ব্যয়বহুল হতে পারে, তাই আমরা এই লজিকটি অ্যাসিঙ্ক্রোনাসভাবে চালাই. এর ফলে স্যান্ডবক্স সেটআপ ধাপটি, যা ব্যবহারকারীদের জন্য ব্লকিং, তাদের কাজ শেষ হওয়ার জন্য অপেক্ষা করতে হয় না.

আমরা সেটআপ লজিকটিকে নিজস্ব বাইনারির মধ্যে আবদ্ধ করেছি, আংশিকভাবে যাতে শুধুমাত্র প্রয়োজন হলেই UAC সীমারেখা অতিক্রম করতে হয়. তবে গভীরতর কারণটি ছিল আর্কিটেকচারগত: স্যান্ডবক্স সেটআপের কাজ codex.exe-এর কাজ থেকে মৌলিকভাবে আলাদা. স্যান্ডবক্স সেটআপ লজিকটি একটি ডেডিকেটেড বা নির্দিষ্ট বাইনারিতে রাখার ফলে codex.exe-কে একটি সাধারণ, আন-এলিভেটেড (উচ্চতর প্রিভিলেজহীন) হার্নেস হিসেবে রাখা সম্ভব হয়েছে; এটি অন্যান্য প্ল্যাটফর্মে উইন্ডোজ-ভিত্তিক সেটআপ মেকানিজমের কারণে codex.exe-এর সাইজ বা মেমোরি অতিরিক্ত বৃদ্ধি পাওয়া থেকে রক্ষা করেছে; দীর্ঘ সময় ধরে চলা সেটআপের কাজগুলোকে মূল প্রসেসের লাইফটাইম বা জীবনকাল থেকে আলাদা করেছে; এবং স্যান্ডবক্সের জন্য প্রয়োজনীয় বিভিন্ন সেটআপ পাথগুলো একসাথে এক জায়গায় হ্যান্ডেল বা পরিচালনা করার সুবিধা দিয়েছে.

Windows ব্যবহারকারী এবং টোকেন লগইন সীমানা যেভাবে কাজ করে, তার কারণে আমরা আনএলিভেটেড স্যান্ডবক্সের মতো একটি সীমাবদ্ধ টোকেন তৈরি করে তার অধীনে একটি প্রসেস চালু করার কাজটি চালিয়ে যেতে পারিনি. প্রকৃতপক্ষে একজন ভিন্ন Windows ব্যবহারকারী হিসেবে কমান্ড চালু করার জন্য, আমাদের প্রথম পরিকল্পনাটি ছিল নিম্নরূপ:

• codex.exe প্রকৃত Windows ব্যবহারকারী হিসেবে চলে. এরপর, ধারাবাহিকভাবে, Codex:
  • স্যান্ডবক্স ব্যবহারকারীর জন্য LogonUserW(...) কল করে.
  • ঐ স্যান্ডবক্স-ব্যবহারকারী টোকেনের উপর CreateRestrictedToken(...) কল করা হয়.
  • সেই সীমাবদ্ধ স্যান্ডবক্স-ব্যবহারকারী টোকেনটি ব্যবহার করে, চূড়ান্ত চাইল্ডটি চালু করার জন্য CreateProcessAsUserW(...) কল করা হয়.

বাস্তবে, CreateProcessAsUserW(...)-এ একটি প্রিভিলেজ-সংক্রান্ত বাধার কারণে সেই কাঙ্ক্ষিত ফ্লোটি কাজ করেনি. এর অর্থ হলো codex.exe স্যান্ডবক্স ব্যবহারকারীর জন্য একটি সীমাবদ্ধ টোকেন তৈরি করতে পারত, কিন্তু সীমানার প্রকৃত-ব্যবহারকারী পাশ থেকে সেই টোকেন দিয়ে নির্ভরযোগ্যভাবে একটি চাইল্ড প্রসেস চালু করতে পারত না. আমাদের এমন একটি প্রক্রিয়া দরকার ছিল যা ইতিমধ্যেই স্যান্ডবক্স ব্যবহারকারী হিসেবে চলছিল—এতে সীমাবদ্ধতা আরোপের ধাপটি এবং চূড়ান্ত স্পনটি সীমানার প্রকৃত-ব্যবহারকারী দিকের পরিবর্তে স্যান্ডবক্স-ব্যবহারকারী দিকেই ঘটতে পারত.

সেই প্রয়োজনীয়তার ফলেই তৈরি হয়েছে codex-command-runner.exe, একটি নতুন বাইনারি যার একমাত্র কাজ হলো একটি সীমাবদ্ধ টোকেন তৈরি করা এবং অনুরোধ করা কমান্ড চালু করা. codex.exe সম্পূর্ণ প্রবাহটি (আসল ব্যবহারকারী → স্যান্ডবক্স ব্যবহারকারী → সীমাবদ্ধ টোকেন → চাইল্ড প্রসেস) নিজে থেকে করতে বলার পরিবর্তে, আমরা প্রবাহটিকে দুটি ভাগে ভাগ করেছি:

পর্ব 1

• codex.exe এখনও কোনো সীমাবদ্ধ টোকেন ব্যবহার না করেই, স্যান্ডবক্স ব্যবহারকারী হিসেবে codex-command-runner.exe চালু করার জন্য CreateProcessWithLogonW(...) কল করে.

পর্ব 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 স্যান্ডবক্সটি বাস্তবে কাজ করতে দেখতে আগ্রহী? পরীক্ষা করে দেখুন⁠.