Windows တွင် Codex ကို အသုံးပြုနိုင်စေရန် ဘေးကင်း၍ ထိရောက်သော sandbox တစ်ခု တည်ဆောက်ခြင်း

2025 ခုနှစ် စက်တင်ဘာလတွင် ကျွန်ုပ် Codex အင်ဂျင်နီယာအဖွဲ့သို့ ဝင်ရောက်ခဲ့ချိန်တွင်၊ Windows အတွက် Codex တွင် sandbox အကောင်အထည်ဖော်မှု မရှိသေးပါ။ ဆိုလိုသည်မှာ OpenAI ၏ ကုဒ်ရေးအေးဂျင့်များကို အသုံးပြုသည့်အခါ Windows အသုံးပြုသူများသည် အဆင့်မမီသော ရွေးချယ်စရာနှစ်ခုအနက်မှ မဖြစ်မနေ ရွေးချယ်ရခဲ့သည်-

1. ကုဒ်ရေးအေးဂျင့်က လုပ်ဆောင်လိုသော command နီးပါးတိုင်းကို (ဖတ်ရှုရေး command များပင်) အတည်ပြုနေရခြင်းသည် ထိရောက်မှုမရှိသည့်အပြင် စိတ်အနှောင့်အယှက်ဖြစ်စေသည်။ Codex ကို အသုံးပြုခြင်း၏ အဓိကအကျိုးကျေးဇူးတစ်ခုမှာ ပင်ပန်းငြီးငွေ့စရာအလုပ်အားလုံးကို သင်ကိုယ်တိုင် လုပ်စရာမလိုခြင်း ဖြစ်သည်။
2. အပြည့်အဝ ဝင်ရောက်ခွင့်မုဒ်ကို ဖွင့်ခြင်း - Codex ကို အတည်ပြုချက် (သို့မဟုတ်) ကန့်သတ်ချက်များ မလိုဘဲ command အားလုံးကို လုပ်ဆောင်ခွင့်ပြုခြင်းဖြစ်ပြီး၊ ၎င်းက ကြီးကြပ်စောင့်ကြည့်မှုကို လျော့နည်းစေသော်လည်း အတားအဆီးများကို ဖယ်ရှားပေးသည်။

Codex⁠ သည် ကျွန်ုပ်တို့၏ ကုဒ်ရေးအေးဂျင့်ဖြစ်ပြီး CLI (Command Line Interface) မှတစ်ဆင့်ဖြစ်စေ၊ IDE တိုးချဲ့မှုမှတစ်ဆင့်ဖြစ်စေ၊ ဒက်စ်တော့ပ် အက်ပ်မှတစ်ဆင့်ဖြစ်စေ developer များ၏ လက်ပ်တော့များပေါ်တွင် လည်ပတ်ပါသည်။ ၎င်းသည် အချက်အလက်အဖြေထုတ်လုပ်ဆောင်မှုကို ကိုင်တွယ်ရန် ကီးဘုတ်ရှေ့ရှိ လူသားနှင့် ကလောက်ဒ်တွင် လည်ပတ်နေသော မော်ဒယ်အကြား စကားပြောဆိုမှုကို စီမံခန့်ခွဲသည်။

Codex သည် မူရင်းအားဖြင့် တကယ့်အသုံးပြုသူတစ်ဦး၏ ခွင့်ပြုချက်များဖြင့် လည်ပတ်သောကြောင့်၊ အသုံးပြုသူ လုပ်နိုင်သမျှ အရာအားလုံးကို လုပ်ဆောင်နိုင်သည်။ ၎င်းသည် အစွမ်းထက်ပြီး အန္တရာယ်ရှိနိုင်ပါသည်။ ကုဒ်ရေး မော်ဒယ်သည် tests များကို လုပ်ဆောင်ခြင်းမှစ၍ ဖိုင်တစ်ခုကို ဖတ်ခြင်း၊ တည်းဖြတ်ခြင်း၊ Git branch တစ်ခု ဖန်တီးခြင်းအထိ command များကို စက်တွင်း၌ လုပ်ဆောင်ရန် harness ကို ညွှန်ကြားနိုင်သောကြောင့်၊ Codex ၏ မူလမုဒ်သည် ထိရောက်မှုနှင့် လုံခြုံမှုအကြား သင့်လျော်သော ဟန်ချက်ကို ရှာဖွေရန် ကြိုးစားသည်။ ဤမူလသတ်မှတ်ထားသော မုဒ်သည် Codex အား နေရာတိုင်းနီးပါးရှိ ဖိုင်များကို ဖတ်နိုင်စေပြီး၊ သင်၏ အလုပ်နေရာ (ဆိုလိုသည်မှာ သင် Codex ကို လည်ပတ်နေသည့် နေရာ) အတွင်းရှိ ဖိုင်များကို ရေးသားနိုင်စေသည်။ သင် အင်တာနက်အသုံးပြုခွင့် လိုချင်ကြောင်း သတ်မှတ်မထားပါက အင်တာနက်အသုံးပြုခွင့် မရှိပါ။ ဖိုင်များကို ရေးသားခြင်းနှင့် ကွန်ရက်သို့ ဝင်ရောက်အသုံးပြုခြင်းတို့ကို ဘေးကင်းသော သတ်မှတ်နယ်ပယ်အတွင်း အလိုအလျောက် ကန့်သတ်နိုင်စေရန် Codex အနေဖြင့် ဤကန့်သတ်ချက်များကို အမှန်တကယ် ကျင့်သုံးအောင် ထိန်းချုပ်ပေးနိုင်သော sandbox ပတ်ဝန်းကျင်တစ်ခု လိုအပ်ပါသည်။

sandbox သည် ကန့်သတ်ထားသော အကောင်အထည်ဖော်မှု ပတ်ဝန်းကျင်တစ်ခု ဖြစ်သည်။ ဆော့ဖ်ဝဲဖန်တီးသူတစ်ဦးသည် Codex ကို အသုံးပြုသည့်အခါ၊ ၎င်း၏ ကွန်ပျူတာ၏ operating system သည် ခွင့်ပြုချက်များ လျှော့ချထားသော command တစ်ခုကို စတင်လုပ်ဆောင်ပြီး၊ ထိုကန့်သတ်ချက်များသည် လုပ်ငန်းစဉ်အဆင့်များ၏ အောက်ဆင့်များသို့ ဆက်လက်သက်ရောက်သွားသည်။ Codex command တိုင်းကို အစကတည်းက sandbox ထဲတွင် ကန့်သတ်သီးခြားထားပြီး၊ ၎င်းမှ ဆင်းသက်လာသော လုပ်ငန်းစဉ်တိုင်းသည်လည်း ထိုတူညီသော နယ်နိမိတ်အတွင်းတွင် ဆက်ရှိနေပါသည်။

ထိရောက်သော sandbox တစ်ခုကို အကောင်အထည်ဖော်ရန် Codex သည် ကွန်ပျူတာ၏ လည်ပတ်မှုစနစ်မှ အတည်ပြုအကောင်အထည်ဖော်ထားသော သီးခြားခွဲခြားရေး လုပ်ဆောင်ချက်များ လိုအပ်သည်။ အချို့သော လည်ပတ်မှုစနစ်များတွင် ဤလုပ်ဆောင်ချက်ကို ကောင်းစွာ ဆောင်ရွက်နိုင်သော utilities များ ပါဝင်နေပါသည် (ဥပမာ- macOS ပေါ်ရှိ Seatbelt၊ Linux ပေါ်ရှိ seccomp သို့မဟုတ် bubblewrap)။ သို့သော် Windows တွင် လက်ရှိအချိန်အထိ ဤအမျိုးအစား စွမ်းရည်ကို မူလတန်းအတိုင်း (out of the box) မပံ့ပိုးထားပါ။

Codex ကို အခြားနေရာတိုင်းတွင် အသုံးပြုရတာ ဘေးကင်းပြီး နှစ်သက်ဖွယ်ကောင်းပြီးသား ဖြစ်သကဲ့သို့ Windows ပေါ်တွင်လည်း ထိုနည်းတူ ဖြစ်စေရန်၊ ကျွန်ုပ်တို့၏ ကိုယ်ပိုင် sandbox ကို အကောင်အထည်ဖော်ရန် လိုအပ်ခဲ့ပါသည်။

Windows သည် သီးခြားခွဲထုတ်ခြင်းအတွက် ကိရိယာများနှင့် အခြေခံအစိတ်အပိုင်းများအချို့ကို ပေးထားသည်။ ၎င်းတို့ထဲမှ မည်သည့်အရာမျှ ကျွန်ုပ်တို့၏ လိုအပ်ချက်များနှင့် တိတိကျကျ မကိုက်ညီခဲ့သော်လည်း၊ ဖြစ်နိုင်ချေရှိသော ဖြေရှင်းနည်း အများအပြားကို ကျွန်ုပ်တို့ လေ့လာစဉ်းစားခဲ့သည်။ ဆိုလိုသည်မှာ AppContainer၊ Windows Sandbox နှင့် Mandatory Integrity Control တံဆိပ်သတ်မှတ်ခြင်းတို့ ဖြစ်သည်။

AppContainer

• ဘာလဲ- AppContainer သည် Windows ၏ မူရင်း sandbox ဖြစ်ပြီး၊ ဝင်ရောက်အသုံးပြုရန် လိုအပ်သည့်အရာများကို အစောပိုင်းကတည်းက တိတိကျကျ သိရှိထားသော အက်ပ်များအတွက် တည်ဆောက်ထားသည့် စွမ်းဆောင်ရည်အခြေပြု သီးခြားခွဲထုတ်မှု မော်ဒယ်တစ်ခု ဖြစ်သည်။
• ဘာကြောင့်- အတတ်နိုင်ဆုံးကြိုးစားမှုအဆင့် ကန့်သတ်ချက်များအစား အမှန်တကယ် OS နယ်နိမိတ်တစ်ခုကို ပေးသောကြောင့် ဆွဲဆောင်မှုရှိသည်။
• ဘာကြောင့် မဟုတ်တာလဲ- Codex သည် လုပ်ဆောင်နိုင်သည့် နယ်ပယ်ကို တင်းကျပ်စွာ ကန့်သတ်ထားသော အက်ပ်တစ်ခုတည်း မဟုတ်ပါ။ ၎င်းသည် ကန့်သတ်မထားသော ဖွံ့ဖြိုးရေး လုပ်ငန်းစဉ်များကို မောင်းနှင်ပေးသည်- shell များ၊ Git၊ Python၊ package manager များ၊ build tool များနှင့် အေးဂျင့်က လိုအပ်ကြောင်း ဆုံးဖြတ်သည့် အခြား binary များ ပါဝင်သည်။ လက်တွေ့တွင်၊ ထိုအချက်ကြောင့် AppContainer သည် ထိုပြဿနာအတွက် မကိုက်ညီသော ပုံစံ ဖြစ်သွားခဲ့သည်။ ၎င်းသည် ခိုင်မာသော သီးခြားခွဲထုတ်မှု ဖြစ်ခဲ့သော်လည်း၊ “အေးဂျင့်ကို developer တစ်ဦးလို လုပ်ဆောင်ခွင့်ပြုခြင်း” ထက် အများကြီး ပိုကျဉ်းမြောင်းသော workload အမျိုးအစားများအတွက်သာ ဖြစ်သည်။

Windows Sandbox

• ဘာလဲ- Windows Sandbox သည် Microsoft ၏ တစ်ခါသုံး ပေါ့ပါးသော VM ဖြစ်သည်။ သင်သည် ခိုင်မာသော သီးခြားခွဲထားမှု နယ်နိမိတ်ပါရှိသည့် Windows ဒက်စ်တော့ပ် အသစ်စက်စက်တစ်ခုကို ရရှိမည်ဖြစ်ပြီး၊ သင်လုပ်ဆောင်သမျှသည် ဆက်ရှင် ပြီးဆုံးသည့်အခါ ပျောက်ကွယ်သွားပါမည်။
• ဘာကြောင့်လဲ- ထင်ရှားသောအကြောင်းရင်းများကြောင့် စိတ်ဝင်စားစရာကောင်းသည်—AppContainer ထက် မည်သည့်ဆော့ဖ်ဝဲလ်မျိုးနှင့်မဆို ပိုမိုကိုက်ညီမှုရှိပြီး လုံခြုံရေးရှုထောင့်မှကြည့်လျှင် ၎င်းသည် အများကြီးပိုခိုင်မာသည့် ကန့်သတ်ပတ်ဝန်းကျင်တစ်ခု ဖြစ်သည်။
• ဘာကြောင့် မဟုတ်သလဲ- Codex သည် setup နှင့် host/guest bridging လိုအပ်မည့် သီးခြား ယာယီအသုံးပြု desktop အတွင်းတွင် မဟုတ်ဘဲ၊ အသုံးပြုသူ၏ အမှန်တကယ် checkout၊ tools နှင့် environment တို့ပေါ်တွင် တိုက်ရိုက် လုပ်ဆောင်ရန် လိုအပ်သည်။ ၎င်းတွင် အခြေခံကျသော ထုတ်ကုန်ဆိုင်ရာ ပြဿနာတစ်ခုလည်း ရှိခဲ့သည်- Windows Sandbox သည် Windows Home SKUs များတွင်တောင် မရရှိနိုင်ပါ။

Mandatory Integrity Control (MIC) ရဲ့ Integrity Labeling လုပ်ငန်းစဉ်

• ဘာလဲ- Windows တွင် “ခိုင်မာမှုအဆင့်များ” ဟုခေါ်သော အယူအဆတစ်ခု ရှိပြီး၊ ၎င်းတို့မှာ အနိမ့်၊ အလတ်နှင့် အမြင့် ကဲ့သို့သော အဆင့်များဖြစ်ကာ စနစ်က အရာဝတ္ထုများနှင့် လုပ်ငန်းစဉ်များအပေါ် မည်မျှ ယုံကြည်စိတ်ချသည်ကို သတ်မှတ်ပေးသည်။ အခြေခံစည်းမျဉ်းမှာ နိမ့်သော integrity အဆင့်ရှိ ပရိုဆက်စ်တစ်ခုသည် ပုံမှန် ACL အရ ခွင့်ပြုထားနိုင်သော်လည်း ပိုမိုမြင့်မားသော integrity အဆင့်ရှိ အရာဝတ္ထုတစ်ခုသို့ ရေးသားခွင့်မရှိခြင်းဖြစ်သည်။ ဥပမာအားဖြင့်၊ integrity အဆင့်နိမ့် process တစ်ခုကို ယုံကြည်စိတ်ချရမှု ပိုနည်းသောအရာအဖြစ် ဆက်ဆံသောကြောင့်၊ ၎င်း objects များကို ခွင့်ပြုရန် အတိအလင်း label ပြန်သတ်မှတ်ထားခြင်း မရှိပါက Windows သည် ၎င်းကို ပုံမှန် medium-integrity objects များထဲသို့ ရေးသားခြင်းမှ ပိတ်ပင်ပါသည်။
• ဘာကြောင့်လဲ- MIC သည် စာရွက်ပေါ်တွင်တော့ ခန့်ညားသပ်ရပ်ပုံရသည်—Codex ကို integrity အဆင့်နိမ့်ဖြင့် run လုပ်ရန်၊ ရေးသားနိုင်သော root များကို integrity အဆင့်နိမ့်အဖြစ် ပြန်လည် label လုပ်ရန်၊ ထို့နောက် အခြားနေရာအားလုံးတွင် ရေးသားခွင့်မရှိစေရန် Windows ကို enforcement လုပ်ခိုင်းရန် ဖြစ်သည်။ ဤသို့ပြုလုပ်ခြင်းက နောက်ကွယ်မှာ OS ၏ အမှန်တကယ် ယန္တရားတစ်ခုဖြင့် အက်ဒမင်ခွင့်မလိုသည့် နည်းလမ်းတစ်ခုကို ကျွန်တော်တို့ ရနိုင်ခဲ့မည်ဖြစ်သည်။
• အဘယ်ကြောင့် မသင့်လျော်သနည်း- ACLs ကဲ့သို့ပင်၊ integrity labels များသည် host ၏ အမှန်တကယ် ဖိုင်စနစ်ကို ပြင်ဆင်ပြောင်းလဲပြီး၊ ဤကိစ္စတွင် semantic ပြောင်းလဲမှုသည် အထူးသဖြင့် ကျယ်ပြန့်ပါသည်။ အလုပ်နေရာတစ်ခုကို low integrity အဖြစ် သတ်မှတ်ခြင်းသည် “Codex သည် ဤနေရာတွင် ရေးသားနိုင်သည်” ဟုသာ ဆိုလိုခြင်းမဟုတ်ပါ။ ၎င်းမှာ integrity အဆင့်နိမ့်သော လုပ်ငန်းစဉ်များသည် ယေဘုယျအားဖြင့် ထိုနေရာတွင် ရေးသားနိုင်သည်ဟု ဆိုလိုပါသည်။ တကယ့် developer စက်တစ်လုံးပေါ်တွင်၊ ၎င်းသည် အသုံးပြုသူ၏ အမှန်တကယ် repository checkout ကို host အတွက် integrity နိမ့်သော sink တစ်ခုအဖြစ် ပြောင်းလဲသွားစေပြီး၊ sandbox ဒီဇိုင်းတစ်ခုအတွက် သေချာစွာ ဦးတည်သတ်မှတ်ထားသော ACL ခွင့်ပြုချက်များပေးခြင်းထက် အန္တရာယ်ပိုများသည်။ medium-integrity အဆင့်ရှိ ဖွံ့ဖြိုးရေးကိရိယာများ ဆက်လက်အလုပ်လုပ်နေဦးမည်ဆိုပါကလည်း၊ အလုပ်နေရာ၏ အခြေခံ ယုံကြည်မှု မော်ဒယ်မှာ ထိန်းချုပ်ထားရန် ခက်ခဲပြီး တရားမျှတကြောင်း ရှင်းပြရန် ပို၍ပင် ခက်ခဲသော ပုံစံဖြင့် ပြောင်းလဲသွားပြီဖြစ်သည်။

ရွေးချယ်စရာအားလုံးကို လက်တွေ့မဖြစ်နိုင်သောအရာများအဖြစ် အကဲဖြတ်ပြီးနောက်၊ Windows အသုံးပြုသူများအတွက် ကောင်းမွန်သော Codex အတွေ့အကြုံကို ရရှိစေရန် ကျွန်ုပ်တို့၏ ကိုယ်ပိုင်ဖြေရှင်းချက်ကို စတင်ဒီဇိုင်းဆွဲခဲ့သည်။

ကျွန်ုပ်တို့၏ ပထမဆုံး လုပ်ဆောင်နိုင်သော ပုံစံငယ်သည် ကျွန်ုပ်တို့ လိုအပ်သော သီးခြားခွဲထားမှုကို အကောင်အထည်ဖော်ရန် Windows သဘောတရားများနှင့် ကိရိယာများကို ပေါင်းစပ်အသုံးပြုခဲ့သည်။ အစပိုင်းကတည်းက ရည်မှန်းချက်တစ်ခုမှာ ဤအရာကို အခွင့်အာဏာ မြှင့်တင်ခြင်း မလိုအပ်ဘဲ လုပ်ဆောင်နိုင်စေရန် ဖြစ်ပြီး၊ ဆိုလိုသည်မှာ Codex က အသုံးပြုသူထံ စီမံခန့်ခွဲသူ အခွင့်အရေးများ တောင်းခံရန် မလိုအပ်ခြင်း ဖြစ်သည်။ ဆိုလိုသည်မှာ အရာနှစ်ခုဖြစ်သည့် ဖိုင်ရေးသားမှုများနှင့် ကွန်ရက် ဝင်ရောက်အသုံးပြုခွင့်အပေါ် သင့်လျော်သော ကန့်သတ်ချက်များကို မည်သို့ ချမှတ်ရမည်ကို ဖော်ထုတ်ရန် ဖြစ်သည်-

ကျွန်ုပ်တို့က ဖိုင်ရေးသားမှုများကို လုံးဝ မကန့်သတ်ထားပါက၊ လုံခြုံရေးပြဿနာတစ်ခု ဖြစ်လာနိုင်ပါသည်။ အကယ်၍ ကျွန်ုပ်တို့က ဖိုင်ရေးသားမှုများကို အလွန်အမင်း ကန့်သတ်ထားပါက၊ sandbox သည် အတည်ပြုချက်ကို မပြတ်တောင်းခံရမည်ဖြစ်သဖြင့် အသုံးပြုသူ၏ ထုတ်လုပ်နိုင်စွမ်းကို ထိခိုက်စေမည်ဖြစ်သည်။ ဤပြဿနာကို ဖြေရှင်းရန်၊ ကျွန်ုပ်တို့သည် အရေးကြီးသော Windows အခြေခံတည်ဆောက်မှုအစိတ်အပိုင်းနှစ်ခုဖြစ်သည့် SIDs နှင့် ရေးသားခွင့်ကန့်သတ်ထားသော တိုကင်များကို အားထားအသုံးပြုခဲ့သည်။

SID သို့မဟုတ် လုံခြုံရေးသတ်မှတ်အမှတ်အသားသည် Windows က ခွင့်ပြုချက်များနှင့် ချိတ်ဆက်သတ်မှတ်ပေးသော ကိုယ်ပိုင်အမှတ်အသားဖြစ်သည်။ အသုံးပြုသူတစ်ဦးချင်းစီတွင် SID တစ်ခုရှိပြီး၊ အုပ်စုများတွင် SID များရှိကာ၊ လော့ဂ်အင် ဆက်ရှင်တစ်ခုတည်းပင်လျှင် ၎င်း၏ ကိုယ်ပိုင် SID ကို ရရှိပါသည်။ ဥပမာအားဖြင့်၊ လက်ရှိ လော့ဂ်အင်ဝင်ထားသော session တစ်ခုတွင် S-1-5-5-X-Y ကဲ့သို့သော SID တစ်ခု ရှိနိုင်သည်။ ဒေသတွင်း စီမံခန့်ခွဲသူများအုပ်စုအတွက် သတ်မှတ်ထားသော SID သည် S-1-5-32-544 ဖြစ်နိုင်ပါသည်။

Windows သည် အမှန်တကယ် အသုံးပြုသူတစ်ဦးနှင့် မကိုက်ညီသော်လည်း အသုံးပြုခွင့် ထိန်းချုပ်မှု စာရင်းများ (ACLs) တွင် ပေါ်နိုင်သေးသော အတုဖန်တီးထားသော SIDs များကိုလည်း ဖန်တီးခွင့်ပေးသည်။ ACLs သည် သတ်မှတ်ထားသော ဖိုင်များ သို့မဟုတ် လမ်းညွှန်များကို မည်သူက ဖတ်၊ ရေး၊ လုပ်ဆောင်နိုင်ကြောင်း သတ်မှတ်ပေးသည်။ ယင်းကြောင့် SIDs များသည် ကျွန်ုပ်တို့၏ sandbox အတွက် အသုံးဝင်သော အခြေခံအစိတ်အပိုင်းတစ်ခု ဖြစ်စေပါသည် စက်ပေါ်ရှိ အခြားအရာများကို အနှောင့်အယှက်မဖြစ်စေဘဲ Codex sandbox က အသုံးပြုရန်အတွက်သာ SIDs များကို ဖန်တီးနိုင်ပါသည်။

လုပ်ငန်းစဉ် တိုကင်များသည် လည်ပတ်နေသော လုပ်ငန်းစဉ်တစ်ခုအတွက် အထောက်အထားနှင့် အခွင့်ထူးများကို သတ်မှတ်ပေးသည့် Windows တွင်ရှိသော လုံခြုံရေး အရာဝတ္ထုများ ဖြစ်သည်။ ၎င်းတို့သည် လုပ်ငန်းစဉ်တစ်ခုက မည်သည့် လုပ်ဆောင်ချက်များကို လုပ်ဆောင်နိုင်သည်ကို သတ်မှတ်ပေးသည်။ ရေးသားခွင့် ကန့်သတ်ထားသော တိုကင် သည် Windows အား ရေးသားမှု လုပ်ဆောင်ချက်များအပေါ် ထပ်ဆောင်း ဝင်ရောက်ခွင့် စစ်ဆေးမှုတစ်ခု ပြုလုပ်စေသည့် လုပ်ငန်းစဉ် တိုကင် အမျိုးအစားတစ်ခု ဖြစ်သည်။

ရေးသားမှုတစ်ခု အောင်မြင်ရန်အတွက် စစ်ဆေးမှုနှစ်ခုကို အောင်မြင်ရမည်။

1. ပုံမှန် အသုံးပြုသူ ကိုယ်ပိုင်အမှတ်အသား (တိုကင် “ပိုင်ရှင်”) အား ၎င်းကို လုပ်ဆောင်ခွင့်ပြုထားရမည်။
2. တိုကင်၏ ကန့်သတ်ထားသော SID စာရင်းတွင်ရှိသော SID အနည်းဆုံး တစ်ခုကိုလည်း ဝင်ရောက်ခွင့် ပေးထားရမည်။

လက်တွေ့တွင်၊ ဤစစ်ဆေးမှုများသည် ACLs ကို အသုံးပြုပြီး sandbox က ဖိုင်စနစ်ထဲရှိ မည်သည့်နေရာများကို ပြုပြင်ပြောင်းလဲနိုင်သည်ကို အတိအကျ သတ်မှတ်နိုင်စေခဲ့ပြီး၊ ၎င်းက ရေးသားမှု လုပ်ဆောင်ချက်များနှင့် ပတ်သက်၍ ကျွန်ုပ်တို့ လိုအပ်သော အသေးစိတ် ထိန်းချုပ်နိုင်မှုအဆင့်ကို ပေးစွမ်းခဲ့သည်။

SIDs နှင့် ရေးသားခွင့်ကန့်သတ်ထားသော တိုကင်များဖြင့်၊ ကျွန်ုပ်တို့၏ အခွင့်အရေးမြှင့်ထားခြင်းမရှိသော sandbox သည် ဤသို့ လုပ်ဆောင်ခဲ့သည်-

1. sandbox setup သည် sandbox-write ဟုခေါ်သော အတုဖန်တီးထားသည့် SID တစ်ခုကို ဖန်တီးခဲ့သည်။
2. sandbox-write SID အား ရေးသားရန်၊ လုပ်ဆောင်ရန်နှင့် ဖျက်ရန် ဝင်ရောက်ခွင့်ကို ပေးအပ်ခဲ့သည်
   1. လက်ရှိ အလုပ်လုပ်နေသော ဒိုင်ရက်ထရီ
   2. config.toml တွင် သတ်မှတ်ပြင်ဆင်ထားသည့် ထပ်ဆောင်း writable_roots များ။
3. sandbox သတ်မှတ်ချက်သည် အဆိုပါ တူညီသော SID အား “ရေးသားနိုင်သော နေရာများအတွင်း ဖတ်ရှုရန်သာ” ဖြစ်သည့် အောက်ပါကဲ့သို့သော တည်နေရာများသို့ ရေးသားခွင့်ကို ထင်ရှားစွာ ပိတ်ပင်ထားသည်။
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex သည် ရေးသားခွင့် ကန့်သတ်ထားသော တိုကင်အောက်တွင် command များကို စတင်လုပ်ဆောင်ခဲ့ပြီး၊ ၎င်း၏ ကန့်သတ်ထားသော SID စာရင်းတွင် အားလုံး၊ လက်ရှိ လော့ဂ်အင်ဝင်ထားသော ဆက်ရှင် SID နှင့် sandbox-write synthetic SID တို့ ပါဝင်သည်။

ဤလုပ်ငန်းစီးဆင်းမှုသည် ဖိုင်ရေးသားမှုများကို ကန့်သတ်ခြင်းဆိုင်ရာ ပြဿနာကို ထိရောက်စွာ ဖြေရှင်းနိုင်ခဲ့ပြီး အလားအလာကောင်းရှိပုံရသည်။ ယခုအခါ sandbox ၏ ကွန်ရက် ဝင်ရောက်အသုံးပြုခွင့်ကို ကန့်သတ်ရန် ဖြေရှင်းချက်တစ်ခု လိုအပ်လာခဲ့သည်။

ကွန်ရက်ဝင်ရောက်ခွင့်ကို ကန့်သတ်ခြင်းသည် သီးခြားကန့်သတ်ပတ်ဝန်းကျင် (sandbox) ၏ အရေးကြီးသော အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ ယင်းကန့်သတ်မှုမရှိပါက အန္တရာယ်ရှိသော ကုဒ်သည် စက်မှ ဒေတာကို အင်တာနက်ပေါ်သို့ ခိုးထုတ်ပို့နိုင်မည်ဖြစ်သည်။ အခွင့်အရေးမြှင့်တင်မှု လိုအပ်ချက်ကို ရှောင်ရှားလိုသောကြောင့်၊ ကွန်ရက်အသွားအလာကို တင်းကျပ်စွာ ပိတ်ဆို့ရန် ကျွန်ုပ်တို့တွင် ရွေးချယ်စရာများ ကန့်သတ်ခဲ့ရသည်။ ကျွန်ုပ်တို့ အသုံးပြုလိုခဲ့သော Windows Firewall ကဲ့သို့သော ကိရိယာများကို ယေဘုယျအားဖြင့် အက်ဒမင် ခွင့်ပြုချက်များ မရှိဘဲ ထည့်သွင်းတပ်ဆင်၍ မရနိုင်ခဲ့ပါ။

Windows Firewall ကို ရွေးချယ်စရာအဖြစ် မသုံးနိုင်သဖြင့် ကျွန်ုပ်တို့ ထိန်းချုပ်နိုင်သည့်အရာများမှာ ကန့်သတ်သွားခဲ့သည်။ ကျွန်ုပ်တို့သည် developer များ လက်တွေ့အသုံးပြုသော ကွန်ရက်ချိတ်ဆက်သုံးစွဲသည့် tool အမျိုးအစားများအတွက် child environment ကို fail-closed ဖြစ်စေရန် ကြိုးစားခဲ့သည်။ ထို့ကြောင့် Git command များ၊ package installer များ စသည်တို့သည် sandbox အတွင်းတွင် fail ဖြစ်မည်ဖြစ်ပြီး၊ အင်တာနက်နှင့် ချိတ်ဆက်ဆောင်ရွက်သည့် operation မည်သည့်အရာမဆို အသုံးပြုသူက အတည်ပြုရန် လိုအပ်မည်ဖြစ်သည်။ အယူအဆမှာ ထင်ရှားသော ထွက်ပေါက်များကို အသုံးမဝင်အောင်လုပ်ရန်ဖြစ်သည် - proxy ကို သိရှိအသုံးပြုနိုင်သော traffic ကို အလုပ်မလုပ်သည့် အဆုံးမှတ်တစ်ခုသို့ ပို့ရန်၊ Git ၏ HTTP(S) transport ကိုလည်း ထိုအတိုင်းလုပ်စေရန်၊ နှင့် SSH မှတစ်ဆင့် Git အသုံးပြုခြင်းကို ချက်ချင်း မအောင်မြင်စေရန် ဖြစ်သည်။ ထို့အပြင်၊ stub SSH နှင့် SCP script များသည် အမှန်တကယ် binary ဖိုင်များထက် အရင် ရှာတွေ့နိုင်စေရန် denybin directory အသေးတစ်ခုကို PATH ၏ ရှေ့ဆုံးတွင် ထည့်ပြီး PATHEXT ကို အစီအစဉ်ပြန်စီခဲ့ပါသည်။

ဥပမာအားဖြင့်၊ ကွန်ရက် ဝင်ရောက်အသုံးပြုခွင့်ကို ကန့်သတ်ရန် ကျွန်ုပ်တို့ အသုံးပြုခဲ့သည့် သီးခြား environment overrides အချို့မှာ အောက်ပါအတိုင်း ဖြစ်သည်။

• 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

၎င်းက သာမန် ကိရိယာအခြေပြု traffic အများအပြားကို ဖမ်းမိခဲ့သော်လည်း အကြံပြုအဆင့်သာ ဖြစ်နေဆဲဖြစ်သည်။ လုပ်ငန်းစဉ်တစ်ခုသည် ပတ်ဝန်းကျင်ကို လျစ်လျူရှုနိုင်သည်၊ PATH ကို ကျော်လွှားနိုင်သည်၊ သို့မဟုတ် sockets များကို တိုက်ရိုက်ဖွင့်နိုင်သည်— အန္တရာယ်များလွန်းသည်။

စိတ်ဝင်စားဖွယ်ကောင်းသော ဆော့ဖ်ဝဲ အကောင်အထည်ဖော်မှုတိုင်းကဲ့သို့ပင်၊ ပထမဆုံး နမူနာပုံစံတွင် အားသာချက်များနှင့် အားနည်းချက်များအချို့ ရှိခဲ့သည်။ ၎င်းသည် စံ Windows လုပ်ဆောင်နိုင်စွမ်း အနည်းငယ်မျှဖြင့် လိုအပ်သည့်အလုပ်ကို ပြီးမြောက်စေနိုင်ခဲ့ပြီး၊ filesystem အတွင်း ရေးသားမှုများကို အလွန်ရှင်းလင်းစွာနှင့် အသေးစိတ်အဆင့်အလိုက် လုပ်ဆောင်နိုင်စေခဲ့ကာ၊ အခွင့်အရေးမြှင့်တင်မှုမလိုဘဲ လည်ပတ်နိုင်ခဲ့သည်—ထို့ကြောင့် အသုံးပြုသူများအနေဖြင့် အလွန်များပြားသော အခွင့်အရေးမြှင့်တင်မှု တုံ့ပြန်ညွှန်ကြားချက်များကို လက်ခံရန် သို့မဟုတ် ၎င်းတို့၏ local machine ပေါ်တွင် အက်ဒမင် ဖြစ်ရန် လိုအပ်ချက်ကို လျှော့ချနိုင်ခဲ့သည်—သို့သော် ၎င်းတွင် အမှန်တကယ် အားနည်းချက်အချို့ ရှိခဲ့ပြီး၊ ထိုအချို့ကြောင့် ၎င်းကို ကျွန်ုပ်တို့၏ နောက်ဆုံးဒီဇိုင်းအဖြစ် မဖြစ်လာနိုင်စေခဲ့သည်-

• setup အမြန်နှုန်း - အလုပ်နေရာ ACL များကို အသုံးချခြင်းသည် အလုပ်နေရာ ဒိုင်ရက်ထရီ၏ ဖွဲ့စည်းတည်ဆောက်ပုံအပေါ် မူတည်၍ ရင်းမြစ်အသုံးပြုမှု များနိုင်သည်။
• သက်ရောက်မှုအတိုင်းအတာ - ကျွန်ုပ်တို့သည် developer ၏စနစ်တွင် အမှန်တကယ် ACLs များကို အသုံးပြုခဲ့သော်လည်း၊ အသုံးပြုထားသော ACLs အားလုံးသည် sandbox ကသာ အသုံးပြုသည့် စိတ်ကြိုက်ဖန်တီးထားသော synthetic SID နှင့် သက်ဆိုင်သောကြောင့် ယင်းသက်ရောက်မှုအတိုင်းအတာသည် အထူးတလည် ထိုးဖောက်သက်ရောက်မှုမရှိပါ။
• ပြောင်းလဲရန် ခက်ခဲသော semantics - ဖိုင်အခြေပြု ကန့်သတ်ချက်များအတွက် ACLs အပေါ် မှီခိုနေခြင်းကြောင့် sandbox semantics ကို ပြောင်းလဲရန် ကုန်ကျစရိတ် မြင့်မားပြီး ရှုပ်ထွေးသည်။ macOS တွင် .sbpl ကို ဘယ်လိုထုတ်လုပ်မည်ကို ပြောင်းလဲနိုင်သည်။ Seatbelt ကို ပြင်ဆင်သတ်မှတ်ရန် အသုံးပြုသော ဖိုင်ဖြစ်ပြီး၊ Windows sandbox သည် ACL များကို ညှိရန် နှေးကွေးပြီး အရင်းအမြစ်အသုံးပြုမှု မြင့်မားသော လုပ်ဆောင်မှုတစ်ခုကို လိုအပ်နိုင်သည်။
• ကွန်ရက် ကာကွယ်မှု အားနည်းနေသည်။ ယခင်က ဖော်ပြခဲ့သည့်အတိုင်း၊ ၎င်းသည် “အကြံပြုသဘောမျိုးသာ” ဖြစ်ပြီး ကိုယ်ပိုင် networking stack ကို အကောင်အထည်ဖော်ထားသော ပရိုဂရမ်အချို့က သေချာပေါက် ရှောင်ကွင်းနိုင်မည်ဖြစ်သလို adversarial code ကို ခံနိုင်ရည်ရှိအောင် ဒီဇိုင်းထုတ်ထားခြင်းလည်း မဟုတ်ပါ။

ပထမဆုံး ပြဿနာသုံးရပ်မှာ အေးဂျင့်အခြေပြု လုပ်ငန်းစဉ်များအတွက် လုံလောက်စွာ ပြောင်းလွယ်ပြင်လွယ်ရှိသည့် စိတ်ကြိုက် sandbox အကောင်အထည်ဖော်မှုတစ်ခုတွင် ပင်ကိုယ်အားဖြင့် ပါဝင်နေသောအရာများဖြစ်သည်။ သို့သော် ကွန်ရက်အတွင်း ခြိမ်းခြောက်မှုများကို တားဆီးနှိမ်နင်းသည့်အပိုင်းမှာတော့ အခြေအနေက မတူခဲ့ပါ။

အန္တရာယ်ရှိသော အေးဂျင့်တစ်ခုသည် ပတ်ဝန်းကျင်အခြေပြု ကွန်ရက်တားဆီးမှုကို လွယ်ကူစွာ ကျော်လွှားနိုင်သည့်အပြင်၊ ရည်ရွယ်ချက်ကောင်းရှိသော code/binaries များစွာကလည်း environment proxy variables များကို မလိုက်နာလျှင်၊ သို့မဟုတ် ၎င်းတို့ကိုယ်ပိုင် socket-based network code ကို အကောင်အထည်ဖော်ထားလျှင်၊ ၎င်းကို ရှောင်ကွင်းသွားမည်ဖြစ်သည်။ ဤအချက်သည် ပိုမိုကောင်းမွန်သော သီးခြားကန့်သတ်မုဒ်တွင် ရင်းနှီးမြှုပ်နှံရန် စဉ်းစားသင့်လောက်အောင် လုံလောက်သည်ဟု ကျွန်ုပ်တို့ ယူဆခဲ့သည်။

ပိုမိုကောင်းမွန်သော ကွန်ရက်ထိန်းချုပ်ပိတ်ဆို့မှုကို ရရှိရန်၊ အသုံးပြုသူများ သို့မဟုတ် ပရိုဂရမ်များအတွက် အပြင်ထွက် ကွန်ရက်လမ်းကြောင်းအသွားအလာကို ပိတ်ဆို့နိုင်စေသည့် Windows Firewall ကို အသုံးပြုလိုခဲ့သည်။ ကံမကောင်းစွာဖြင့်၊ အကြောင်းရင်းအချို့ကြောင့် Codex harness မှ စတင်လုပ်ဆောင်စေသော commands များအတွက်သာ သက်ရောက်မည့် လုပ်ဆောင်နိုင်သော firewall rule တစ်ခုကို ထိရောက်စွာ ဖန်တီး၍ မရနိုင်ခဲ့ပါ။

• Windows သည် firewall စည်းမျဉ်းတစ်ခုကို ကန့်သတ်ထားသော တိုကင်၏ ပင်မ မဟုတ်သော ကိုယ်ပိုင်အမှတ်အသားနှင့် ကိုက်ညီစေရန် ခွင့်မပြုပါ။ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့၏ synthetic SID ကို ၎င်း၏ ကန့်သတ်ထားသော SID စာရင်းတွင် ထည့်သွင်းထားသည့် “မည်သည့် တိုကင်မဆို” အပေါ် firewall rule တစ်ခုကို ကျွန်ုပ်တို့ မကျင့်သုံးနိုင်ခဲ့ခြင်း ဖြစ်သည်။
• သတ်မှတ်ထားသော binary ဖိုင်တစ်ခုနှင့် ကိုက်ညီသည့် firewall စည်းမျဉ်းတစ်ခုကို ကျွန်ုပ်တို့ ဖန်တီးနိုင်သော်လည်း၊ ၎င်းက codex.exe ကိုယ်တိုင်အတွက် ကွန်ရက်ချိတ်ဆက်မှုကိုသာ ကန့်သတ်ခွင့်ပေးသည်။ ၎င်းသည် အသုံးပြုသူကိုယ်စား အေးဂျင့်က စတင်ဖန်တီးသည့် Git သို့မဟုတ် Python ပရိုဆက်စ်များကဲ့သို့သော ဆောင်ရွက်မှုများအပေါ် သက်ရောက်မည်မဟုတ်ပါ။
• အခြား firewall ကိုက်ညီမှု အတိုင်းအတာများ၏ ပုံသဏ္ဌာန်လည်း မှားယွင်းနေပါသည်။ အသုံးပြုသူအလိုက် scope သတ်မှတ်ထားသော စည်းမျဉ်းများသည် အခွင့်ထူးမြှင့်တင်မထားသော ဒီဇိုင်းတွင် ကန့်သတ်ထားသော child ကိုသာမက အမှန်တကယ် Windows အသုံးပြုသူနှင့်လည်း ဆက်လက်ကိုက်ညီနေခဲ့သည်။ ပရိုဂရမ်လမ်းကြောင်းဆိုင်ရာ စည်းမျဉ်းများသည် အလွန်ကျယ်ပြန့်လွန်းခဲ့သည်။ ၎င်းတို့သည် codex.exe သို့မဟုတ် python.exe ကို ယေဘုယျအားဖြင့် ပိတ်ဆို့နိုင်ခဲ့သော်လည်း၊ သီးခြားကန့်သတ်ထားသော ဤ python.exe ခေါ်ယူလုပ်ဆောင်မှုတစ်ခုကိုတော့ ပိတ်ဆို့နိုင်ခြင်း မရှိခဲ့ပါ။ ပို့တ် သို့မဟုတ် လိပ်စာအခြေပြု စည်းမျဉ်းများသည်လည်း လုံးဝ မှားယွင်းသော မူဝါဒဖြစ်ခဲ့သည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် port 443 ကို ပိတ်ဆို့လိုခဲ့ခြင်း မဟုတ်ဘဲ၊ ဤကန့်သတ်ထားသော သီးခြား process tree အတွက် အပြင်သို့ ထွက်သည့် မည်သည့် ဝင်ရောက်ခွင့်မဆိုကို ပိတ်ဆို့လိုခဲ့ခြင်း ဖြစ်သည်။

ကျွန်ုပ်တို့၏ sandbox ပြုလုပ်ထားသော command များအတွက်သာ firewall စည်းမျဉ်းတစ်ခုကို အသုံးချရန်၊ ၎င်းတို့ကို “တကယ့်” အသုံးပြုသူအဖြစ် မဟုတ်ဘဲ သီးခြား နိယာမ တစ်ခုအဖြစ် လုပ်ဆောင်ရန် လိုအပ်ခဲ့ပါသည်။ ဤချဉ်းကပ်ပုံက ကျွန်ုပ်တို့ကို လမ်းကြောင်းအသစ်တစ်ခုဆီသို့ ဦးတည်စေခဲ့ပြီး၊ ထိုလမ်းကြောင်းတွင် ကျွန်ုပ်တို့၏ “မြှင့်တင်မှု မရှိ” ကန့်သတ်ချက်ကို ဖြေလျှော့ခဲ့ပါသည်။

ကျွန်ုပ်တို့၏ လက်ရှိအကောင်အထည်ဖော်မှုဖြစ်သော စမ်းသပ်မှု စနစ်၏ နောက်ထပ်ဗားရှင်းသည် စတင်သတ်မှတ်ချိန်တွင် အဆင့်မြင့် အက်ဒမင်ခွင့်ပြုချက်များ လိုအပ်သည်။ ထို့ကြောင့် ကျွန်ုပ်သည် ၎င်းကို “မြှင့်တင်ထားသော sandbox” ဟု ခေါ်ဆိုပါသည်။ စနစ်ပေါ်တွင် Codex က command တစ်ခုကို spawn လုပ်သည့် နယ်နိမိတ်တွင်၊ အခွင့်အာဏာမြှင့်ထားသော sandbox သည် အခွင့်အာဏာမမြှင့်ထားသော sandbox နှင့် တူညီသလို ဖြစ်နေသည်။ ၎င်းသည် child process များကို ကန့်သတ်ထားသော တိုကင်အောက်တွင် ဆက်လက် run လုပ်သည်—အလားတူပင် [Everyone, Logon, Synthetic]ဟူသော တူညီသည့် ကန့်သတ် SID စာရင်းပါဝင်သော write_restricted တိုကင်တစ်ခုဖြစ်သည်—သို့သော် ဤတိုကင်၏ principal သည် အမှန်တကယ် Windows အသုံးပြုသူ မဟုတ်တော့ဘဲ Codex ကိုယ်တိုင် ဖန်တီးထားသော local user နှစ်ခုအနက် တစ်ခု ဖြစ်သည်-

• CodexSandboxOffline (firewall စည်းမျဉ်းများက ပစ်မှတ်ထားသည့် အရာ)
• CodexSandboxOnline (firewall စည်းမျဉ်းများက ပစ်မှတ်မထားသည့် အရာ)

သေးငယ်သော အသေးစိတ်အချက်တစ်ခုဟု ထင်ရသော်လည်း၊ အမှန်တကယ်တွင် ၎င်းသည် သီးခြားကန့်သတ်နယ်မြေအတွက်၊ ၎င်းကို မည်သူများ အသုံးပြုနိုင်သည်ဆိုသည်နှင့် ၎င်း၏ စနစ်တပ်ဆင်သတ်မှတ်မှုနှင့် လုပ်ဆောင်ချိန်အတွင်း အကောင်အထည်ဖော်မှု၏ ရှုပ်ထွေးမှုအပေါ် ကြီးမားသော သက်ရောက်မှုများ ရှိသည်။

၎င်းသည် အဆင့်မမြှင့်ထားသော prototype နှင့် မြင်ကွင်းအရ ဆင်တူပြီး firewall စည်းမျဉ်းများနှင့် command များကို အမှန်တကယ် လည်ပတ်စေသည့် သီးသန့် Windows အသုံးပြုသူတစ်ဦးကို ထည့်သွင်းထားပါသည်။ (သို့သော် ဤအယူအဆအသစ်များကို မိတ်ဆက်ထည့်သွင်းခြင်းကြောင့် sandbox သည် စတင်လည်ပတ်ပြီး command များကို ကာကွယ်နိုင်ရန် မတိုင်မီ ကြိုတင်ပြင်ဆင်မှု အလုပ်များ ပိုမိုရှိလာသည်။)

အထူးအခွင့်အာဏာ မြှင့်တင်မထားသော သီးခြားကန့်သတ်နယ်မြေ ဒီဇိုင်းတွင် ရိုးရှင်းသော တပ်ဆင်သတ်မှတ်မှု အဆင့်တစ်ခု ပါဝင်ခဲ့သော်လည်း၊ ၎င်းသည် နှိုင်းယှဉ်လျှင် သေးငယ်သည်-

• လိုအပ်ပါက သန့်စင်ထားသော SID တစ်ခု ဖန်တီးပါ။
• sandbox-write ဖန်တီးထားသော SID အတွက် ACL များကို သတ်မှတ်၍ အသုံးပြုပါ။

သို့သော် အခွင့်အာဏာမြှင့်တင်ထားသော sandbox တွင် လုပ်ဆောင်စရာ ပိုရှိသည်။

• မဖန်တီးရသေးပါက အတု SID တစ်ခုကို ဖန်တီးပါ
• အွန်လိုင်းနှင့် အော့ဖ်လိုင်း စမ်းသပ်မှု အသုံးပြုသူများကို မဖန်တီးရသေးပါက ဖန်တီးပါ၊
• အသစ်ဖန်တီးထားသော အသုံးပြုသူများ၏ အကောင့်ဝင် အထောက်အထားများကို စက်တွင်းတွင် သိမ်းဆည်းပြီး sandbox အသုံးပြုသူများက အမှန်တကယ် ဖတ်ရှု၍မရနိုင်သော နေရာတွင် Windows Data Protection API (DPAPI) ကို အသုံးပြု၍ စာဝှက်ထားပါ
• CodexSandboxOffline အသုံးပြုသူအတွက် အပြင်သို့ ထွက်သည့် ကွန်ရက်ဝင်ရောက်ခွင့်အားလုံးကို ပိတ်ဆို့သည့် firewall စည်းမျဉ်းများကို ဖန်တီးပါ၊ သို့မဟုတ် ၎င်းတို့ ရှိပြီးသားဖြစ်ပါက မှန်ကန်ကြောင်း အတည်ပြုပါ

စတင်ပြင်ဆင်မှုအဆင့်တွင် နောက်ထပ် ရှုပ်ထွေးမှုတစ်ခု ရှိပါသည်။ Codex ၏ sandbox သည် အမှန်တကယ် Windows အသုံးပြုသူနှင့် ညီမျှသော ဖတ်ရှုခွင့် ရှိမည်ဟု မျှော်လင့်ထားသည်။ ကန့်သတ်ထားသော တိုကင်၏ အဓိက SID သည် Windows အသုံးပြုသူဖြစ်သည့် အခွင့်ထူးမြှင့်တင်မထားသော sandbox ထဲတွင်၊ ဤအရာကို ပြီးမြောက်စေနိုင်ခဲ့သည်။ သို့သော် principal သည် CodexSandbox အသုံးပြုသူအသစ် ဖြစ်လာသည့်အခါ၊ ထိုအရာသည် အခမဲ့ ရရှိလာသည့်အရာတော့ မဟုတ်ပါ။ Windows ပေါ်ရှိ သက်ဆိုင်ရာ လမ်းညွှန်အများအပြားသည် “Authenticated Users” အတွက် ဖတ်ရှု/လုပ်ဆောင်ခွင့်များ ပေးထားပါမည်။ ထင်ရှားသော ဥပမာတစ်ခုမှာ အသုံးပြုသူ၏ ပရိုဖိုင် လမ်းညွှန် ဖြစ်ပါသည်။ ပုံသေအားဖြင့် Windows အသုံးပြုသူများသည် အခြား Windows အသုံးပြုသူများ၏ ပရိုဖိုင် ဒါရိုက်ထရီများကို မဖတ်နိုင်သောကြောင့် အခြေအနေများစွာတွင် ရိုးရှင်းသော ဖိုင်ဖတ်ခြင်းများပင် မအောင်မြင်နိုင်ပါ။

ဤပြဿနာကို ဖြေရှင်းရန်၊ ကျွန်ုပ်တို့သည် sandbox ပြင်ဆင်သတ်မှတ်မှု လုပ်ငန်းစဉ်တွင် နောက်ထပ်အလွှာတစ်ခု ထည့်သွင်းခဲ့သည် (ထိုကဲ့သို့သော ACL များ ရှိမနေသေးနိုင်သည့် နေရာများတွင် sandbox အသုံးပြုသူများအတွက် read ACLs ခွင့်ပြုပေးရန် အလွှာတစ်ခု ဖြစ်သည်)။ ဥပမာအားဖြင့်၊ အများအားဖြင့် အသုံးပြုသော Windows လမ်းညွှန်အချို့သို့ -

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

ဤ directories စာရင်းသည် အတတ်နိုင်ဆုံး စုစည်းထားသော (best-effort) စာရင်းသာဖြစ်ပြီး၊ တစ်ခုချင်းစီတွင် ACL များကို သတ်မှတ်ထည့်သွင်းခြင်းသည် အရင်းအမြစ်/ကုန်ကျစရိတ် အတော်များနိုင်သောကြောင့်၊ အသုံးပြုသူများအတွက် blocking ဖြစ်နေသော sandbox setup အဆင့်သည် ၎င်းတို့ ပြီးဆုံးရန် စောင့်ဆိုင်းစရာမလိုစေရန် ဤ logic ကို asynchronous အဖြစ် လုပ်ဆောင်ပါသည်။

ကျွန်ုပ်တို့သည် တပ်ဆင်မှု logic ကို ၎င်း၏ သီးခြား binary ထဲတွင် ထုပ်ပိုးထားခဲ့သည်၊ တစ်စိတ်တစ်ပိုင်းအားဖြင့် UAC နယ်နိမိတ်ကို လိုအပ်သည့်အခါမှသာ ဖြတ်ကျော်ရန် ဖြစ်သည်။ သို့သော် ပိုမိုနက်ရှိုင်းသော အကြောင်းရင်းမှာ ဗိသုကာပုံစံဆိုင်ရာ ဖြစ်သည်—sandbox ပြင်ဆင်မှုသည် codex.exe နှင့် အခြေခံအားဖြင့် မတူညီသော လုပ်ငန်းတာဝန်တစ်ခု ရှိသည်။ sandbox setup logic ကို သီးသန့် binary တစ်ခုအတွင်း ထားရှိခြင်းကြောင့် codex.exe ကို ပုံမှန်၊ အခွင့်အရေးမြှင့်မထားသော harness အဖြစ် ဆက်လက်ထားရှိနိုင်ခဲ့သည်။ Windows အတွက်သာ သက်ဆိုင်သော setup ယန္တယား ကြောင့် အခြား ဤလက်ဖောင်းများပေါ်ရှိ codex.exe မလိုအပ်ဘဲ ဖောင်းပွလာခြင်းကို တားဆီးနိုင်ခဲ့သည်။ ပိုမိုကြာရှည်လုပ်ဆောင်ရသော setup လုပ်ငန်းများကို အဓိကလုပ်ငန်းစဉ်၏ သက်တမ်းနှင့် ခွဲထုတ်နိုင်ခဲ့သည်။ ထို့အပြင် sandbox လိုအပ်သည့် မတူညီသော setup လမ်းကြောင်းများကို ကိုင်တွယ်ရန် တစ်နေရာတည်းကိုလည်း ရရှိစေခဲ့သည်။

Windows အသုံးပြုသူနှင့် တိုကင် လော့ဂ်အင် နယ်နိမိတ်များ အလုပ်လုပ်ပုံကြောင့်၊ အခွင့်အာဏာ မြှင့်မထားသော sandbox တွင် လုပ်နိုင်ခဲ့သကဲ့သို့ ကန့်သတ်ထားသော တိုကင်တစ်ခုကို ဆက်လက်ဖန်တီးပြီး ၎င်းအောက်တွင် လုပ်ငန်းစဉ်တစ်ခုကို စတင်ဖန်တီးရန် မလုပ်ဆောင်နိုင်ခဲ့ပါ။ command များကို အခြား Windows အသုံးပြုသူတစ်ဦးအနေဖြင့် အမှန်တကယ် spawn လုပ်ရန်အတွက်၊ ကျွန်ုပ်တို့၏ ပထမဦးဆုံးအကြံဉာဏ်မှာ အောက်ပါလုပ်ငန်းစဉ်ဖြစ်သည်-

• codex.exe သည် အမှန်တကယ် Windows အသုံးပြုသူအဖြစ် လည်ပတ်သည်။ ထို့နောက် အစဉ်လိုက်အတိုင်း - Codex
  • သီးခြားကန့်သတ်နယ်မြေ အသုံးပြုသူအတွက် LogonUserW(...) ကို ခေါ်ဆိုသည်။
  • ထို sandbox အသုံးပြုသူ တိုကင်ပေါ်တွင် CreateRestrictedToken(...) ကို ခေါ်ဆိုသည်။
  • ထိုကန့်သတ်ထားသည့် စမ်းသပ်မှု စနစ်အသုံးပြုသူ တိုကင်ကို အသုံးပြုပြီး၊ နောက်ဆုံး child ကို စတင်ရန် CreateProcessAsUserW(...) ကို ခေါ်ဆိုသည်။

လက်တွေ့တွင်မူ ထိုရည်မှန်းထားသော လုပ်ငန်းစီးဆင်းမှုသည် CreateProcessAsUserW(...) တွင် အခွင့်ထူးဆိုင်ရာ အတားအဆီးတစ်ခုကြောင့် အလုပ်မဖြစ်ခဲ့ပါ။ ဆိုလိုသည်မှာ codex.exe သည် sandbox အသုံးပြုသူအတွက် ကန့်သတ်ထားသော တိုကင်တစ်ခုကို ဖန်တီးနိုင်ခဲ့သော်လည်း၊ နယ်နိမိတ်၏ အမှန်တကယ်အသုံးပြုသူဘက်မှနေ၍ ထို တိုကင်ဖြင့် child process တစ်ခုကို ယုံကြည်စိတ်ချရစွာ စတင်မပြုလုပ်နိုင်ခဲ့သည်ဟု ဆိုလိုသည်။ ကျွန်ုပ်တို့သည် sandbox အသုံးပြုသူအဖြစ် လည်ပတ်နေပြီးသား process တစ်ခု လိုအပ်ခဲ့သည်။ ဤသို့ဖြင့် ကန့်သတ်ခြင်းအဆင့်နှင့် နောက်ဆုံး spawn ပြုလုပ်မှုတို့သည် နယ်နိမိတ်၏ အမှန်တကယ်အသုံးပြုသူဘက်တွင် မဟုတ်ဘဲ sandbox အသုံးပြုသူဘက်တွင် ဖြစ်ပွားနိုင်မည်ဖြစ်သည်။

ထိုလိုအပ်ချက်ကြောင့် codex-command-runner.exe ဟုခေါ်သော binary အသစ်တစ်ခု ဖြစ်ပေါ်လာခဲ့ပြီး၊ ၎င်း၏ တစ်ခုတည်းသော အလုပ်မှာ ကန့်သတ်ထားသော တိုကင်တစ်ခု ဖန်တီးပြီး တောင်းဆိုထားသော command ကို စတင်လုပ်ဆောင်စေရန် ဖြစ်သည်။ codex.exe ကို စီးဆင်းမှုတစ်ခုလုံး (အမှန်တကယ်အသုံးပြုသူ → sandbox အသုံးပြုသူ → ကန့်သတ်ထားသော တိုကင် → child process) ကို ၎င်းကိုယ်တိုင် ဆောင်ရွက်စေရန် တောင်းဆိုမည့်အစား၊ ကျွန်ုပ်တို့သည် စီးဆင်းမှုကို နှစ်ပိုင်းခွဲထားသည်။

အပိုင်း 1

• codex.exe သည် CreateProcessWithLogonW(...) ကို ခေါ်၍ codex-command-runner.exe ကို sandbox အသုံးပြုသူအဖြစ် စတင်ဖွင့်လှစ်သည်၊ သို့သော် ကန့်သတ်ထားသော တိုကင် ကို မသုံးသေးပါ။

အပိုင်း 2

• runner အတွင်းတွင် OpenProcessToken(GetCurrentProcess(), ...) သည် runner ၏ ကိုယ်ပိုင် တိုကင်ကို ဖွင့်သည်၊ ၎င်းတိုကင်သည် အစကတည်းက sandbox အသုံးပြုသူ၏ တိုကင်ဖြစ်ပြီးသားဖြစ်သည်။
• Runner သည် sandbox logon SID ကို ထုတ်ယူရန် GetTokenInformation(...) ကို ခေါ်ဆိုပြီး၊ ထို့နောက် နောက်ဆုံး ကန့်သတ်ထားသော တိုကင်ကို တည်ဆောက်ရန် CreateRestrictedToken(...) ကို ခေါ်ဆိုသည်။
• runner အတွင်းမှာပဲ ဆက်လက်၍၊ ၎င်းသည် အမှန်တကယ် child process ကို စတင်ရန် ထို ကန့်သတ်ထားသော တိုကင်ဖြင့် CreateProcessAsUserW(...) ကို ခေါ်ဆိုသည်။

အယ်လ်ဘတ် အိုင်းစတိုင်းက - “အရာအားလုံးကို ဖြစ်နိုင်သမျှ ရိုးရှင်းအောင် ပြုလုပ်သင့်တယ်၊ ဒါပေမဲ့ အဲ့ဒီထက်ပိုပြီး ရိုးရှင်းအောင် မလုပ်သင့်ဘူး။” ဟု ပြောခဲ့သည်။ ထိုအမြင်သဘောထားဖြင့်၊ ကျွန်ုပ်တို့၏ ဒီဇိုင်းသည် ပြဿနာတစ်ခုချင်းစီကို လုံလောက်စွာ ဖြေရှင်းနိုင်ခဲ့ပါသည်။ အပြီးသတ် ဗိသုကာပုံစံတွင် ယခင်က ဖော်ပြခဲ့ပြီးသော အလွှာလေးခု ပါဝင်သည်-

• codex.exe ကိုယ်တိုင်
• မြင့်မားသော ခွင့်ပြုချက်များ လိုအပ်သည့် setup နှင့် သက်ဆိုင်သော အလုပ်အားလုံးကို ကိုင်တွယ်လုပ်ဆောင်ရန်အတွက် codex-windows-sandbox-setup.exe
• codex-command-runner.exe သည် ကန့်သတ်ထားသော တိုကင် command များကို လုပ်ဆောင်ရန်အတွက်
• child process

ဒီပရောဂျက်ကို ပထမဆုံး စတင်ကိုင်တွယ်ခဲ့ချိန်မှာ၊ နောက်ဆုံးမှာ ဘယ်လိုဖြစ်လာမလဲဆိုတာကို ကျွန်ုပ် သေချာမသိခဲ့ပါ။ ကျွန်ုပ်၏ ချဉ်းကပ်ပုံမှာ Codex နှင့် operating system အကြားရှိ နယ်နိမိတ်တွင် sandboxing စွမ်းရည်ကို စောင့်ကြည့်တိုင်းတာနိုင်ရန် instrumentation ထည့်သွင်းခြင်းဖြင့် စတင်ရန်ဖြစ်သည်။ ဤချဉ်းကပ်နည်းသည် MacOs နှင့် Linux တွင် Codex ၏ sandbox ကို အကောင်အထည်ဖော်ထားပုံနှင့် အလွန်နီးစပ်စွာ ကိုက်ညီပါသည်။

Windows က ပံ့ပိုးပေးသော သီးခြားကိရိယာများအကြောင်း ပိုမိုလေ့လာလာသည်နှင့်အမျှ၊ လုံခြုံရေးနှင့် အသုံးပြုရလွယ်ကူမှုအကြား မျှတစေရန် ချိန်ဆထားသော ဆုံးဖြတ်ချက်များစွာမှတစ်ဆင့်၊ စနစ်သည် ၎င်း၏ လက်ရှိပုံစံ—binary ဖိုင်များစွာ၊ စိတ်ကြိုက် user များ၊ firewall စည်းမျဉ်းများ၊ မြှင့်တင်ထားသော setup အဆင့်တစ်ခု၊ asynchronous process များနှင့် အခြားအရာများ—အထိ တဖြည်းဖြည်း ဖွံ့ဖြိုးလာခဲ့သည်။

၎င်းသည် အထူးတလည် ရိုးရှင်းသော စနစ်တစ်ခု မဟုတ်သော်လည်း၊ ရှုပ်ထွေးမှုတစ်ခုချင်းစီကို လိုအပ်ချက်အရ ထည့်သွင်းခဲ့ခြင်းဖြစ်ပြီး ဘေးကင်းသလို အသုံးပြုသူအား အတတ်နိုင်ဆုံး မနှောင့်ယှက်စေသော sandbox ပတ်ဝန်းကျင်တစ်ခုကို တည်ဆောက်ရန် ဖြစ်ပါသည်။

Windows ပေါ်ရှိ Codex အသုံးပြုသူများအတွက် ကောင်းမွန်သော အသုံးပြုသူအတွေ့အကြုံကို ပေးနိုင်ရန် ကြိုးပမ်းရာတွင် ကျွန်ုပ်တို့၏ ရည်မှန်းချက်မှာ အသုံးဝင်မှုကို မလျှော့ချဘဲ လုံခြုံသော အရာတစ်ခုကို ဖန်တီးရန်ဖြစ်သည်—Codex ကို အသုံးပြုရခြင်း၏ အဓိကရည်ရွယ်ချက်မှာ သင့်အနေဖြင့် အမြဲမပြတ် အာရုံစိုက်စောင့်ကြည့်နေရန် မလိုဘဲ အေးဂျင့်များက အလုပ်များ ဆောင်ရွက်နိုင်စေရန် ဖြစ်သည်။

ဤပရောဂျက်မှ ရရှိခဲ့သော အကြီးမားဆုံး သင်ခန်းစာများထဲမှ တစ်ခုမှာ Windows သည် “လုံခြုံသော အလိုအလျောက် ကုဒ်ရေးအေးဂျင့်” နှင့် သန့်ရှင်းတိကျစွာ ကိုက်ညီသည့် အခြေခံ primitive တစ်ခုကို ကျွန်ုပ်တို့အား ပေးခဲ့ခြင်းမရှိပါ။ ကျွန်ုပ်တို့သည် ညီညွတ်မှုရှိသော အရာတစ်ခုကို တည်ဆောက်ရန် ကိရိယာများနှင့် အယူအဆများစွာကို ပေါင်းစပ်အသုံးပြုခဲ့ပါသည်။ အစောပိုင်းက အကြံဉာဏ်အချို့သည် ဆက်လက်အကောင်အထည်ဖော်၍မရသော အကြံများ ဖြစ်ခဲ့သည်။ နောက်ဆုံး ဒီဇိုင်းသည် ပြဿနာ၏ အစိတ်အပိုင်းတစ်ခုစီကို ဖြေရှင်းပေးခဲ့သော အစောပိုင်း နမူနာမော်ဒယ်များကို ပေါင်းစပ်ထားသည့် ဒီဇိုင်းတစ်ခု ဖြစ်သည်။

နောက်ထပ် သင်ခန်းစာတစ်ခုမှာ ကုဒ်ရေးအေးဂျင့်အတွက် လုံခြုံရေးသည် ပိုမိုရိုးရာကျသော အက်ပ်လီကေးရှင်း လုံခြုံရေးနှင့် နှိုင်းယှဉ်လျှင် သဘောသဘာဝ မတူသော ကိစ္စတစ်ခု ဖြစ်သည်။ Codex သည် လက်တွေ့ developer လုပ်ငန်းစဉ်များတွင် အသုံးဝင်စွာ အလုပ်လုပ်နိုင်ရမည်။ ထိုအင်ဂျင်နီယာလုပ်ငန်းသည် အေးဂျင့်ဆန်သော workload များနှင့် ကိုက်ညီမှုကို အမှန်တကယ် တင်းကျပ်အကောင်အထည်ဖော်မှုနှင့် ချိန်ညှိမျှတစေရန် အဓိကထားခဲ့ခြင်း ဖြစ်သည်။ ထိုဆန့်ကျင်တင်းမာမှုက နောက်ဆုံး ဒီဇိုင်းထဲရှိ အပေးအယူများကို ပုံဖော်ပေးခဲ့သည်။

Codex sandbox လက်တွေ့လုပ်ဆောင်နေသည်ကို ကြည့်ချင်ပါသလား။ စမ်းသုံးကြည့်ပါ⁠။