በWindows ላይ Codexን ለማስቻል ደህንነቱ የተጠበቀና ውጤታማ sandbox መገንባት

በሴፕቴምበር 2025 የCodex ምህንድስና ቡድን ስቀላቀል፣ የWindows የCodex ሥሪት sandbox አተገባበር አልነበረውም፤ ይህም ማለት የWindows ተጠቃሚዎች OpenAI የኮድ ወኪሎችን ሲጠቀሙ ከሁለት ከመደበኛው በታች የሆኑ አማራጮች መካከል ለመምረጥ ይገደዱ ነበር፦

1. የኮድ ወኪል ሊያሄድ የሚፈልገውን እያንዳንዱን ትዕዛዝ (እንዲያውም የሚያነብ) ማጽደቅ፣ ውጤታማ ያልሆነ እና አስቸጋሪ ነው። Codexን መጠቀም ያለው ትልቅ ጥቅም ሁሉንም አድካሚ ሥራዎች እራስዎ ማድረግ ስላልኖረብዎት ነው።
2. የሙሉ መዳረሻ ሁነታን ማስቻል፦ Codex ያለ ፈቃድ ወይም ገደብ ሁሉንም ትዕዛዞች እንዲያስኬድ መፍቀድ፣ ይህም ቁጥጥርን በመቀነስ ግጭትን ያስወግዳል።

Codex⁠ ይህም በCLI፣ በIDE ቅጥያ ወይም በዴስክቶፕ መተግበሪያ በኩል ቢሆንም—የእኛ የኮድ ወኪል በዲቨሎፐሮች ላፕቶፖች ላይ ይሰራል። ይህ የኢንፈረንስ ሂደትን ለመፈጸም ቁልፍ ሰሌዳ የሚጠቀም ሰው እና በክላውድ ውስጥ በሚሰራ ሞዴል መካከል ያለውን ውይይት ያስተዳድራል።

Codex በነባሪነት እውነተኛ ተጠቃሚ ካለው ፈቃድ ጋር ይሰራል፤ ይህም ተጠቃሚው ሊያደርገው የሚችለውን ሁሉ እሱም ሊያደርግ ይችላል ማለት ነው። ይህ ኃይለኛ ቢሆንም አደገኛ ሊሆን ይችላል። የኮድ ሞዴሉ ለharness ትእዛዞችን በአካባቢያዊ ሁኔታ እንዲያስኬድ ሊነግረው ይችላል፣ ፈተናዎችን ከማስኬድ እስከ ፋይል ማንበብ ወይም ማርትዕ እስከ Git branch መፍጠር ድረስ፤ ስለዚህ የCodex ነባሪ ሁነታ በውጤታማነት እና በደህንነት መካከል ትክክለኛውን ሚዛን ለማግኘት ይሞክራል። ይህ ነባሪ ሁነታ Codex በሁሉም ቦታ ማለት ይቻላል ፋይሎችን እንዲያነብ እና በየስራ ቦታዎ ውስጥ (ማለትም Codex እያስኬዱበት ባለው ማውጫ) ፋይሎችን እንዲጽፍ ይፈቅዳል፣ እርስዎ እንዲፈልጉት ካልገለጹ በስተቀር የበይነመረብ መዳረሻ የለውም። ፋይል መጻፍን እና የአውታረ መረብ መዳረሻን በደህንነቱ ገደቦች ውስጥ በራስ-ሰር ለመገደብ፣ Codex እነዚህን ገደቦች በእውነት የሚያስፈጽም sandbox አካባቢ ያስፈልገዋል።

sandbox የተገደበ የማስኬጃ አካባቢ ነው። አንድ ገንቢ Codexን ሲጠቀም፣ የኮምፒዩተራቸው ኦፕሬቲንግ ሲስተም የተቀነሰ ፈቃድ ያለው ትዕዛዝ ያስጀምራል፣ እና እነዚህ ገደቦች በሂደቱ ዛፍ ላይ ይሰራጫሉ። እያንዳንዱ የCodex ትእዛዝ ከመጀመሪያው ጀምሮ በsandbox ውስጥ ይከለላል፣ እና እያንዳንዱ ተከታይ ሂደት በዚያው ወሰን ውስጥ ይቆያል።

Codex ውጤታማ sandbox ለመተግበር በኮምፒውተሩ ኦፕሬቲንግ ሲስተም የሚያስፈጸሙ የማግለል ባህሪያት ያስፈልጉታል። አንዳንድ ኦፕሬቲንግ ሲስተሞች ይህን በጥሩ ሁኔታ የሚያደርጉ መገልገያዎችን ይሰጣሉ (ለምሳሌ፣ Seatbelt በMacOs፣ seccomp ወይም bubblewrap በLinux)፤ ነገር ግን Windows በአሁኑ ጊዜ ይህን ዓይነት ችሎታ ከሳጥኑ ውስጥ አያቀርብም።

Codex በWindows ላይም እንደሌሎቹ ሁሉ ደህና እና ለመጠቀም አስደሳች እንዲሆን፣ የራሳችንን sandbox መተግበር አስፈልጎናል።

Windows ለማግለል አንዳንድ መሣሪያዎችና መሠረታዊ አካላትን ያቀርባል። ምንም እንኳን ከእነሱ አንዱም ፍላጎታችንን በትክክል ባያሟላም፣ በርካታ ሊሆኑ የሚችሉ መፍትሄዎችን—በተለይ AppContainer፣ Windows Sandbox እና Mandatory Integrity Control labeling—ተመልክተናል።

AppContainer

• ምንድነው፦ AppContainer የWindows የተወላጅ sandbox ሲሆን ለመተግበሪያዎች ከቀድሞ በትክክል ምን መዳረሻ እንደሚፈልጉ የሚያውቁ በችሎታ-የተመሠረተ የግልጋሎት ሞዴል ነው።
• ለምን፦ በተቻለ መጠን የሚተገበሩ ገደቦች ሳይሆኑ እውነተኛ የOS ወሰን ስለሚሰጥ ማራኪ ነው።
• ለምን አይሆንም፦ Codex በጥብቅ የተገደበ ወሰን ያለው አንድ መተግበሪያ አይደለም። ይህ ሰፊና ያልተገደቡ የገንቢዎች የሥራ ፍሰቶችን ያንቀሳቅሳል፦ ሼሎች፣ Git፣ Python፣ የፓኬጅ አስተዳዳሪዎች፣ የግንባታ መሣሪያዎች፣ እና ወኪሉ እንደሚያስፈልጉት የሚወስናቸው ሌሎች ባይነሪዎች። በተግባር፣ ይህ AppContainerን ለችግሩ ተስማሚ ያልሆነ ያደረገው ነው። ይህ ጠንካራ ማግለል ነበር፣ ነገር ግን «ኤጀንት እንደ ሶፍትዌር ገንቢ እንዲሰራ መፍቀድ» ከሚለው ይልቅ በጣም የተገደበ የሥራ ጫናዎች ክፍል ላይ ብቻ የሚመለከት ነበር።

የWindows Sandbox

• ምንድን ነው፦ Windows Sandbox የMicrosoft ሊጣል የሚችል ቀላል VM ነው። በጠንካራ የማግለል ወሰን አዲስ የWindows ዴስክቶፕ ያገኛሉ፣ እና በውስጡ የሚያደርጉት ሁሉ ክፍለ ጊዜው ሲያበቃ ይጠፋል።
• ለምን፦ ምክንያቱ ግልጽ ነው—ከAppContainer ይልቅ ከየትኛውም ሶፍትዌር ጋር የበለጠ ተኳኋኝ ነው፣ እና ከደኅንነት አንፃር እጅግ ጠንካራ ሳጥን ነው።
• ለምን አይሆንም፦ Codex በቀጥታ በተጠቃሚው ትክክለኛ የቼክ አወጣጥ፣ መሣሪያዎች እና አካባቢ ላይ መሥራት አለበት፣ ማዋቀር እና የአስተናጋጅ/እንግዳ ድልድይ የሚያስፈልገው የተለየ የሚጠፋ ዴስክቶፕ ውስጥ አይደለም። እንዲሁም መሠረታዊ የምርት ችግር ነበረበት፦ Windows Sandbox በWindows Home SKUs ላይ እንኳን አይገኝም ነበር።

Mandatory Integrity Control (የግዴታ የኢንቴግሪቲ ቁጥጥር፣ MIC) የኢንቴግሪቲ መለያ

• ምንድን ነው፦ Windows ሥርዓቱ ነገሮችን እና ሂደቶችን ምን ያህል እንደሚያምናቸው የሚወስኑ፣ እንደ ዝቅተኛ፣ መካከለኛ እና ከፍተኛ ያሉ «የአስተማማኝነት ደረጃዎች» የሚባል ጽንሰ-ሐሳብ አለው። መሠረታዊው ደንብ፣ ዝቅተኛ የታማኝነት ደረጃ ያለው ሂደት ከፍተኛ የታማኝነት ደረጃ ወዳለው ኦብጀክት መጻፍ አይችልም፤ መደበኛው ACL በሌላ ሁኔታ ይህን ቢፈቅድለትም። ለምሳሌ፣ ዝቅተኛ የታማኝነት ደረጃ ያለው ሂደት ከታመነው ያነሰ እንደሆነ ይቆጠራል፤ ስለዚህ Windows ወደ መደበኛ መካከለኛ-የታማኝነት ኦብጀክቶች እንዳይጽፍ ያግደዋል፣ እነዚያ ኦብጀክቶች እንዲፈቅዱለት በግልጽ እንደገና ካልተሰየሙ በስተቀር።
• ለምን፦ MIC በወረቀት ላይ የሚያምር ይመስል ነበር—Codexን በዝቅተኛ ትክክለኛነት ያሄድ ነበር፣ የሚጻፉትን ሥሮች በዝቅተኛ ትክክለኛነት እንደገና ይሰይም እና Windows በሌሎች ቦታዎች ላይ ምንም ዓይነት ጽሑፍ እንዳይጽፉ እንዲያስገድድ ይፍቅድ ነበር። ያ በእውነተኛ የOS ስልት የተደገፈ የአስተዳዳሪ መብት የማይጠይቅ መንገድ ይሰጠን ነበር።
• ለምን አይሆንም፦ እንደ ACLs ሁሉ፣ የኢንቴግሪቲ መለያዎች እውነተኛውን የአስተናጋጅ ፋይል ስርዓት ያሻሽላሉ፣ በዚህም ሁኔታ የሴማንቲክ ለውጡ በተለይ ሰፊ ነው። የስራ ቦታን ዝቅተኛ ታማኝነት እንዳለው ምልክት ማድረግ፣ «Codex እዚህ መጻፍ ይችላል» ማለት ብቻ አይደለም። ይህ ማለት፣ ዝቅተኛ-ኢንተግሪቲ ሂደቶች በአጠቃላይ በዚያ መጻፍ ይችላሉ ማለት ነው። በእውነተኛ የገንቢ ማሽን ላይ፣ ይህ የተጠቃሚውን ትክክለኛ checkout ለአስተናጋጁ ዝቅተኛ-ታማኝነት ያለው sink ያደርገዋል፤ ይህም ለአንድ የsandbox ንድፍ በጥንቃቄ የተመሩ ACLs ከመስጠት በጣም የበለጠ አደገኛ ነው። የመካከለኛ ኢንቴግሪቲ የገንቢ መሣሪያዎች መስራታቸውን ቢቀጥሉም፣ የየስራ ቦታው መሠረታዊ የእምነት ሞዴል ለመቆጣጠር አስቸጋሪ እና ለማጽደቅ ደግሞ ይበልጥ አስቸጋሪ በሆነ መንገድ ተለውጧል።

ሁሉንም አማራጮች የማይጀምሩ እንደሆኑ ከገምገምን በኋላ፣ ለWindows ተጠቃሚዎች ጥሩ የCodex ተሞክሮ ለማምጣት የራሳችንን መፍትሄ ማቀድ ጀምረናል።

የመጀመሪያው የሚሠራ ፕሮቶታይፓችን የሚያስፈልገንን ማግለል ለመተግበር የWindows ጽንሰ-ሐሳቦችንና መሣሪያዎችን በጥምረት ተጠቅሟል። ከመጀመሪያው ጀምሮ፣ አንዱ ግብ ይህንን ያለ የመብት ከፍ ማድረግ እንዲሠራ ማድረግ ነበር፤ ይህም Codex ሳንድቦክሱን ለማዋቀር ወይም ለማስኬድ ብቻ ከተጠቃሚው የአስተዳዳሪ መብቶችን እንዲፈቅድ እርምጃ ማቅረብ እንደማያስፈልገው ማለት ነው። ይህም በሁለት ነገሮች ላይ ምክንያታዊ ገደቦችን እንዴት ማስቀመጥ እንደሚቻል መለየት ማለት ነበር፦ የፋይል መጻፍ ክወናዎች እና የአውታረ መረብ መዳረሻ።

የፋይል ጽሕፈትን ከቶ ካልገደብን፣ የደኅንነት ችግር ይኖረናል። በጣም ብዙ ከገደብን ደግሞ sandbox የተጠቃሚውን ምርታማነት ይጎዳል እና ያለማቋረጥ ፈቃድ መጠየቅ ይኖርበታል። ይህን ችግር ለመፍታት፣ በWindows ውስጥ ባሉ ሁለት አስፈላጊ መሠረታዊ አካላት ተደግፈናል፦ SIDዎች እና ጽሕፈት-የተገደበላቸው tokenዎች።

SID ወይም የደኅንነት መለያ፣ Windows ከፈቃዶች ጋር የሚያያዘው ማንነት ነው። እያንዳንዱ ተጠቃሚ SID አለው፣ ቡድኖች SIDዎች አሏቸው፣ እና አንድ የመግቢያ ክፍለ ጊዜ እንኳን የራሱን SID ያገኛል። ለምሳሌ፣ አሁን የተገባበት ክፍለ ጊዜ እንደ S-1-5-5-X-Y ያለ SID ሊኖረው ይችላል። ለአካባቢያዊ አስተዳዳሪዎች ቡድን የተመደበው SID S-1-5-32-544 ሊሆን ይችላል።

Windows እውነተኛ ተጠቃሚን የማይወክሉ ነገር ግን በACLs (access control lists) ውስጥ ሊታዩ የሚችሉ የሰው ሠራሽ SIDዎች መፍጠርንም ይፈቅዳል፣ እነዚህም ማን የተወሰኑ ፋይሎችን ወይም ማውጫዎችን ማንበብ/መጻፍ/ማስኬድ እንደሚችል ይገልጻሉ። ይህም SIDዎችን ለsandbox ጠቃሚ መሠረታዊ አካል ያደርጋቸዋል፦ ለCodex sandbox ብቻ የሚጠቀሙ እና በማሽኑ ላይ ሌላ ነገርን የማይነኩ የSID መለያዎችን መፍጠር እንችላለን።

የሂደት tokenዎች በWindows ውስጥ እየተፈጸመ ላለ ሂደት ማንነትንና መብቶችን የሚወስኑ የደኅንነት ኦብጀክቶች ናቸው። አንድ ሂደት ምን እርምጃዎችን ማከናወን እንደሚችል ይወስናሉ። ጽሕፈት-የተገደበለት token Windows በመጻፍ ክወናዎች ላይ ተጨማሪ የመዳረሻ ማረጋገጫ እንዲያከናውን የሚያደርግ ልዩ ዓይነት የሂደት token ነው።

ጽሕፈት እንዲሳካ፣ ሁለት ምርመራዎች ማለፍ አለባቸው፦

1. መደበኛው የተጠቃሚ መለያ (የtoken «ባለቤት») ይህን ማድረግ እንዲችል ሊፈቀድለት ይገባል
2. በtoken የተገደበው SID ዝርዝር ውስጥ ቢያንስ አንድ የSID መዳረሻ ሊሰጠው ይገባል

በተግባር፣ እነዚህ ምርመራዎች sandbox የፋይል ሥርዓቱን በትክክል የት ሊቀይር እንደሚችል ለመግለጽ ACLዎችን እንድንጠቀም አስችለውናል፣ ይህም በመጻፍ እርምጃዎች ዙሪያ ያስፈለገንን ዝርዝር ቁጥጥር ሰጥቶናል።

በSIDዎች እና ጽሕፈት-የተገደበላቸው tokenዎች ያልተስተካከለው sandboxችን በዚህ መልክ ይሠራ ነበር፦

1. የsandbox ማቀናበሪያው 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 የተገደበ የSID ዝርዝር ሁሉንም፣ የአሁኑ የገባበት ክፍለ ጊዜ SID እና sandbox-write ሠራሽ SIDን የሚያካትት በጽሑፍ የተገደበ token ስር ትዕዛዞች አስጀምሯል።

ይህ ፍሰት የፋይል መጻፍን መገደብ በተግባር ፈታው እና ተስፋ ሰጪ መስሎ ታየ። አሁን የsandbox የአውታረ መረብ መዳረሻን ለመገደብ መፍትሄ ያስፈልገን ነበር።

የአውታረ መረብ መዳረሻን መገደብ sandbox አስፈላጊ ክፍል ነው፤ ይህ ከሌለ ክፉ ኮድ ከማሽኑ ውስጥ ውሂብን ወደ በይነመረብ ሊያወጣ ይችላል። የማሳደጊያ መስፈርትን ለማስወገድ ስለፈለግን፣ የአውታረ መረብ ትራፊክን በጠንካራ ሁኔታ ለማገድ ያሉን አማራጮች ውስን ነበሩ። ልንጠቀምባቸው የፈለግናቸው መሣሪያዎች እንደ Windows Firewall ያሉት በአጠቃላይ የአስተዳዳሪ ፈቃድ ሳይኖር መጫን አይቻልም ነበር።

Windows Firewall እንደ አማራጭ ስላልነበረ፣ ልንቆጣጠረው የምንችለውን ገድበናል። ገንቢዎች በተግባር ለሚጠቀሙባቸው የአውታረ መረብ መሣሪያዎች ዓይነቶች፣ የልጅ አካባቢው በ «fail-closed» መርህ፣ ማለትም በነባሪነት በተዘጋ ሁኔታ እንዲከሽፍ ለማድረግ ሞክረናል፤ ይህም የGit ትእዛዞች፣ የጥቅል ጫኚዎች ወዘተ በሳንድቦክሱ ውስጥ እንዲከሽፉ፣ እና ተጠቃሚው ወደ በይነመረብ የሚገናኙ ማናቸውንም ክወናዎች መፍቀድ እንዲኖርበት ነው። ሀሳቡ ግልጽ የሆኑትን የማምለጫ መውጫዎች ማበላሸት ነበር፦ ፕሮክሲ-አዋቂ ትራፊክን ወደ ምላሽ የማይሰጥ መጨረሻ ነጥብ መላክ፣ የGit HTTP(S) ትራንስፖርትም ተመሳሳይ ነገር እንዲያደርግ ማድረግ፣ እና Git over SSH ወዲያውኑ እንዲከሽፍ ማድረግ። ከዚያም በተጨማሪ፣ ትንሽ የ denybin ማውጫን በ PATH መጀመሪያ ላይ ጨመርን፣ እንዲሁም የstub SSH እና SCP ስክሪፕቶች ከእውነተኛዎቹ ባይነሪዎች በፊት እንዲገኙ PATHEXTን እንደገና አደራጀን።

ለምሳሌ፣ የአውታረ መረብ መዳረሻን ለመገደብ ከተጠቀምንባቸው የተለዩ የአካባቢ መሻሪያዎች መካከል እነዚህ ነበሩ፦

• 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ን ሊያልፍ ወይም በቀጥታ sockets ሊከፍት ይችላል—ይህ በጣም አደገኛ ነበር።

እንደ ማንኛውም አስደሳች የሶፍትዌር ትግበራ፣ የመጀመሪያው ፕሮቶታይፕ አንዳንድ ጥቅሞችና ጉዳቶች ነበሩት። በጥቂት መደበኛ የWindows ችሎታዎች ብቻ ሥራውን ቢያከናውንም፣ በጣም ግልጽ እና በዝርዝር የfilesystem መጻፍ ቢፈቅድም፣ እና ከፍ ሳይደረግ ቢሠራም—ተጠቃሚዎች ብዙ የከፍታ መጠይቆች መቀበል ወይም በአካባቢያቸው ማሽን ላይ አስተዳዳሪዎች መሆን እንዳያስፈልጋቸው በማድረግ—አንዳንዶቹ የመጨረሻ ንድፋችን ከመሆን ያስቀሩት እውነተኛ ጉዳቶች ነበሩት፦

• የማቀናበሪያ ፍጥነት፦ የየስራ ቦታ ACLs መተግበር እንደ የሥራ ቦታ ማውጫው ቅርጸት ከፍ ያለ ወጪ ሊኖረው ይችላል።
• Footprint፦ በገንቢው ሥርዓት ላይ እውነተኛ ACLዎች ተግብረናል፣ ምንም እንኳን footprint በተለይ ወራሪ ባይሆንም፣ ምክንያቱም የተተገበሩት ACLs ሁሉ በsandbox ብቻ ጥቅም ላይ የሚውል በብጁ የተፈጠረ የሰው ሠራሽ SIDን የሚመለከቱ ናቸው።
• ለመቀየር አስቸጋሪ የሆኑ ሴማንቲክስ፦ ለፋይል-ተመሳሳይ ገደቦች ACLዎች ላይ መመርኮዝ የsandbox ሴማንቲክስን መቀየር ወጪ የሚጠይቅና ውስብስብ እንዲሆን ያደርገዋል። በmacOS ላይ ግን፣ .sbpl እንዴት እንደምናመነጭ በተለዋዋጭ ሁኔታ መቀየር እንችላለን Seatbeltን ለማዋቀር የሚጠቅመው ፋይል፣ የWindows ሳንድቦክስ ACLዎች ለማስተካከል የዘገየ እና ከባድ ክወና ሊፈልግ ይችላል።
• የአውታረ መረብ ጥበቃ ደካማ ነው። ከዚህ በፊት እንደተጠቀሰው «ምክር ብቻ» ነበር፣ የራሳቸውን የአውታረ መረብ ቁልል የሚተገብሩ አንዳንድ ፕሮግራሞች በእርግጥ ያልፉታል፣ እና ከጠላት ኮድ ጋር ለመቋቋም የተነደፈ አልነበረም።

የመጀመሪያዎቹ ሦስት ጉዳዮች ለወኪላዊ ፍሰቶች በቂ ተለዋዋጭ ከሆነ ብጁ የsandbox አተገባበር ውስጥ የተፈጥሮ ናቸው። የአውታረ መረብ መገደብ ግን የተለየ ነበር።

ጉዳት አዘል ወኪል በአካባቢ-መሠረት የአውታረ መረብ መገደብን በቀላሉ ሊያልፍ ከመቻሉ በተጨማሪ፣ ጥሩ አላማ ያላቸው ብዙ ኮዶች/ binaries የአካባቢ proxy ተለዋዋጮችን ካላከበሩ ወይም የራሳቸውን በsocket የተመሠረተ የአውታረ መረብ ኮድ ካላቸው ብቻ እንኳ ያልፉት ነበር። ይህ ገጽታ ብቻ በተሻለ sandbox ሁነታ ላይ ኢንቨስት እንድናደርግ በቂ ነው ብለን ተሰማን።

የተሻለ የአውታረ መረብ መገደብ ለማግኘት፣ ወጪ የሚወጣ የአውታረ መረብ ትራፊክን ለተጠቃሚዎች ወይም ለፕሮግራሞች ማገድ የሚፈቅድልንን Windows Firewall መጠቀም ፈለግን። የሚያሳዝነው ግን፣ በCodex harness የሚፈጠሩ ትእዛዞች ላይ ብቻ የሚተገበር ተግባራዊ firewall ደንብ በተሳካ ሁኔታ መፍጠር አልቻልንም፣ ይህም በእነዚህ ጥቂት ምክንያቶች ነው፦

• Windows የfirewall ደንብን ከተገደበ token ዋና ያልሆነ ማንነት ጋር ማዛመድን አይፈቅድም። ይህ ማለት «በrestricted SID list ውስጥ የእኛን የሰው ሠራሽ SID የያዘ ማንኛውም token» ላይ firewall ደንብ መተግበር አንችልም ማለት ነው።
• ከተወሰነ ሁለትዮሽ ጋር የሚዛመድ የfirewal ደንብ መፍጠር ብንችልም፣ ይህ ለ codex.exe ራሱ አውታረ መረብን እንድንገድብ ብቻ ያስችለናል። ይህ ወኪሉ በተጠቃሚው ምትክ ለሚያስነሳቸው ሂደቶች፣ እንደ Git ወይም Python ሂደቶች፣ ተፈጻሚ አይሆንም።
• ሌሎች የfirewall ማዛመጃ ልኬቶችም ትክክለኛ ቅርጸት አልነበራቸውም። በተጠቃሚ ወሰን የተገደቡ ደንቦች፣ ከፍ ያለ መብት ባልተሰጠው ንድፍ ውስጥ፣ የተገደበውን ንዑስ ሂደት ብቻ ሳይሆን አሁንም ከእውነተኛው የWindows ተጠቃሚ ጋር ይዛመዱ ነበር። የፕሮግራም መንገድ ደንቦች በጣም ሰፊ ነበሩ፦ codex.exe ወይም python.exe ን በአጠቃላይ ሊያግዱ ይችሉ ነበር፣ ግን ይህን አንድ በsandbox ውስጥ የተገደበ የ python.exe ማስኬጃ ግን ሊያግዱ አይችሉም ነበር። በፖርት ወይም በአድራሻ የተመሠረቱ ደንቦችም ፈጽሞ የተሳሳተ የፖሊሲ ምርጫ ነበሩ። ለምሳሌ፣ ፖርት 443ን ማገድ አልፈለግንም፤ ለዚህ የተወሰነ የተገደበ የሂደት ዛፍ ማንኛውንም የወደ ውጭ መዳረሻ ማገድ ነበር የፈለግነው።

በተለይ በsandbox የተደረጉ ትዕዛዞቻችን ላይ firewall rule ለመተግበር፣ እነዚያን ትእዛዞች እንደ «እውነተኛ» ተጠቃሚ ሳይሆን እንደ ተለየ principal ማስኬድ አስፈለገ። ይህ አቀራረብ «ከፍታ የለም» የሚለውን ገደባችንን ዘና ያደረገ አዲስ መንገድ አመጣን።

የsandbox ቀጣይ ሥሪት፣ ይህም የአሁኑ ትግበራችን ነው፣ በማዋቀር ጊዜ ከፍ ያሉ የአስተዳዳሪ ፈቃዶች ይፈልጋል። ስለዚህ «ከፍ ያለ sandbox» በማለት እጠራዋለሁ። Codex በሥርዓቱ ላይ ትዕዛዝ በሚያስጀምርበት ድንበር ላይ፣ ከፍ ያለ መብት ያለው sandbox ከፍ ያለ መብት ከሌለው sandbox ጋር ተመሳሳይ ይመስላል። ይህ አሁንም የልጅ ሂደቶችን በተገደበ token ስር ያስኬዳል—በተመሳሳይ ሁኔታ [Everyone, Logon, Synthetic]የሆነውን ተመሳሳይ የተገደበ SID ዝርዝር ያለውwrite_restrictedtoken—ነገር ግን፣ የዚህ token ዋና ማንነት ከአሁን በኋላ ትክክለኛው የWindows ተጠቃሚ ሳይሆን Codex ራሱ ከፈጠራቸው ሁለት አካባቢያዊ ተጠቃሚዎች አንዱ ነው፦

• CodexSandboxOffline (በfirewall ደንቦች ያልታለመው)
• CodexSandboxOnline (በfirewall ደንቦች ያልታለመው)

ይህ ትንሽ የሚመስል ዝርዝር በእውነቱ በsandbox ላይ፣ ማን ሊጠቀምበት እንደሚችል ላይ፣ እና በማቀናበሪያውና በሥራ ጊዜው አስፈጻሚነት ውስብስብነት ላይ ትልቅ ተጽዕኖ አለው።

በእይታ ከከፍ ያልተደረገው ፕሮቶታይፕ ጋር ተመሳሳይ ነው፣ ነገር ግን firewall ደንቦች እና ለዚሁ የተለየ የWindows ተጠቃሚ ተጨምሯል፣ ይህም ትዕዛዞቹን በእውነት የሚያስኬድ ነው። (ነገር ግን እነዚህ አዳዲስ ሐሳቦች በመግባታቸው፣ sandbox ትዕዛዞች ከመሥራቱና ከመጠበቁ በፊት ተጨማሪ የማቀናበሪያ ሥራ ያስፈልጋል።)

ከፍ ያልተደረገው sandbox ንድፍ ቀላል የማቀናበሪያ እርምጃ ነበረው፣ ነገር ግን በአንፃራዊነት ትንሽ ነበር፦

• ካስፈለገ የሰው ሠራሽ SID መፍጠር
• ለsandbox-write የሰው ሠራሽ SID ACLs መተግበር

ከፍ የተደረገው sandbox ግን ተጨማሪ የሚያደርገው ነገር አለ።

• አስቀድሞ ካልተፈጠረ፣ ሰው ሠራሽ SID መፍጠር
• የመስመር ላይ እና ከመስመር ውጪ sandbox ተጠቃሚዎች መፍጠር፣ አስቀድሞ ካልተፈጠሩ
• አዲስ የተፈጠሩትን የተጠቃሚዎች ምስጢራዊ መረጃዎች በአካባቢያዊ ሁኔታ ማከማቸት እና የWindows Data Protection API (DPAPI) በመጠቀም የsandbox ተጠቃሚዎች በእውነት ማንበብ በማይችሉበት ቦታ መመስጠር
• ለ CodexSandboxOffline ተጠቃሚ ሁሉንም የወጪ የአውታረ መረብ መዳረሻ የሚከለክሉ firewall rules መፍጠር ወይም አስቀድመው ካሉ ትክክል መሆናቸውን መረጋገጥ

በማዋቀር ደረጃ ላይ ተጨማሪ ውስብስብነት አለ። የCodex ሳንድቦክስ ከትክክለኛው የWindows ተጠቃሚ ጋር ተመጣጣኝ የንባብ መዳረሻ እንዲኖረው ይጠበቃል። ከፍተኛ መብት ባልተሰጠው sandbox ውስጥ፣ የተገደበው token ዋና SID የWindows ተጠቃሚ በነበረበት ሁኔታ፣ ይህ ተሳክቷል። ሆኖም፣ principal አዲስ የ CodexSandbox ተጠቃሚ ሲሆን ያ በነፃ የሚገኝ አይደለም። በWindows ላይ ያሉ ብዙ ተዛማጅ ማውጫዎች ለ «የተረጋገጡ ተጠቃሚዎች» የማንበብ/የማስፈጸም ፈቃዶች ይሰጣሉ። አንድ ጉልህ ምሳሌ የተጠቃሚው መገለጫ ማውጫ ነው። በነባሪነት፣ የWindows ተጠቃሚዎች የሌሎች የWindows ተጠቃሚዎችን የመገለጫ ዳይሬክቶሪዎች ማንበብ አይችሉም፣ ስለዚህ በብዙ ሁኔታዎች ቀላል የፋይል ንባብ ክዋኔዎች እንኳን ላይሳኩ ይችላሉ።

ይህን ለመቅረፍ፣ ለsandbox ተጠቃሚዎች እንደዚህ ያሉ የ read ACLዎች አስቀድመው የማይኖሩባቸው ቦታዎች ላይ ለመስጠት ሌላ ንብርብር ወደ sandbox የማቀናበሪያ ሂደት አክለናል። ለምሳሌ፣ ወደ አንዳንድ በተለምዶ ጥቅም ላይ የሚውሉ የWindows ማውጫዎች፦

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

ይህ የማውጫዎች ዝርዝር best-effort ስለሆነ እና በእያንዳንዱ ላይ ACLዎች መጫን ከፍ ያለ ወጪ ስለሚያስፈልግ፣ ተጠቃሚዎችን የሚያስቆም የsandbox ማቀናበሪያ እርምጃ እነሱ እስኪጠናቀቁ እንዳይጠብቅ ይህን ሎጂክ በasynchronous መንገድ እናስኬዳለን።

የማዋቀሪያውን ሎጂክ በራሱ ባይነሪ ውስጥ አካትተነዋል፤ ይህም በከፊል የUAC ወሰንን በሚያስፈልግ ጊዜ ብቻ ለማለፍ ነው። ነገር ግን ጥልቁ ምክንያት ከአርክቴክቸር ጋር የተያያዘ ነበር፦ የsandbox ማዋቀር ከ codex.exe በመሠረቱ የተለየ ተግባር አለው። የsandbox ማቀናበሪያ ሎጂኩን በተለየ binary ማቆየት codex.exe መደበኛ፣ ከፍ ያልተደረገ harness እንዲቆይ አስቻለ፤ በሌሎች መድረኮች ላይ የWindows-ብቻ የማቀናበሪያ ሂደት እንዳያጨናንቀው አደረገ፤ ረጅም ጊዜ የሚወስድ የማቀናበሪያ ስራ ከዋናው ሂደት እድሜ እንዲለይ አደረገ፤ እና sandbox የሚያስፈልጉትን የተለያዩ የማቀናበሪያ መንገዶች አንድ ቦታ እንድንያዝ ሰጠን።

የWindows ተጠቃሚ እና token የመግቢያ ወሰኖች ስለሚሠሩበት መንገድ፣ በከፍ ያልተደረገው sandbox ላይ እንዳደረግነው restricted token መፍጠር እና በሱ ስር ሂደት ማስነሳት መቀጠል አልቻልንም። በእውነት እንደ የተለየ የWindows ተጠቃሚ ትዕዛዞች ለማስነሳት፣ የመጀመሪያ ሐሳባችን የሚከተለው ፍሰት ነበር፦

• codex.exe እንደ እውነተኛው የWindows ተጠቃሚ ይሰራል። ከዚያ፣ በቅደም ተከተል፣ Codex፦
  • ለsandbox ተጠቃሚው LogonUserW(...) ይጠራል።
  • በዚያ የsandbox-user token ላይ CreateRestrictedToken(...) ን ይጠራል።
  • ያንን የተገደበ የsandbox-user token በመጠቀም፣ የመጨረሻውን ልጅ ሂደት ለማስጀመር CreateProcessAsUserW(...) ይጠራል።

በተግባር ግን፣ ያ የተፈለገው ፍሰት በ CreateProcessAsUserW(...) ላይ ባለ የመብት እንቅፋት ምክንያት አልሠራም። ይህ ማለት codex.exe ለsandbox ተጠቃሚው የተገደበ token መፍጠር ችሏል፣ ነገር ግን ከድንበሩ የእውነተኛው ተጠቃሚ በኩል በዚያ token የልጅ ሂደት በአስተማማኝ ሁኔታ ማስጀመር አልቻለም ነው። እንደ sandbox ተጠቃሚ ቀድሞውኑ እየሠራ ያለ ሂደት ያስፈልገን ነበር—ይህም የገደብ ደረጃው እና የመጨረሻው ማስነሳት በወሰኑ የsandbox-ተጠቃሚ በኩል እንጂ በእውነተኛ-ተጠቃሚ በኩል እንዳይከናወኑ ያስችላል።

ያ መስፈርት codex-command-runner.exe ወደተባለ አዲስ ባይነሪ ፋይል አመራ፤ ብቸኛ ሥራውም የተገደበ token ማመንጨት እና የተጠየቀውን ትዕዛዝ ማስጀመር ነው። codex.exe ፍሰቱን ሙሉ በሙሉ እንዲያደርግ (እውነተኛ ተጠቃሚ → sandbox ተጠቃሚ → restricted token → child process) ከመጠየቅ ይልቅ፣ ፍሰቱን በሁለት ክፍሎች ከፈልነው፦

ክፍል 1

• codex.exe restricted token ገና ሳይጠቀም codex-command-runner.exe ን እንደ sandbox ተጠቃሚ ለማስነሳት CreateProcessWithLogonW(...) ይጠራል።

ክፍል 2

• በአስኬያሃጁ ውስጥ፣ OpenProcessToken(GetCurrentProcess(), ...) የአስኬያሃጁ የራሱ token ይከፍታል፣ ይህም አስቀድሞ የsandbox ተጠቃሚው ነው።
• አስኬያሃጁ የsandbox logon SIDን ለማውጣት GetTokenInformation(...) ይጠራል፣ ከዚያም የመጨረሻውን የተገደበ token ለመገንባት CreateRestrictedToken(...) ይጠራል።
• አሁንም በአስኬያሃጁ ውስጥ ሆኖ፣ እውነተኛውን ልጅ ለማስነሳት በዚያ የተገደበ token CreateProcessAsUserW(...) ይጠራል።

Albert Einstein «ሁሉም ነገር የተቻለውን ያህል ቀላል መደረግ አለበት፣ ግን ከዚያ ያለፈ አይሆንም» ብሎ ተናግሯል። በዚያ መንፈስ፣ ንድፋችን እያንዳንዱን ችግር በቂ ሁኔታ ፈታ። የመጨረሻው አርክቴክቸር ከዚህ በፊት የሸፈንናቸው አራት ንብርብሮች አሉት፦

• codex.exe ራሱ
• codex-windows-sandbox-setup.exe ሁሉንም ከፍ ያሉ ማዋቀር ጋር የተያያዙ ሥራዎችን ለማስተናገድ
• የተገደቡ የtoken ትዕዛዞች ለማስኬድ codex-command-runner.exe
• የጅማሬ ሂደት

መጀመሪያ ወደዚህ ፕሮጀክት ስመጣ፣ መጨረሻ ወዴት እንደሚደርስ ጠንካራ ግንዛቤ አልነበረኝም። አቀራረቤ በCodex እና በሥርዓተ ክወና መካከል ባለው ወሰን ላይ የsandboxing ችሎታን በመለካት መጀመር ነበር። ይህ አቀራረብ የCodex sandbox በMacOs እና Linux ላይ እንዴት እንደሚተገበር ጋር በጣም ቅርብ ነው።

Windows የሚሰጠንን የተለዩ መሣሪያዎች የለጠ እየተማርኩ ስመጣ፣ እና ደኅንነትን ከመጠቀም ቀላልነት ጋር ለማመዛዘን በደርዘን ውሳኔዎች አማካኝነት፣ ሥርዓቱ እስከ አሁን ያለው መልኩ አደገ—ብዙ ባይነሪዎች፣ ብጁ ተጠቃሚዎች፣ firewall ደንቦች፣ ከፍ ያለ የማቀናበሪያ እርምጃ፣ በተመሳሳይ ጊዜ ማይከሰቱ ሂደቶች እና ሌሎችም።

በተለይ ቀላል ሥርዓት አይደለም፣ ነገር ግን እያንዳንዱ ውስብስብ ነገር በአስፈላጊነት ተጨምሮበታል፣ ይህም ደህንነቱ የተጠበቀ እና በተቻለ መጠን በተጠቃሚው መንገድ ላይ የማይሆን sandbox ለመገንባት ነው።

ለWindows ላይ ያሉ የCodex ተጠቃሚዎች ጥሩ የተጠቃሚ ተሞክሮ ለማቅረብ በመሥራት፣ ግባችን ጠቃሚነትን ሳይጎዳ ደኅና የሆነ ነገር መፍጠር ነበር—Codexን የመጠቀም ዋና ነጥብ ወኪሎች ያለ ቀጣይ ትኩረትዎ ሥራ እንዲሠሩ ማድረግ ነው።

ከዚህ ፕሮጀክት ያገኘናቸው ትልቁ ትምህርቶች አንዱ ይህ ነበር፦ Windows «አስተማማኝ ራስ-ገዝ የኮድ ወኪል» ጋር በንጹህ ሁኔታ የሚዛመድ አንድ መሠረታዊ አካል አልሰጠንም። ተዋረድ ያለውን አንድ ነገር ለመገንባት ብዙ መሣሪያዎች እና ሐሳቦች አቀናጅተናል። አንዳንድ ቀደምት ሐሳቦች ግብ የሌላቸው መንገዶች ነበሩ። የመጨረሻው ንድፍ እያንዳንዳቸው የችግሩን ክፍል የፈቱ የቀድሞ ፕሮቶታይፖች ጥምረት ነበር።

ሌላው ትምህርት ደግሞ ለኮድ ወኪል ደኅንነት ከተለመደው የመተግበሪያ ደኅንነት የተለየ መሆኑ ነው። Codex ለእውነተኛ የገንቢ የሥራ ሂደቶች መሥራት አለበት። የምህንድስና ሥራው ከወኪላዊ የሥራ ጫናዎች ጋር ተኳኋኝነትን ከእውነተኛ ማስፈጸሚያ ጋር ማመዛዘን ነበር። ይህ ግጭት በመጨረሻው ንድፍ ውስጥ ያሉትን ልውውጦች ቀረጸ።

የCodex sandboxን በተግባር ማየት ይፈልጋሉ? ይሞክሩት⁠።