Windows-ൽ Codex പ്രവർത്തനക്ഷമമാക്കാൻ സുരക്ഷിതവും ഫലപ്രദവുമായ സാൻഡ്ബോക്സ് നിർമ്മിക്കൽ

2025 സെപ്റ്റംബറിൽ ഞാൻ Codex എഞ്ചിനീയറിംഗ് ടീമിൽ ചേർന്നപ്പോൾ, Windows-നുള്ള Codex-ന് സാൻഡ്ബോക്സ് ഇംപ്ലിമെന്റേഷൻ ഉണ്ടായിരുന്നില്ല, അതായത് OpenAI-യുടെ കോഡിംഗ് ഏജന്റുകൾ ഉപയോഗിക്കുമ്പോൾ Windows ഉപയോക്താക്കൾക്ക് രണ്ട് തൃപ്തികരമല്ലാത്ത ഓപ്ഷനുകളിൽ ഒന്ന് തിരഞ്ഞെടുക്കണമായിരുന്നു:

1. കോഡിംഗ് ഏജന്റ് പ്രവർത്തിപ്പിക്കാൻ ആഗ്രഹിക്കുന്ന മിക്കവാറും എല്ലാ കമാൻഡുകൾക്കും (വായനകൾ പോലും) അനുമതി നൽകേണ്ടി വരുന്നത് കാര്യക്ഷമമല്ലാത്തതും മടുപ്പിക്കുന്നതുമാണ്. Codex ഉപയോഗിക്കുന്നതിന്റെ ഒരു പ്രധാന നേട്ടം, മടുപ്പിക്കുന്ന മുഴുവൻ ജോലിയും നിങ്ങൾ തന്നെ ചെയ്യേണ്ടതില്ല എന്നതാണ്.
2. ഫുൾ ആക്‌സസ് മോഡ് പ്രവർത്തനക്ഷമമാക്കുന്നു: അംഗീകാരങ്ങളോ നിയന്ത്രണങ്ങളോ ഇല്ലാതെ എല്ലാ കമാൻഡുകളും പ്രവർത്തിപ്പിക്കാൻ Codex-നെ അനുവദിക്കുന്നു; ഇത് മേൽനോട്ടം കുറയ്ക്കുന്നതിലൂടെ തടസ്സങ്ങൾ ഇല്ലാതാക്കുന്നു.

Codex⁠, നമ്മുടെ കോഡിംഗ് ഏജന്റ്, ഡെവലപ്പർ ലാപ്‌ടോപ്പുകളിലാണ് പ്രവർത്തിക്കുന്നത്—അത് CLI വഴിയോ, IDE എക്സ്റ്റൻഷൻ വഴിയോ, അല്ലെങ്കിൽ ഡെസ്ക്ടോപ്പ് ആപ്പ് വഴിയോ ആയിരിക്കാം. ഇൻഫറൻസ് കൈകാര്യം ചെയ്യാൻ, കീബോർഡിന് മുന്നിലുള്ള മനുഷ്യനും ക്ലൗഡിൽ പ്രവർത്തിക്കുന്ന മോഡലും തമ്മിലുള്ള സംഭാഷണം ഇത് കൈകാര്യം ചെയ്യുന്നു.

Codex സ്വഭാവികമായി യഥാർത്ഥ ഉപയോക്താവിന്റെ അനുമതികളോടെയാണ് പ്രവർത്തിക്കുന്നത്, അതിനാൽ ഉപയോക്താവിന് ചെയ്യാൻ കഴിയുന്നതെല്ലാം ഇതിന് ചെയ്യാനും കഴിയും. ഇത് ശക്തമാണ്, പക്ഷേ അപകടസാധ്യതയും ഉണ്ട്. കോഡിംഗ് മോഡൽ ഹാർനസിനോട് കമാൻഡുകൾ ലോക്കലായി പ്രവർത്തിപ്പിക്കാൻ പറയാം, ടെസ്റ്റുകൾ നടത്തുന്നത് മുതൽ ഫയൽ വായിക്കുകയോ തിരുത്തുകയോ Git ബ്രാഞ്ച് സൃഷ്ടിക്കുകയോ വരെയാണിത്. അതുവഴി Codex-ന്റെ ഡിഫോൾട്ട് മോഡ് ഫലപ്രാപ്തിയും സുരക്ഷയും തമ്മിലുള്ള ശരിയായ ബാലൻസ് കണ്ടെത്താൻ ശ്രമിക്കുന്നു. ഈ ഡിഫോൾട്ട് മോഡ്, മിക്കവാറും എല്ലാ സ്ഥലങ്ങളിലുമുള്ള ഫയലുകൾ വായിക്കാനും നിങ്ങളുടെ വർക്ക്‌സ്പേസിനുള്ളിൽ (അതായത് നിങ്ങൾ Codex പ്രവർത്തിപ്പിക്കുന്ന ഡയറക്ടറി) ഫയലുകൾ എഴുതാനും Codex-നെ അനുവദിക്കുന്നു; നിങ്ങൾ പ്രത്യേകം ആവശ്യപ്പെടാത്ത പക്ഷം ഇതിന് ഇന്റർനെറ്റ് ആക്‌സസ് ഉണ്ടായിരിക്കില്ല. ഫയലുകൾ എഴുതുന്നതിനും നെറ്റ്‌വർക്ക് ആക്‌സസ് ചെയ്യുന്നതിനും സുരക്ഷിതമായ പരിധിക്കുള്ളിൽ നിന്നുകൊണ്ട് സ്വയമേവ ഇത്തരമൊരു നിയന്ത്രണം സാധ്യമാക്കുന്നതിന്, ഈ നിബന്ധനകൾ കൃത്യമായി നടപ്പിലാക്കുന്ന ഒരു സാൻഡ്‌ബോക്സ് എൻവയോൺമെന്റ് Codex-ന് ആവശ്യമാണ്.

ഒരു sandbox എന്നത് നിയന്ത്രിതമായ ഒരു നിർവഹണ പരിതസ്ഥിതിയാണ്. ഒരു ഡെവലപ്പർ Codex ഉപയോഗിക്കുമ്പോൾ, അവരുടെ കമ്പ്യൂട്ടറിലെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം കുറഞ്ഞ അനുമതികളോടെ ഒരു കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയും ആ നിയന്ത്രണങ്ങൾ പ്രോസസ്സ് ട്രീയുടെ താഴേക്കു വ്യാപിക്കുകയും ചെയ്യുന്നു. ഓരോ Codex കമാൻഡും ആരംഭം മുതൽ സാൻഡ്ബോക്‌സിൽ ഒതുക്കപ്പെട്ടിരിക്കും, കൂടാതെ അതിൽ നിന്ന് ഉത്ഭവിക്കുന്ന ഓരോ പ്രോസസും അതേ പരിധിക്കുള്ളിൽ തന്നെ തുടരും.

ഒരു ഫലപ്രദമായ സാൻഡ്‌ബോക്സ് നടപ്പിലാക്കുന്നതിന്, കമ്പ്യൂട്ടറിലെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം നിർബന്ധമായും നടപ്പിലാക്കുന്ന ഐസൊലേഷൻ ഫീച്ചറുകൾ Codex-ന് ആവശ്യമാണ്. ചില ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾ ഇതിനായി മികച്ച യൂട്ടിലിറ്റികൾ നൽകുന്നുണ്ട് (ഉദാഹരണത്തിന്: MacOS-ലെ Seatbelt, Linux-ലെ seccomp അല്ലെങ്കിൽ bubblewrap); എന്നാൽ, Windows-ൽ നിലവിൽ ഇത്തരം സംവിധാനങ്ങൾ നേരിട്ട് ലഭ്യമായ രീതിയിൽ നൽകുന്നില്ല.

Windows-ലും Codex-ന്റെ ഉപയോഗം മറ്റെല്ലാ ഇടങ്ങളിലുമെന്നപോലെ സുരക്ഷിതവും മികച്ചതുമാക്കുന്നതിന്, ഞങ്ങൾക്ക് സ്വന്തമായി ഒരു സാൻഡ്‌ബോക്സ് നടപ്പിലാക്കേണ്ടതുണ്ടായിരുന്നു.

Windows ഐസൊലേഷനായി ചില ടൂളുകളും പ്രിമിറ്റീവ്സുകളും വാഗ്ദാനം ചെയ്യുന്നുണ്ട്. അവയിലൊന്നും ഞങ്ങളുടെ ആവശ്യകതകൾ പൂർണ്ണമായി നിറവേറ്റുന്നവ ആയിരുന്നില്ലെങ്കിലും, സാധ്യമായ നിരവധി പരിഹാരങ്ങൾ ഞങ്ങൾ പരിശോധിച്ചു—പ്രത്യേകിച്ച് AppContainer, Windows Sandbox, മാൻഡേറ്ററി ഇന്റഗ്രിറ്റി കൺട്രോൾ ലേബലിംഗ് എന്നിവ.

AppContainer

• എന്താണത്: Windows-ലെ നേറ്റീവ് സാൻഡ്‌ബോക്സ് സംവിധാനമാണ് AppContainer; ഏതൊക്കെ കാര്യങ്ങൾ ആക്‌സസ് ചെയ്യണമെന്ന് മുൻകൂട്ടി കൃത്യമായി അറിയാവുന്ന ആപ്പുകൾക്കായി നിർമ്മിച്ച, ശേഷി അധിഷ്ഠിത ഐസൊലേഷൻ മോഡൽ ആണ് ഇത്.
• എന്തുകൊണ്ട്: ശക്തമായ നിയന്ത്രണങ്ങൾക്കു പകരം യഥാർത്ഥ OS പരിധികള്‍ വാഗ്ദാനം ചെയ്യുന്നു എന്നത് ഇതിനെ കൂടുതൽ ആകർഷകമാക്കുന്നു.
• എന്തുകൊണ്ട് വേണ്ട: Codex ഒരു കർശനമായി പരിമിതപ്പെടുത്തിയ പരിധിയിലുള്ള ഒറ്റ ആപ്പ് അല്ല. ഇത് തുറന്ന സ്വഭാവമുള്ള ഡെവലപ്പർ വർക്ക്ഫ്ലോകൾ പ്രവർത്തിപ്പിക്കുന്നു: ഷെല്ലുകൾ, Git, Python, പാക്കേജ് മാനേജർമാർ, ബിൽഡ് ടൂളുകൾ, കൂടാതെ ഏജന്റിന് ആവശ്യമാണെന്ന് തീരുമാനിക്കുന്ന മറ്റേതെങ്കിലും ബൈനറികൾ. പ്രായോഗികമായി, അത് AppContainer-നെ ആ പ്രശ്നത്തിന് യോജിക്കാത്ത ഘടനയാക്കി. അത് ശക്തമായ ഐസൊലേഷനായിരുന്നു, പക്ഷേ “ഒരു ഏജന്റിനെ ഡെവലപ്പറെപ്പോലെ പ്രവർത്തിക്കാൻ അനുവദിക്കുക” എന്നതിനെക്കാൾ വളരെ ചുരുങ്ങിയ തരത്തിലുള്ള വർക്ക്‌ലോഡുകൾക്കായുള്ളതായിരുന്നു.

Windows Sandbox

• എന്ത്: Windows Sandbox എന്നത് Microsoft-ന്റെ ഉപയോഗശേഷം ഉപേക്ഷിക്കാവുന്ന ലഘുഭാര VM ആണ്. ശക്തമായ ഐസൊലേഷൻ അതിർത്തിയോടു കൂടിയ ഒരു പുതിയ Windows ഡെസ്ക്ടോപ്പ് ഇതിലൂടെ നിങ്ങൾക്ക് ലഭിക്കുന്നു; അതിനുള്ളിൽ നിങ്ങൾ ചെയ്യുന്ന കാര്യങ്ങളെല്ലാം സെഷൻ അവസാനിക്കുമ്പോൾ ഇല്ലാതാകുകയും ചെയ്യും.
• എന്തുകൊണ്ട്: വ്യക്തമായ കാരണങ്ങളാൽ ശ്രദ്ധേയമാണ്—AppContainer-നെ അപേക്ഷിച്ച് ഏതു തരത്തിലുള്ള സോഫ്റ്റ്‌വെയറുമായും വളരെ കൂടുതൽ പൊരുത്തപ്പെടുന്നു, കൂടാതെ സുരക്ഷാ കാഴ്ചപ്പാടിൽ ഇത് വളരെ ശക്തമായ ഒരു സാൻഡ്‌ബോക്സാണ്.
• എന്തുകൊണ്ടല്ല: Codex-ന് ഉപയോക്താവിന്റെ യഥാർത്ഥ ചെക്ക്ഔട്ട്, ടൂളുകൾ, എൻവയോൺമെന്റ് എന്നിവയിൽ നേരിട്ട് പ്രവർത്തിക്കേണ്ടതുണ്ട്; അല്ലാതെ സജ്ജീകരണങ്ങളും ഹോസ്റ്റ്/ഗസ്റ്റ് ബ്രിഡ്ജിംഗും ആവശ്യമായ മറ്റൊരു വേറിട്ട, താത്കാലിക ഡെസ്ക്ടോപ്പിനുള്ളിലല്ല പ്രവര്‍ത്തിക്കേണ്ടത്. ഇതിന് മറ്റൊരു അടിസ്ഥാനപരമായ ഉൽപ്പന്ന പ്രശ്നവും ഉണ്ടായിരുന്നു: Windows Home SKU-കളിൽ Windows Sandbox പോലും ലഭ്യമല്ല.

മാൻഡേറ്ററി ഇന്റഗ്രിറ്റി കൺട്രോൾ (MIC) ഇന്റഗ്രിറ്റി ലേബലിംഗ്

• എന്ത്: താഴ്ന്ന, ഇടത്തരം, ഉയർന്ന എന്നിവ പോലുള്ള “സമഗ്രതാ നിലകൾ” എന്ന ആശയം Windows-ലുണ്ട്; ഒബ്ജക്റ്റുകളെയും പ്രോസസ്സുകളെയും സിസ്റ്റം എത്രത്തോളം വിശ്വസിക്കുന്നു എന്ന് ഇവ നിർണ്ണയിക്കുന്നു. അടിസ്ഥാന നിയമം എന്തെന്നാൽ, സാധാരണ ACL അത് അനുവദിക്കുന്നതായിരുന്നാലും, താഴ്ന്ന അഖണ്ഡതയുള്ള ഒരു പ്രോസസിന് ഉയർന്ന അഖണ്ഡത നിലയുള്ള ഒരു ഒബ്ജക്റ്റിലേക്ക് എഴുതാൻ കഴിയില്ല. ഉദാഹരണത്തിന്, കുറഞ്ഞ ഇന്റഗ്രിറ്റി പ്രോസസ് കുറച്ച് മാത്രം വിശ്വസനീയമായതായി കണക്കാക്കപ്പെടുന്നു, അതിനാൽ Windows അതിനെ സാധാരണ ഇടത്തരം ഇന്റഗ്രിറ്റി ഒബ്ജക്റ്റുകളിലേക്ക് എഴുതുന്നതിൽ നിന്ന് തടയും, അല്ലെങ്കില്‍ അത് അനുവദിക്കുന്നതിനായി ആ ഒബ്ജക്റ്റുകൾ വ്യക്തമായി റീലേബൽ ചെയ്യണം.
• എന്തുകൊണ്ട്: MIC കടലാസിൽ വളരെ മികച്ചതായി തോന്നി—Codex-നെ ലോ-ഇന്റഗ്രിറ്റിയിൽ പ്രവർത്തിപ്പിക്കുക, റൈറ്റ് ചെയ്യാവുന്ന റൂട്ടുകളെ ലോ-ഇന്റഗ്രിറ്റി എന്ന് മാറ്റി ലേബൽ ചെയ്യുക, മറ്റ് എല്ലായിടത്തും ഡാറ്റ എഴുതുന്നില്ലെന്ന് Windows-നെക്കൊണ്ട് ഉറപ്പുവരുത്തുക. അത് പിന്നിൽ ഒരു യഥാർത്ഥ OS സംവിധാനത്തിന്റെ പിന്തുണയുള്ള, അഡ്മിൻ അല്ലാത്ത ഒരു മാർഗം നമുക്ക് നൽകിയേനേ.
• എന്തുകൊണ്ട് വേണ്ട: ACL-കളെപ്പോലെ, ഇന്റഗ്രിറ്റി ലേബലുകൾ യഥാർത്ഥ ഹോസ്റ്റ് ഫയൽസിസ്റ്റത്തെ മാറ്റുന്നു, ഈ സാഹചര്യത്തിൽ അർത്ഥതലത്തിലുള്ള മാറ്റം പ്രത്യേകിച്ച് വ്യാപകമാണ്. ഒരു വർക്ക്സ്പേസ് ലോ ഇന്റഗ്രിറ്റി ആയി അടയാളപ്പെടുത്തുന്നത് “Codex-ന് ഇവിടെ എഴുതാൻ കഴിയും.” എന്നതിനെ മാത്രം സൂചിപ്പിക്കുന്നതല്ല. അതായത്, ലോ-ഇന്റഗ്രിറ്റി പ്രോസസ്സുകൾക്ക് പൊതുവെ അവിടെ എഴുതാൻ കഴിയും. ഒരു യഥാർത്ഥ ഡെവലപ്പർ മെഷീനിൽ, അത് ഉപയോക്താവിന്റെ യഥാർത്ഥ കോഡ് ചെക്ക്ഔട്ടിനെ ഹോസ്റ്റിനായി ഒരു ലോ-ഇന്റഗ്രിറ്റി സിങ്കായി മാറ്റുന്നു; ഒരു സാൻഡ്‌ബോക്സ് രൂപകൽപ്പനയ്ക്ക് സൂക്ഷ്മമായി ലക്ഷ്യമിട്ട ACL-കൾ അനുവദിക്കുന്നതിനെക്കാൾ ഇത് ഏറെ അപകടസാധ്യതയുള്ളതാണ്. മീഡിയം-ഇന്റഗ്രിറ്റി ഡെവലപ്പർ ടൂളുകൾ തുടർന്നും പ്രവർത്തിച്ചാലും, വർക്ക്സ്പേസ് അടിസ്ഥാന വിശ്വാസ മോഡൽ നിയന്ത്രിച്ചു നിർത്താൻ പ്രയാസമുള്ളതും ന്യായീകരിക്കാൻ അതിലും പ്രയാസമുള്ളതുമായ രീതിയിൽ മാറിയിരിക്കുന്നു.

ലഭ്യമായ എല്ലാ ഓപ്ഷനുകളും പ്രായോഗികമല്ലെന്ന് വിലയിരുത്തിയ ശേഷം, Windows ഉപയോക്താക്കൾക്ക് മികച്ച Codex അനുഭവം നൽകുന്നതിനായി ഞങ്ങൾ സ്വന്തമായൊരു പരിഹാരം വികസിപ്പിക്കാൻ ആരംഭിച്ചു.

ഞങ്ങൾക്ക് ആവശ്യമായ ഐസൊലേഷൻ നടപ്പിലാക്കാൻ Windows ആശയങ്ങളുടെയും ഉപകരണങ്ങളുടെയും സംയോജനം ഉപയോഗിച്ചായിരുന്നു ഞങ്ങളുടെ ആദ്യത്തെ പ്രവർത്തിക്കുന്ന പ്രോട്ടോട്ടൈപ്പ്. തുടക്കം മുതൽ തന്നെ, elevation ആവശ്യമില്ലാതെ ഇത് പ്രവർത്തിക്കുന്നതാക്കുക എന്നത് ഒരു ലക്ഷ്യമായിരുന്നു; അതായത്, സാൻഡ്‌ബോക്സ് സജ്ജീകരിക്കാനോ പ്രവർത്തിപ്പിക്കാനോ മാത്രം Codex ഉപയോക്താവിനോട് അഡ്മിനിസ്ട്രേറ്റർ പ്രത്യേകാവകാശങ്ങൾക്കായി പ്രോംപ്റ്റ് ചെയ്യേണ്ടതില്ല. അതിന്റെ അർത്ഥം രണ്ട് കാര്യങ്ങൾക്ക് യുക്തിസഹമായ പരിധികൾ എങ്ങനെ ഏർപ്പെടുത്താമെന്ന് കണ്ടെത്തുക എന്നായിരുന്നു: ഫയലിലേക്ക് എഴുതൽ, നെറ്റ്‌വർക്ക് ആക്‌സസ്.

ഫയൽ റൈറ്റുകൾ നമ്മൾ ഒട്ടും പരിമിതപ്പെടുത്തിയില്ലെങ്കിൽ അതൊരു സുരക്ഷാ പ്രശ്നത്തിന് കാരണമാകുമായിരുന്നു. ഫയൽ റൈറ്റുകൾ അമിതമായി പരിമിതപ്പെടുത്തിയാൽ, നിരന്തരമായി അനുമതികൾ ചോദിക്കേണ്ടി വരികയും സാൻഡ്ബോക്സ് ഉപയോക്താവിന്റെ ഉൽപ്പാദനക്ഷമതയെ പ്രതികൂലമായി ബാധിക്കുകയും ചെയ്യുമായിരുന്നു. ഈ പ്രശ്നം പരിഹരിക്കുന്നതിനായി, Windows-ന്റെ രണ്ട് പ്രധാന അടിസ്ഥാന ഘടകങ്ങളെ ഞങ്ങൾ ആശ്രയിച്ചു: SID-കളും റൈറ്റ്-നിയന്ത്രിത ടോക്കണുകളും.

SID, അഥവാ സുരക്ഷാ ഐഡന്റിഫയർ, അനുമതികളുമായി Windows ബന്ധിപ്പിക്കുന്ന തിരിച്ചറിയലാണ്. ഓരോ ഉപയോക്താവിനും ഒരു SID ഉണ്ടാകും, ഗ്രൂപ്പുകൾക്ക് SID-കൾ ഉണ്ടാകും, ഒറ്റ ലോഗിൻ സെഷന് പോലും സ്വന്തമായൊരു SID ലഭിക്കും. ഉദാഹരണത്തിന്, നിലവിൽ ലോഗിൻ ചെയ്‌തിരിക്കുന്ന ഒരു സെഷനിൽ S-1-5-5-X-Y പോലുള്ള ഒരു SID ഉണ്ടായിരിക്കാം. പ്രാദേശിക അഡ്മിനിസ്ട്രേറ്റർമാരുടെ ഗ്രൂപ്പിന് അസൈൻ ചെയ്തിരിക്കുന്ന SID S-1-5-32-544 ആയിരിക്കാം.

ഒരു യഥാർത്ഥ ഉപയോക്താവിന്റേതല്ലാത്ത കൃത്രിമ SID-കൾ സൃഷ്ടിക്കാൻ Windows നിങ്ങളെ അനുവദിക്കുന്നു. എങ്കിലും നിർദ്ദിഷ്ട ഫയലുകളോ ഡയറക്‌ടറികളോ ആർക്കൊക്കെ വായിക്കാൻ/എഴുതാൻ/പ്രവർത്തിപ്പിക്കാൻ സാധിക്കുമെന്ന് നിർവചിക്കുന്ന ACL-കളിൽ (ആക്സസ് കൺട്രോൾ ലിസ്റ്റുകൾ) ഇവയ്ക്ക് പ്രത്യക്ഷപ്പെടാൻ കഴിയും. ഇത് SID-കളെ നമ്മുടെ സാൻഡ്ബോക്സിന് ഉപയോഗപ്രദമായ ഒരു അടിസ്ഥാന ഘടകമാക്കുന്നു: മെഷീനിലെ മറ്റൊന്നിനെയും തടസ്സപ്പെടുത്താത്ത രീതിയിൽ Codex സാൻഡ്ബോക്സിന് മാത്രം ഉപയോഗിക്കാനായി നമുക്ക് SID-കൾ നിർമ്മിക്കാൻ കഴിയും.

പ്രോസസ് ടോക്കൺ എന്നത് പ്രവർത്തിക്കുന്ന ഒരു പ്രോസസിന്റെ ഐഡന്റിറ്റിയും പ്രത്യേകാവകാശങ്ങളും നിർവചിക്കുന്ന Windows-ലെ സുരക്ഷാ ഒബ്ജക്റ്റുകളാണ്. ഒരു പ്രക്രിയയ്ക്ക് ഏതെല്ലാം പ്രവർത്തനങ്ങൾ നടത്താനാകുമെന്ന് അവ നിർണ്ണയിക്കുന്നു. ഒരു റൈറ്റ്-നിയന്ത്രിത ടോക്കൺ എന്നത് ഒരു പ്രത്യേക തരം പ്രോസസ്സ് ടോക്കൺ ആണ്, ഇത് റൈറ്റ് പ്രവർത്തനങ്ങളിൽ ഒരു അധിക ആക്‌സസ് പരിശോധന നടത്താൻ Windows-നെ പ്രേരിപ്പിക്കുന്നു.

ഒരു റൈറ്റ് വിജയകരമാകണമെങ്കിൽ, രണ്ട് പരിശോധനകൾ വിജയിക്കേണ്ടതുണ്ട്:

1. സാധാരണ ഉപയോക്തൃ ഐഡന്റിറ്റിക്ക് (ടോക്കൺ “ഉടമ”) അത് ചെയ്യാനുള്ള അനുമതി ഉണ്ടായിരിക്കണം
2. ടോക്കണിന്റെ നിയന്ത്രിത SID ലിസ്റ്റിലുള്ള ഒരു SID-ക്കെങ്കിലും ആക്സസ് അനുവദിച്ചിരിക്കണം

പ്രായോഗികമായി, സാൻഡ്‌ബോക്‌സിന് ഫയൽസിസ്റ്റത്തിൽ എവിടെയൊക്കെ മാറ്റങ്ങൾ വരുത്താമെന്ന് കൃത്യമായി നിർണ്ണയിക്കാൻ ഈ പരിശോധനകൾ വഴി ACL-കൾ ഉപയോഗിക്കാൻ ഞങ്ങൾക്ക് സാധിക്കുന്നു; റൈറ്റ് ഓപ്പറേഷനുകളിൽ ഞങ്ങൾക്ക് ആവശ്യമായ സൂക്ഷ്മമായ നിയന്ത്രണം ഇത് നൽകുന്നു.

SID-കളും റൈറ്റ്-നിയന്ത്രിത ടോക്കണുകളും ഉപയോഗിച്ച്, ഞങ്ങളുടെ ഉന്നതമല്ലാത്ത സാൻഡ്‌ബോക്‌സ് ഇപ്രകാരമാണ് പ്രവർത്തിച്ചിരുന്നത്:

1. സാൻഡ്‌ബോക്‌സ് സജ്ജീകരണം സാൻഡ്‌ബോക്‌സ്-റൈറ്റ് എന്ന് വിളിക്കുന്ന ഒരു സിന്തറ്റിക് SID സൃഷ്ടിച്ചു.
2. sandbox-write SID-ന് എഴുതൽ, പ്രവർത്തനം, ഇല്ലാതാക്കൽ ആക്‌സസ് അനുവദിച്ചു
   1. നിലവിലെ പ്രവർത്തന ഡയറക്ടറി
   2. config.toml -ൽ കോൺഫിഗർ ചെയ്‌തിരിക്കുന്ന ഏതെങ്കിലും അധിക writable_roots.
3. സാൻഡ്ബോക്സ് സജ്ജീകരണം, “എഴുതാവുന്നവയിൽ വായിക്കാൻ മാത്രം” ലൊക്കേഷനുകളിലേക്കുള്ള അതേ SID റൈറ്റ് ആക്സസ് വ്യക്തമായി നിരസിച്ചു, ഉദാഹരണത്തിന്:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. നിയന്ത്രിത SID പട്ടികയിൽ എല്ലാവരും, നിലവിൽ ലോഗിൻ ചെയ്തിട്ടുള്ള സെഷൻ SID, സാൻഡ്‌ബോക്സ്-റൈറ്റ് സിന്തറ്റിക് SID എന്നിവ ഉൾപ്പെടുന്ന ഒരു റൈറ്റ്-നിയന്ത്രിത ടോക്കണിന് കീഴിലാണ് Codex കമാൻഡുകൾ പ്രവർത്തിപ്പിച്ചത്.

ഈ ഫ്ലോ ഫയൽ റൈറ്റുകളെ നിയന്ത്രിക്കുന്നതിൽ ഫലപ്രദമാവുകയും പ്രതീക്ഷ നൽകുന്നതായി തോന്നുകയും ചെയ്തു. ഇനി സാൻഡ്‌ബോക്സിന്റെ നെറ്റ്‌വർക്ക് ആക്‌സസ് പരിമിതപ്പെടുത്തുന്നതിനുള്ള ഒരു പരിഹാരമാണ് ഞങ്ങൾക്ക് ആവശ്യമായിരുന്നത്.

സാൻഡ്‌ബോക്‌സിന്റെ സുരക്ഷയിൽ നെറ്റ്‌വർക്ക് ആക്‌സസ് പരിമിതപ്പെടുത്തുന്നത് വളരെ പ്രധാനപ്പെട്ട ഒരു കാര്യമാണ്; അതില്ലെങ്കിൽ, മെഷീനിൽ നിന്നുള്ള വിവരങ്ങൾ ഇന്റർനെറ്റിലേക്ക് ചോർത്താൻ ദുരുദ്ദേശ്യപരമായ കോഡുകൾക്ക് സാധിക്കും. എലിവേഷൻ റിക്വയർമെന്റ് ഒഴിവാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചതുകൊണ്ട് തന്നെ, നെറ്റ്‌വർക്ക് ട്രാഫിക് ശക്തമായി തടയുന്നതിന് ഞങ്ങളുടെ മുന്നിൽ പരിമിതമായ വഴികളെ ഉണ്ടായിരുന്നുള്ളൂ. Windows Firewall പോലുള്ള ഞങ്ങൾ ഉപയോഗിക്കാൻ ഉദ്ദേശിച്ച ടൂളുകൾ അഡ്മിൻ പെർമിഷൻ ഇല്ലാതെ ഇൻസ്റ്റാൾ ചെയ്യാൻ സാധാരണ നിലയില്‍ കഴിയില്ലായിരുന്നു.

Windows Firewall ഒരു ഓപ്ഷനായി ഇല്ലാതിരുന്നതിനാൽ, ഞങ്ങൾക്ക് നിയന്ത്രിക്കാൻ കഴിയുന്ന കാര്യങ്ങൾ ഞങ്ങൾ പരിമിതപ്പെടുത്തി. ഡെവലപ്പർമാർ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന തരത്തിലുള്ള നെറ്റ്‌വർക്ക്-ആശ്രിത ടൂളുകൾക്കായി ചൈൽഡ് എൻവയോൺമെന്റ് fail-closed ആയി പ്രവർത്തിക്കുന്നവിധം രൂപപ്പെടുത്താൻ ഞങ്ങൾ ശ്രമിച്ചു; അങ്ങനെ 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-ൽ, ഞങ്ങൾ .sbpl സൃഷ്ടിക്കുന്ന രീതി ഡൈനാമിക്കായി മാറ്റാനാകും Seatbelt കോൺഫിഗർ ചെയ്യാൻ ഉപയോഗിക്കുന്ന ഫയൽ, Windows sandbox-ന് 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 (ഫയർവാൾ നിയമങ്ങളാൽ ലക്ഷ്യമിടാത്തത്)

ഈ ചെറിയ കാര്യത്തിന് സാൻഡ്‌ബോക്‌സിലും, അത് ആർക്കൊക്കെ ഉപയോഗിക്കാം എന്നതിലും, അതിന്റെ സജ്ജീകരണത്തിന്റെയും പ്രവർത്തനസമയ നിർവ്വഹണത്തിന്റെയും സങ്കീർണ്ണതയിലും വലിയ സ്വാധീനമുണ്ട്.

ഇത് എലിവേറ്റഡ് അല്ലാത്ത പ്രോട്ടോടൈപ്പിനോട് കാഴ്ചയിൽ സമാനമാണ്, എന്നാൽ ഫയർവാൾ നിയമങ്ങളും കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുന്നതിനായി ഒരു പ്രത്യേക Windows യൂസറെയും ഇതിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. (എങ്കിലും, ഈ പുതിയ ആശയങ്ങൾ അവതരിപ്പിക്കുന്നത് വഴി, സാൻഡ്‌ബോക്‌സ് കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കാനും അവയ്ക്ക് സംരക്ഷണം നൽകാനും തുടങ്ങുന്നതിന് മുമ്പായി കൂടുതൽ സജ്ജീകരണ പ്രവർത്തനങ്ങൾ ചെയ്യേണ്ടതുണ്ട്.)

എലിവേറ്റഡ് അല്ലാത്ത സാൻഡ്‌ബോക്‌സ് രൂപകൽപ്പനയിൽ ലളിതമായ ഒരു സെറ്റപ്പ് സ്റ്റെപ്പ് ഉണ്ടായിരുന്നു, എന്നാൽ അത് താരതമ്യേന ചെറുതായിരുന്നു:

• ആവശ്യമായാൽ ഒരു സിന്തറ്റിക് SID സൃഷ്ടിക്കുക
• സാൻഡ്‌ബോക്‌സ്-റൈറ്റ് സിന്തറ്റിക് SID-യ്ക്കായി ACL-കൾ പ്രയോഗിക്കുക

എങ്കിലും, എലിവേറ്റഡ് സാൻഡ്‌ബോക്‌സിന് കൂടുതൽ കാര്യങ്ങൾ ചെയ്യാനുണ്ട്.

• മുമ്പ് സൃഷ്ടിച്ചിട്ടില്ലെങ്കിൽ, ഒരു സിന്തറ്റിക് SID സൃഷ്ടിക്കുക
• ഓൺലൈൻ, ഓഫ്‌ലൈൻ സാൻഡ്‌ബോക്‌സ് ഉപയോക്താക്കളെ ഇതിനകം സൃഷ്ടിച്ചിട്ടില്ലെങ്കിൽ അവ സൃഷ്ടിക്കുക
• പുതിയതായി സൃഷ്ടിച്ച ഉപയോക്താക്കളുടെ ക്രെഡൻഷ്യലുകൾ ലോക്കലായി സംഭരിക്കുകയും, സാൻഡ്‌ബോക്‌സ് ഉപയോക്താക്കൾക്ക് യഥാർത്ഥത്തിൽ വായിക്കാൻ കഴിയാത്ത ഒരിടത്ത് Windows ഡാറ്റ പ്രൊട്ടക്ഷൻ API (DPAPI) ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യുകയും ചെയ്യുക
• CodexSandboxOffline ഉപയോക്താവിന്റെ എല്ലാ ഔട്ട്ബൗണ്ട് നെറ്റ്‌വർക്ക് ആക്സസ്സും തടയുന്ന ഫയർവാൾ നിയമങ്ങൾ സൃഷ്ടിക്കുക, അല്ലെങ്കിൽ അവ നിലവിലുണ്ടെങ്കിൽ അവ ശരിയാണെന്ന് വാലിഡേറ്റ് ചെയ്യുക

സജ്ജീകരണ ഘട്ടത്തിൽ ഒരു അധിക സങ്കീർണതയുണ്ട്. Codex-ന്റെ സാൻഡ്‌ബോക്സിന് യഥാർത്ഥ Windows ഉപയോക്താവിന് തുല്യമായ റീഡ് ആക്‌സസ് ഉണ്ടായിരിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു. ഉയർന്ന അധികാരങ്ങളില്ലാത്ത സാൻഡ്ബോക്സിൽ, നിയന്ത്രിത ടോക്കണിന്റെ പ്രിൻസിപ്പൽ SID Windows ഉപയോക്താവായിരുന്നിടത്ത്, ഇത് കൈവരിക്കപ്പെട്ടു. എന്നിരുന്നാലും, പ്രിൻസിപ്പൽ ഒരു പുതിയ CodexSandbox ഉപയോക്താവാകുമ്പോൾ അത് ചെലവില്ലാതെ ലഭിക്കുന്നതല്ല. Windows-ലെ പ്രസക്തമായ പല ഡയറക്ടറികളും “Authenticated Users” എന്നതിന് വായന/പ്രവർത്തിപ്പിക്കൽ അനുമതികൾ നൽകും. ശ്രദ്ധേയമായ ഒരു ഉദാഹരണം ഉപയോക്താവിന്റെ പ്രൊഫൈൽ ഡയറക്ടറിയാണ്. സ്ഥിരസ്ഥിതിയായി, Windows ഉപയോക്താക്കൾക്ക് മറ്റ് Windows ഉപയോക്താക്കളുടെ പ്രൊഫൈൽ ഡയറക്ടറികൾ വായിക്കാൻ കഴിയില്ല, അതിനാൽ പല സാഹചര്യങ്ങളിലും ലളിതമായ ഫയൽ വായിക്കൽ പ്രവർത്തനങ്ങൾ പോലും പരാജയപ്പെടും.

ഇത് പരിഹരിക്കുന്നതിനായി, സാൻഡ്‌ബോക്‌സ് സെറ്റപ്പ് പ്രക്രിയയിൽ ഞങ്ങൾ മറ്റൊരു ഘട്ടം കൂടി ഉൾപ്പെടുത്തി—സാൻഡ്‌ബോക്‌സ് ഉപയോക്താക്കൾക്ക് നിലവിൽ റീഡ് ACL ഇല്ലാത്തയിടങ്ങളിൽ അവ അനുവദിക്കുന്നതിനായാണിത്. ഉദാഹരണത്തിന്, സാധാരണയായി ഉപയോഗിക്കുന്ന ചില Windows ഡയറക്ടറികളിലേക്ക്:

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

ഈ ഡയറക്‌ടറികളുടെ പട്ടിക ഏറ്റവും മികച്ച രീതിയിലുള്ള ഒരു ശ്രമം മാത്രമായതിനാലും, ഓരോന്നിലും ACL-കൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നത് വലിയ പ്രയത്നം ആവശ്യമായ കാര്യമായതിനാലും, ഞങ്ങൾ ഈ ലോജിക് സമയബന്ധിതമല്ലാത്ത ഒന്ന് ആയിട്ടാണ് പ്രവർത്തിപ്പിക്കുന്നത്. അതിനാൽ ഉപയോക്താക്കളെ തടഞ്ഞുവെക്കുന്ന സാൻഡ്‌ബോക്‌സ് സെറ്റപ്പ് ഘട്ടത്തിന് ഇവ പൂർത്തിയാകുന്നതുവരെ കാത്തിരിക്കേണ്ടി വരുന്നില്ല.

ആവശ്യമുള്ളപ്പോൾ മാത്രം UAC അതിർത്തി കടക്കുന്നതിനായി ഭാഗികമായി, സെറ്റപ്പ് ലോജിക് അതിന്റെ സ്വന്തം ബൈനറിയിൽ ഞങ്ങൾ ഉൾക്കൊള്ളിച്ചു. എന്നാൽ കൂടുതൽ ആഴത്തിലുള്ള കാരണം ആർക്കിടെക്ചറുമായി ബന്ധപ്പെട്ടതായിരുന്നു: സാൻഡ്‌ബോക്സ് സജ്ജീകരണത്തിന്റെ ചുമതല codex.exe-യുടേതിൽ നിന്ന് അടിസ്ഥാനപരമായി വ്യത്യസ്തമാണ്. സാൻഡ്‌ബോക്‌സ് സെറ്റപ്പ് ലോജിക് ഒരു പ്രത്യേക ബൈനറിയിൽ സൂക്ഷിക്കുന്നത് വഴി codex.exe -നെ സാധാരണ നിലയിലുള്ള, എലിവേറ്റഡ് അല്ലാത്ത ഒരു ഹാർനെസ് ആയി നിലനിർത്താൻ സാധിച്ചു; Windows-ൽ മാത്രം ആവശ്യമുള്ള സെറ്റപ്പ് സംവിധാനങ്ങൾ മറ്റ് പ്ലാറ്റ്‌ഫോമുകളിലെ codex.exe -ന്റെ വലിപ്പം കൂട്ടുന്നത് ഒഴിവാക്കി; ദൈർഘ്യമേറിയ സെറ്റപ്പ് ജോലികളെ പ്രധാന പ്രോസസിന്റെ പ്രവര്‍ത്തന സമയത്തില്‍ നിന്ന് വേർപെടുത്തി; കൂടാതെ സാൻഡ്‌ബോക്‌സിന് ആവശ്യമായ വ്യത്യസ്ത സെറ്റപ്പ് പാതകൾ കൈകാര്യം ചെയ്യാൻ ഒരു കേന്ദ്രീകൃത ഇടം ഞങ്ങൾക്ക് നൽകി.

Windows ഉപയോക്താവ്, ടോക്കൺ ലോഗിൻ ബൗണ്ടറികൾ എന്നിവ പ്രവർത്തിക്കുന്ന രീതി കാരണം, എലിവേറ്റഡ് അല്ലാത്ത സാൻഡ്‌ബോക്‌സിൽ ചെയ്തതുപോലെ ഒരു നിയന്ത്രിത ടോക്കൺ സൃഷ്ടിക്കാനോ അതിന് കീഴിൽ ഒരു പ്രോസസ്സ് ആരംഭിക്കാനോ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല. മറ്റൊരു Windows ഉപയോക്താവായി കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് ഞങ്ങളുടെ ആദ്യത്തെ ആശയം താഴെ പറയുന്ന രീതിയിലായിരുന്നു:

• codex.exe യഥാർത്ഥ Windows ഉപയോക്താവായി പ്രവർത്തിക്കുന്നു. തുടർന്ന്, ഒരു ക്രമത്തിൽ, Codex:
  • സാൻഡ്ബോക്സ് ഉപയോക്താവിനായി LogonUserW(...) വിളിക്കുന്നു.
  • ആ സാൻഡ്‌ബോക്‌സ്-ഉപയോക്തൃ ടോക്കണിൽ CreateRestrictedToken(...) വിളിക്കുന്നു.
  • ആ നിയന്ത്രിത sandbox-user ടോക്കൺ ഉപയോഗിച്ച്, അവസാനത്തെ ചൈൽഡ് പ്രോസസ് ആരംഭിക്കാൻ CreateProcessAsUserW(...) വിളിക്കുന്നു.

പ്രായോഗികമായി, CreateProcessAsUserW(...) എന്നിടത്തെ ഒരു പ്രിവിലേജ് തടസ്സം കാരണം ആ ഉദ്ദേശിച്ച ഫ്ലോ പ്രവർത്തിച്ചില്ല. ഇതിന്റെ അർത്ഥം codex.exe -യ്ക്ക് സാൻഡ്‌ബോക്സ് ഉപയോക്താവിനായി ഒരു നിയന്ത്രിത ടോക്കൺ സൃഷ്ടിക്കാൻ കഴിഞ്ഞിരുന്നെങ്കിലും, അതിരിന്റെ യഥാർത്ഥ ഉപയോക്തൃ വശത്ത് നിന്ന് ആ ടോക്കൺ ഉപയോഗിച്ച് ഒരു ചൈൽഡ് പ്രോസസ് വിശ്വസനീയമായി ആരംഭിക്കാൻ കഴിഞ്ഞില്ല എന്നാണ്. സാൻഡ്ബോക്സ് ഉപയോക്താവായി ഇതിനകം പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു പ്രോസസ് ഞങ്ങൾക്ക് ആവശ്യമായിരുന്നു—ഇതിലൂടെ നിയന്ത്രണ ഘട്ടവും അന്തിമ പ്രോസസ് സൃഷ്ടിക്കലും അതിർത്തിയുടെ യഥാർത്ഥ-ഉപയോക്തൃ വശത്തിന് പകരം സാൻഡ്ബോക്സ്-ഉപയോക്തൃ വശത്ത് നടക്കാൻ സാധിക്കും.

ആ ആവശ്യകത codex-command-runner.exe എന്ന പുതിയ ബൈനറിയിലേക്ക് നയിച്ചു; അതിന്റെ ഏക ജോലി ഒരു നിയന്ത്രിത ടോക്കൺ സൃഷ്ടിക്കുകയും അഭ്യർത്ഥിച്ച കമാൻഡ് ആരംഭിക്കുകയും ചെയ്യുന്നതാണ്. മുഴുവൻ പ്രക്രിയയും (യഥാർത്ഥ ഉപയോക്താവ് → സാൻഡ്‌ബോക്സ് ഉപയോക്താവ് → നിയന്ത്രിത ടോക്കൺ → ചൈൽഡ് പ്രോസസ്സ്) തനിച്ച് ചെയ്യാൻ codex.exe -നോട് ആവശ്യപ്പെടുന്നതിന് പകരം, ഞങ്ങൾ ആ ഫ്ലോയെ രണ്ടായി വിഭജിച്ചു:

ഭാഗം 1

• codex-command-runner.exe -നെ സാൻഡ്‌ബോക്‌സ് ഉപയോക്താവായി ലോഞ്ച് ചെയ്യുന്നതിനായി codex.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 സാൻഡ്ബോക്സ് പ്രവർത്തിക്കുന്നതു കാണാൻ ആകാംക്ഷയുണ്ടോ? ഇത് പരീക്ഷിക്കുക⁠.