Windows-இல் Codex-ஐ செயல்படுத்த பாதுகாப்பான, பயனுள்ள சாண்ட்பாக்ஸ் உருவாக்குதல்

செப்டம்பர் 2025-இல் நான் Codex பொறியியல் குழுவில் சேர்ந்தபோது, Windows-க்கான Codex-இல் சாண்ட்பாக்ஸ் செயல்படுத்தப்படவில்லை. அதனால் OpenAI-இன் கோடிங் ஏஜென்ட்டுகளைப் பயன்படுத்தும் Windows பயனர்கள் இரண்டு தரமற்ற தேர்வுகளில் ஒன்றைத் தேர்ந்தெடுக்க வேண்டியிருந்தது:

1. கோடிங் ஏஜென்ட் (படித்தல்களுக்குக் கூட) இயக்க விரும்பிய கிட்டத்தட்ட ஒவ்வொரு கட்டளையையும் அங்கீகரிப்பது திறனற்றதும் தொந்தரவானதும் ஆகும். Codex-ஐப் பயன்படுத்துவதன் ஒரு முக்கிய நன்மை என்னவென்றால், சலிப்பூட்டும் எல்லா வேலைகளையும் நீங்களே செய்ய வேண்டியதில்லை.
2. முழுமையான அணுகல் பயன்முறையை இயக்குதல்: Codex எந்த அங்கீகாரமும் கட்டுப்பாடுகளும் இல்லாமல் எல்லா கட்டளைகளையும் இயக்க அனுமதிக்கிறது, இது கண்காணிப்பை இழக்கும் விலைக்கு இடையூறுகளை நீக்குகிறது.

Codex⁠, எங்கள் கோடிங் ஏஜென்ட், டெவலப்பர் மடிக்கணினிகளில் இயங்குகிறது—அது CLI, IDE நீட்டிப்பு அல்லது டெஸ்க்டாப் ஆப் வழியாக இருந்தாலும்கூட. அனுமானத்தைக் கையாள, விசைப்பலகையைப் பயன்படுத்தும் மனிதருக்கும் கிளவுடில் இயங்கும் மாடலுக்கும் இடையிலான உரையாடலை இது நிர்வகிக்கிறது.

Codex இயல்பாக ஒரு உண்மையான பயனரின் அனுமதிகளுடன் இயங்குகிறது. அதாவது, பயனர் செய்யக்கூடிய அனைத்தையும் அது செய்ய முடியும். இது சக்திவாய்ந்ததும், சாத்தியமான அளவில் ஆபத்தானதும் ஆகும். கோடிங் மாடல், ஹார்னஸிடம் அகத்தில் கட்டளைகளை இயக்கச் சொல்லலாம்—சோதனைகள் இயக்குதல், கோப்பை வாசித்தல் அல்லது திருத்துதல், Git branch உருவாக்குதல் வரை அடங்கும். ஆகவே Codex-இன் இயல்புநிலை முறை செயல்திறனுக்கும் பாதுகாப்புக்கும் இடையில் சரியான சமநிலையைத் தேடுகிறது. இந்த இயல்புநிலை முறை Codex-க்கு கிட்டத்தட்ட எங்கிருந்தும் கோப்புகளை வாசிக்கவும், உங்கள் வர்க்ஸ்பேஸிற்குள் (அதாவது, நீங்கள் Codex இயக்கும் அடைவு) கோப்புகளை எழுதவும் அனுமதிக்கிறது; நீங்கள் விரும்புவதாக குறிப்பிட்டாலன்றி இணைய அணுகல் இல்லை. கோப்புகளை எழுதுதலையும் பாதுகாப்பான வரம்புகளுக்குள் நெட்வொர்க் அணுகலையும் தானாகக் கட்டுப்படுத்த, இந்தக் கட்டுப்பாடுகளை உண்மையில் அமல்படுத்தும் ஒரு சாண்ட்பாக்ஸ் சூழல், Codex-க்கு தேவை.

ஒரு சாண்ட்பாக்ஸ் என்பது கட்டுப்படுத்தப்பட்ட செயலாக்கச் சூழல் ஆகும். ஒரு டெவலப்பர் Codex-ஐ பயன்படுத்தும்போது, அவர்களின் கணினியின் இயக்க முறைமை குறைக்கப்பட்ட அனுமதிகளுடன் ஒரு கட்டளையைத் தொடங்குகிறது, மேலும் அந்தக் கட்டுப்பாடுகள் செயல்பாட்டு ட்ரீ முழுவதும் கீழே பரவுகின்றன. ஒவ்வொரு Codex கட்டளையும் தொடக்கத்திலிருந்தே சாண்ட்பாக்ஸ் சூழலுக்குள் தனிமைப்படுத்தப்படுகிறது, மேலும் அதிலிருந்து உருவாகும் ஒவ்வொரு செயல்முறையும் அதே எல்லைக்குள் தங்கிக்கொள்ளும்.

ஒரு பயனுள்ள சாண்ட்பாக்ஸை செயல்படுத்த Codex-க்கு கணினியின் இயக்க முறைமை அமல்படுத்தும் தனிமைப்படுத்தல் அம்சங்கள் தேவை. சில இயக்க முறைமைகள் இதைச் சிறப்பாகச் செய்யும் பயன்பாடுகளை வழங்குகின்றன (எ.கா., MacOs-இல் Seatbelt, Linux-இல் seccomp அல்லது bubblewrap); ஆனால் Windows தற்போது இப்படியான திறனை இயல்பாக வழங்கவில்லை.

Codex-ஐ Windows-இல் மற்ற இடங்களில் இருப்பதைப் போலவே பாதுகாப்பாகவும் பயன்படுத்த இனிமையாகவும் உருவாக்க, நாங்கள் எங்களுடைய சாண்ட்பாக்ஸை நாங்களே செயல்படுத்த வேண்டியிருந்தது.

Windows, தனிமைப்படுத்தலுக்காக சில கருவிகளையும் அடிப்படை கூறுகளையும் வழங்குகிறது. அவற்றில் எதுவும் எங்கள் தேவைகளை முழுமையாக பூர்த்தி செய்யவில்லை என்றாலும், AppContainer, Windows சாண்ட்பாக்ஸ், மற்றும் கட்டாயமான நேர்மைக் கட்டுப்பாடு லேபிளிங் ஆகிய பல சாத்தியமான தீர்வுகளை ஆய்வு செய்தோம்.

AppContainer

• எது: AppContainer என்பது Windows-இன் சொந்த சாண்ட்பாக்ஸ்; முன்கூட்டியே தமக்கு எந்த அணுகல் தேவை என்பதைத் துல்லியமாக அறிந்துள்ள ஆப்களுக்காக உருவாக்கப்பட்ட, திறன்-அடிப்படையிலான தனிமைப்படுத்தல் மாடல்.
• ஏன் வேண்டும்: சிறந்த முயற்சிக் கட்டுப்பாடுகளுக்குப் பதிலாக உண்மையான OS எல்லையை வழங்குவதால் கவர்ச்சியாக உள்ளது.
• ஏன் இல்லை: Codex என்பது ஒரே ஒரு குறுகிய வரம்பில் இறுக்கமாக வரையறுக்கப்பட்ட செயலி அல்ல. இது வரையறையற்ற டெவலப்பர் பணிப்பாய்வுகளை இயக்குகிறது: ஷெல்கள், Git, Python, தொகுப்பு மேலாளர்கள், பில்ட் கருவிகள், மேலும் ஏஜென்ட் தேவையானவை என்று தீர்மானிக்கும் பிற எந்த பைனரிகளும். நடைமுறையில், அதனால் AppContainer அந்தச் சிக்கலுக்குப் பொருத்தமற்றதாகிவிட்டது. அது வலுவான தனிமைப்படுத்தலாக இருந்தது, ஆனால் “ஒரு ஏஜெண்டை டெவலப்பரைப் போல செயல்பட அனுமதிப்பது” என்பதைக் காட்டிலும் மிகவும் குறுகிய வகை பணிச்சுமைகளுக்கே அது பொருந்தியது.

Windows சாண்ட்பாக்ஸ்

• என்ன: Windows Sandbox என்பது Microsoft-இன் பயன்படுத்திவிட்டு அகற்றக்கூடிய இலகுரக VM ஆகும். வலுவான தனிமைப்படுத்தல் எல்லையுடன் புதிய Windows டெஸ்க்டாப் ஒன்றைப் பெறுவீர்கள்; அதற்குள் நீங்கள் என்ன செய்தாலும் அமர்வு முடிந்ததும் மறைந்து விடும்.
• ஏன் வேண்டும்: வெளிப்படையான காரணங்களால் சுவாரஸ்யமாக இருந்தது—AppContainer-ஐ விட தன்னிச்சையான மென்பொருள்களுடன் மிகச் சிறப்பாக இணங்கும்; பாதுகாப்பு பார்வையில் இது மிகவும் வலுவான ஒரு பெட்டி.
• ஏன் வேண்டாம்: Codex, பயனரின் உண்மையான செக்அவுட், கருவிகள், மற்றும் சூழல் மீது நேரடியாக செயல்பட வேண்டியது அவசியம்; அமைவும் ஹோஸ்ட்/கெஸ்ட் பிரிட்ஜிங்கும் தேவைப்படும் தனி தூக்கியெறியப்படக்கூடிய டெஸ்க்டாப்பிற்குள் அல்ல. இதிலும் ஒரு அடிப்படை தயாரிப்பு சிக்கல் இருந்தது: Windows Sandbox, Windows Home SKU-களில் கூட கிடைக்காது.

கட்டாயமான நேர்மைக் கட்டுப்பாடு (MIC) நேர்மை லேபிளிங்

• என்ன: அமைப்பு பொருள்கள் மற்றும் செயல்முறைகளை எந்த அளவு நம்புகிறது என்பதைத் தீர்மானிக்கும் “ஒருமைப்பாட்டு நிலைகள்” எனப்படும் ஒரு கருத்து Windows-இல் உள்ளது; எடுத்துக்காட்டாக, குறைந்த, நடுத்தர மற்றும் உயர்ந்த நிலைகள். அடிப்படை விதி என்னவென்றால், சாதாரண ACL அனுமதித்தாலும் கூட, குறைந்த ஒருமைப்பாட்டு செயல்முறை, அதிக ஒருமைப்பாட்டு நிலை கொண்ட பொருளில் எழுத முடியாது. எடுத்துக்காட்டாக, குறைந்த ஒருமைப்பாட்டு செயல்முறை குறைவாக நம்பகமானதாகக் கருதப்படுகிறது. எனவே, அந்த பொருட்கள் அதற்கு அனுமதி வழங்கும் வகையில் வெளிப்படையாக மறுபெயரிடப்பட்டிருந்தால் மட்டுமே, Windows அதை வழக்கமான நடுத்தர ஒருமைப்பாட்டு பொருட்களுக்குள் எழுதுவதைத் தடுக்கிறது.
• ஏன்: MIC காகிதத்தில் அழகாகத் தோன்றியது—Codex-ஐ குறைந்த Integrity-இல் இயக்கி, எழுதக்கூடிய ரூட்களை குறைந்த Integrity-ஆக மீண்டும் லேபிள் செய்து, மற்ற எல்லா இடங்களிலும் எழுதாமையை Windows அமல்படுத்தட்டும். அது, உண்மையான OS இயங்குமுறையின் ஆதரவு கொண்ட ஒரு நிர்வாகி-அல்லாத வழியை நமக்குத் தந்திருக்கும்.
• ஏன் வேண்டாம்: ACLs போலவே, ஒருமைப்பாட்டு லேபிள்கள் உண்மையான ஹோஸ்ட் கோப்பு முறைமையை மாற்றுகின்றன, மேலும் இந்தச் சூழலில் அர்த்தவியல் மாற்றம் குறிப்பாகப் பரந்ததாக உள்ளது. ஒரு வர்க்ஸ்பேஸை குறைந்த ஒருமைப்பாடு கொண்டதாகக் குறியிடுவது “Codex இங்கே எழுத முடியும்.” என்பதையே மட்டும் குறிக்காது. இதன் அர்த்தம், குறைந்த ஒருமைப்பாட்டு செயல்முறைகள் பொதுவாக அங்கே எழுத முடியும். ஒரு உண்மையான டெவலப்பர் கணினியில், அது பயனரின் நிஜமான செக்-அவுட்டை ஹோஸ்டுக்கான low-integrity sink ஆக மாற்றுகிறது; இது ஒரு sandbox வடிவமைப்பிற்கு கவனமாக இலக்கு வைக்கப்பட்ட ACLகளை வழங்குவதைக் காட்டிலும் மிகவும் ஆபத்தானது. நடுத்தர-இன்டெக்ரிட்டி டெவலப்பர் கருவிகள் தொடர்ந்து வேலை செய்தாலும், வர்க்ஸ்பேஸின் அடிப்படை நம்பிக்கை மாடல் கட்டுப்படுத்துவது கடினமாகவும் நியாயப்படுத்துவது இன்னும் கடினமாகவும் இருக்கும் வகையில் மாறியுள்ளது.

இந்த எல்லா விருப்பங்களும் தொடங்கவே முடியாதவை என்று மதிப்பிட்ட பிறகு, Windows பயனர்களுக்கு நல்ல Codex அனுபவத்தை வழங்க எங்களுடைய சொந்த தீர்வை வடிவமைக்கத் தொடங்கினோம்.

எங்களின் முதல் செயல்படும் முன்மாதிரி, எங்களுக்கு தேவைப்பட்ட தனிமைப்படுத்தலை செயல்படுத்த Windows கருத்துகள் மற்றும் கருவிகளின் கலவையைப் பயன்படுத்தியது. தொடக்கத்திலிருந்தே, ஒரு குறிக்கோள் இதை elevation தேவையில்லாமல் செயல்படச் செய்வதாக இருந்தது; அதாவது, sandbox-ஐ அமைக்க அல்லது இயக்க மட்டுமே பயனரிடம் நிர்வாகி சலுகைகளைக் கோரி Codex ப்ராம்ப்ட் செய்ய வேண்டியிருக்காது. அதாவது, இரண்டு விஷயங்களுக்கு நியாயமான வரம்புகளை எப்படிப் போடுவது என்பதைக் கண்டறிய வேண்டியது: கோப்பு எழுதுதல் செயல்பாடுகள் மற்றும் நெட்வொர்க் அணுகல்.

கோப்பு எழுதுதல்களை எவ்விதத்திலும் கட்டுப்படுத்தாவிட்டால், பாதுகாப்பு சிக்கல் உருவாகும். மிக அதிகமாக கட்டுப்படுத்தினால், சாண்ட்பாக்ஸ் பயனர், உற்பத்தித்திறனை பாதித்து, தொடர்ச்சியான அங்கீகாரம் கேட்கும். இந்தப் பிரச்சினையைத் தீர்க்க, Windows-இன் இரண்டு முக்கிய பில்டிங் பிளாக்குகளை நாங்கள் சார்ந்துள்ளோம்: SIDகள் மற்றும் எழுதுதல் கட்டுப்படுத்தப்பட்ட டோக்கன்கள்.

SID, அல்லது பாதுகாப்பு அடையாளங்காட்டி, என்பது அனுமதிகளுடன் Windows இணைக்கும் அடையாளமாகும். ஒவ்வொரு பயனருக்கும் ஒரு SID உள்ளது, குழுக்களுக்கு SID-கள் உள்ளன, மேலும் ஒற்றை உள்நுழைவு அமர்வுக்குக் கூட தனக்கென ஒரு SID கிடைக்கும். எடுத்துக்காட்டாக, தற்போது உள்நுழைந்துள்ள அமர்வுக்கு S-1-5-5-X-Y போன்ற SID இருக்கலாம். உள்ளூர் நிர்வாகிகள் குழுவுக்கு ஒதுக்கப்பட்ட SID S-1-5-32-544 ஆக இருக்கலாம்.

உண்மையான பயனருடன் பொருந்தாததாக இருந்தாலும் ACLகளில் (அணுகல் கட்டுப்பாட்டுப் பட்டியல்கள்) தோன்றக்கூடிய செயற்கை SIDகளை உருவாக்கவும் Windows அனுமதிக்கிறது; இவையே குறிப்பிட்ட கோப்புகள் அல்லது அடைவுகளை யார் படிக்கலாம்/எழுதலாம்/இயக்கலாம் என்பதை வரையறுக்கின்றன. இதனால் SIDகள் எங்கள் சாண்ட்பாக்ஸுக்கு பயனுள்ள அடிப்படைக் கூறாகின்றன: இயந்திரத்தில் வேறு எதையும் பாதிக்காமல், Codex சாண்ட்பாக்ஸ் மட்டும் பயன்படுத்தும் SIDகளை உருவாக்க முடியும்.

செயல்முறை டோக்கன் என்பது Windows-இல் இயங்கிக் கொண்டிருக்கும் ஒரு செயல்முறையின் அடையாளத்தையும் சிறப்புரிமைகளையும் வரையறுக்கும் பாதுகாப்பு ஆப்ஜெக்ட்கள் ஆகும். ஒரு செயல்முறை எந்தச் செயல்களைச் செய்ய முடியும் என்பதை அவை தீர்மானிக்கின்றன. ஒரு எழுதக் கட்டுப்படுத்தப்பட்ட டோக்கன் என்பது, எழுதுதல் செயல்பாடுகளில் Windows கூடுதல் அணுகல் சரிபார்ப்பைச் செய்ய வைக்கும் ஒரு குறிப்பிட்ட வகை செயல்முறை டோக்கன் ஆகும்.

ஒரு எழுதுதல் வெற்றியடைய, இரண்டு சரிபார்ப்புகள் கடக்க வேண்டும்:

1. சாதாரண பயனர் அடையாளம் (டோக்கன் “உரிமையாளர்”) அதனைச் செய்ய அனுமதிக்கப்பட்டிருக்க வேண்டும்
2. மேலும் டோக்கனின் restricted 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 ஒரு விருப்பமாக இல்லாததால், எங்களால் கட்டுப்படுத்தக்கூடியவற்றில் வரம்புகள் ஏற்பட்டன. டெவலப்பர்கள் உண்மையில் பயன்படுத்தும் வகையான நெட்வொர்க் சார்ந்த கருவிகளுக்காக, சைல்ட் சூழல் இயல்பாகத் தடுக்கப்படும் வகையில் அமைக்க முயன்றோம்; இதனால் Git கட்டளைகள், பேக்கேஜ் நிறுவிகள் போன்றவை சாண்ட்பாக்ஸில் தோல்வியடையும், மேலும் இணையத்தை அணுகும் எந்தச் செயல்பாடுகளுக்கும் பயனர் ஒப்புதல் அளிக்க வேண்டியிருக்கும். தெளிவாகத் தெரியும் தப்பிக்கும் வழிகளை செயலிழக்கச் செய்வதே யோசனை: ப்ராக்ஸி-அறிந்த டிராஃபிக்கை செயலற்ற எண்ட்பாயிண்டுக்கு அனுப்புவது, Git-இன் HTTP(S) டிரான்ஸ்போர்ட்டையும் அதையே செய்யச் செய்வது, மேலும் SSH வழியாக Git உடனடியாக தோல்வியடையச் செய்வது. அதற்கு மேலாக, denybin என்ற சிறிய கோப்பகத்தை PATH-இன் தொடக்கத்தில் சேர்த்தோம்; மேலும் ஸ்டப் 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-ஐ மீறலாம், அல்லது நேரடியாக சாக்கெட்களைத் திறக்கலாம்—அது மிக ஆபத்தானது.

எந்த சுவாரஸ்யமான மென்பொருள் செயலாக்கத்திலும் இருப்பதுபோல, முதல் முன்மாதிரிக்கும் சில நன்மைகளும் குறைகளும் இருந்தன. இது சில நிலையான Windows திறன்களை மட்டுமே பயன்படுத்தி வேலையைச் செய்தாலும், மிகவும் தெளிவான மற்றும் நுணுக்கமான ஃபைல்சிஸ்டம் எழுதுதல்களை அனுமதித்தாலும், மேலும் உயர்த்தப்படாத முறையில் இயங்கினாலும்—அதனால் பயனர்கள் அதிகப்படியான உயர்த்தல் ப்ராம்ப்ட்களை ஏற்கவோ தங்கள் உள்ளூர் கணினியில் நிர்வாகிகளாக இருக்கவோ வேண்டிய அவசியம் குறைந்தது—இதற்கு சில உண்மையான குறைபாடுகள் இருந்தன; அவற்றில் சில, இது எங்கள் இறுதி வடிவமைப்பாக மாறுவதற்குத் தகுதியற்றதாக ஆக்கின:

• அமைப்பின் வேகம்: வர்க்ஸ்பேஸ் அடைவின் டோப்பாலஜியைப் பொறுத்து வர்க்ஸ்பேஸ் ACLகளைப் பயன்படுத்துவது விலையுயர்ந்ததாக இருக்கலாம்.
• தடம்: நாங்கள் டெவலப்பரின் சிஸ்டத்தில் உண்மையான ACLகளைப் பயன்படுத்தினோம்; இருப்பினும் அந்த தடம் அதிகமாக ஊடுருவும் தன்மை கொண்டதல்ல, ஏனெனில் பயன்படுத்தப்பட்ட ACLகள் அனைத்தும் சாண்ட்பாக்ஸ் மட்டும் பயன்படுத்தும் தனிப்பயன் உருவாக்கப்பட்ட செயற்கை SIDக்கு தொடர்புடையவை.
• மாற்றுவதற்கு கடினமான செமாண்டிக்ஸ்: கோப்பு அடிப்படையிலான கட்டுப்பாடுகளுக்காக ACLகளைச் சார்ந்திருப்பதால், சாண்ட்பாக்ஸ் செமாண்டிக்ஸை மாற்றுவது செலவானதும் சிக்கலானதும் ஆகிறது. ஆனால் macOS இல், .sbpl -ஐ உருவாக்கும் முறையை நாம் இயங்குநேரத்தில் மாற்றலாம் Seatbelt-ஐ உள்ளமைக்கப் பயன்படுத்தப்படும் கோப்பு காரணமாக, ACLகளைச் சரிசெய்ய Windows sandbox-க்கு மெதுவான மற்றும் அதிக வளம் தேவைப்படும் செயல்பாடு தேவைப்படக்கூடும்.
• நெட்வொர்க் பாதுகாப்பு பலவீனமாக உள்ளது. முன்பு குறிப்பிட்டதுபோல், அது “ஆலோசனை” மட்டுமே; தங்களுடைய சொந்த நெட்வொர்க் ஸ்டாக்கைச் செயல்படுத்தும் சில நிரல்கள் அதை நிச்சயமாக மீறிவிடும், மேலும் எதிர்மறை குறியீட்டைக் கையாளத் தகுந்ததாக அது வடிவமைக்கப்படவில்லை.

முதல் மூன்று சிக்கல்களும் ஏஜென்டிக் ஓட்டங்களுக்கு போதுமான நெகிழ்வுடைய தனிப்பயன் சாண்ட்பாக்ஸ் செயல்படுத்தலுக்கே உட்பட்டவை. ஆனால் நெட்வொர்க் ஒடுக்கத்தின் கதை வேறுபட்டது.

தீங்கிழைக்கும் ஏஜென்ட் சூழல்-அடிப்படையிலான நெட்வொர்க் ஒடுக்கத்தை எளிதாக மீறக்கூடியதோடு, நல்ல நோக்கமுள்ள ஏராளமான கோடிங்/பைனரிகளும் சூழல் பிராக்ஸி மாறிகளை மதிக்காவிட்டாலோ, தங்களுடைய சாக்கெட்-அடிப்படையிலான நெட்வொர்க் கோடிங்கை செயல்படுத்தினாலோ அதை மீறிவிடும். இந்த அம்சம் மட்டுமே மேம்பட்ட சாண்ட்பாக்ஸ் முறையில் முதலீடு செய்வதைப் பரிசீலிக்கப் போதுமானது என்று நாங்கள் உணர்ந்தோம்.

மேம்பட்ட நெட்வொர்க் ஒடுக்கத்தைப் பெற Windows Firewall-ஐப் பயன்படுத்த விரும்பினோம்; இது பயனர்கள் அல்லது நிரல்களுக்கு வெளிப்புற நெட்வொர்க் போக்குவரத்தைத் தடுக்க அனுமதிக்கிறது. துரதிருஷ்டவசமாக, Codex ஹார்னஸ் தொடங்கும் கட்டளைகளுக்கு மட்டும் பொருந்தும் செயல்படும் ஃபயர்வால் விதியை சில காரணங்களால் எங்களால் பயனுள்ள முறையில் உருவாக்க முடியவில்லை:

• கட்டுப்படுத்தப்பட்ட டோக்கனின் முதன்மை அல்லாத அடையாளத்துடன் ஃபயர்வால் விதியைப் பொருத்த Windows அனுமதிக்காது. அதாவது “எங்கள் செயற்கை SID, அதன் தடுக்கப்பட்ட SID பட்டியலில் உள்ள எந்த டோக்கனுக்கும்” ஃபயர்வால் விதியைப் பொருத்த முடியவில்லை.
• குறிப்பிட்ட பைனரிக்கு பொருந்தும் ஃபயர்வால் விதி ஒன்றை உருவாக்கலாம் என்றாலும், அது codex.exe தனக்கே நெட்வொர்க் வரம்பைச் செயற்படுத்த உதவும். பயனரின் சார்பாக ஏஜெண்ட் தொடங்கும் Git அல்லது Python செயல்முறைகள் போன்ற செயல்முறைகளுக்கு இது பொருந்தாது.
• மற்ற ஃபயர்வால் பொருத்தப் பரிமாணங்களும் தவறான வடிவத்தில் இருந்தன. பயனர்-வரம்புள்ள விதிகள், உயர்த்தப்படாத வடிவமைப்பில் கட்டுப்படுத்தப்பட்ட துணைச் செயல்முறையுடன் மட்டுமல்லாமல், உண்மையான Windows பயனருடனும் இன்னும் பொருந்தின. நிரல்-பாதை விதிகள் மிகவும் பரந்தவையாக இருந்தன: அவை பொதுவாக codex.exe அல்லது python.exe ஆகியவற்றைத் தடுக்க முடிந்தாலும், சாண்ட்பாக்ஸ் செய்யப்பட்ட python.exe-இன் இந்த ஒரு குறிப்பிட்ட இயக்க அழைப்பைத் தடுக்க முடியவில்லை. போர்ட் அல்லது முகவரி அடிப்படையிலான விதிகளும் முற்றிலும் தவறான கொள்கையாக இருந்தன. உதாரணமாக, நாங்கள் போர்ட் 443-ஐத் தடுக்க விரும்பவில்லை; இந்தக் குறிப்பிட்ட கட்டுப்படுத்தப்பட்ட செயல்முறை மரத்திற்கான தன்னிச்சையான வெளிச்செல்லும் அணுகலைத் தடுக்கவே விரும்பினோம்.

எங்கள் சாண்ட்பாக்ஸ் செய்த கட்டளைகளுக்கு குறிப்பாக ஃபயர்வால் விதி பொருத்த, அவற்றை “உண்மையான” பயனராக அல்லாமல் தனி principal-ஆக இயக்க வேண்டியது ஏற்பட்டது. இந்த அணுகுமுறை எங்களை ஒரு புதிய பாதைக்கு அழைத்துச் சென்றது; அதில் “உயர்த்தப்படுதல் இல்லை” என்ற எங்கள் கட்டுப்பாட்டை நாம் தளர்த்தினோம்.

எங்கள் தற்போதைய செயலாக்கமான சாண்ட்பாக்ஸின் அடுத்த பதிப்பிற்கு, அமைக்கும் நேரத்தில் உயர்ந்த நிர்வாகி அனுமதிகள் தேவைப்படுகின்றன. எனவே, நான் அதை “உயர்த்தப்பட்ட சாண்ட்பாக்ஸ்” என்று குறிப்பிடுகிறேன். அமைப்பில் Codex ஒரு கட்டளையைத் தொடக்கும் எல்லையில், உயர்த்தப்பட்ட சாண்ட்பாக்ஸ் உயர்த்தப்படாத சாண்ட்பாக்ஸ் போலவே தோன்றுகிறது. இது இன்னும் துணைச் செயல்முறைகளை ஒரு கட்டுப்படுத்தப்பட்ட டோக்கனின் கீழ் இயக்குகிறது—அதேபோல் [Everyone, Logon, Synthetic]என்ற அதே கட்டுப்படுத்தப்பட்ட SID பட்டியலுடன் கூடியwrite_restrictedடோக்கன்—ஆனால், இந்த டோக்கனின் முதன்மை அடையாளம் இனி உண்மையான Windows பயனர் அல்ல; மாறாக Codex தானே உருவாக்கிய இரண்டு உள்ளூர் பயனர்களில் ஒருவர்:

• CodexSandboxOffline (ஃபயர்வால் விதிகள் குறிவைக்கும் ஒன்று)
• CodexSandboxOnline (ஃபயர்வால் விதிகள் குறிவைக்காத ஒன்று)

சிறிய விவரம் போலத் தோன்றும் இந்த விஷயத்திற்கே, சாண்ட்பாக்ஸ், அதை யார் பயன்படுத்தலாம், அதன் அமைவு மற்றும் இயக்கநேரச் செயல்படுத்தல் சிக்கல்தன்மை ஆகியவற்றில் பெரிய விளைவுகள் உள்ளன.

பார்வைக்கு இது உயர்த்தப்படாத முன்மாதிரியைப் போன்றே உள்ளது; ஆனால் ஃபயர்வால் விதிகளும், கட்டளைகளை உண்மையில் இயக்கும் பிரத்யேகமான Windows பயனரும் சேர்க்கப்பட்டுள்ளனர். (எனினும், இந்தப் புதிய கருத்துகள் சேர்க்கப்பட்டதால், சாண்ட்பாக்ஸ் கட்டளைகளை இயக்கி பாதுகாக்கத் தொடங்குவதற்கு முன் மேலும் அமைவு வேலை செய்ய வேண்டியுள்ளது.)

உயர்த்தப்படாத சாண்ட்பாக்ஸ் வடிவமைப்பில் ஒரு எளிய அமைவு படி இருந்தது; ஆனால் அது ஒப்பீட்டளவில் சிறியது:

• தேவையெனில் செயற்கை SID ஒன்றை உருவாக்குதல்
• சாண்ட்பாக்ஸ்-எழுதுதல் செயற்கை SID-க்கான ACLகளைப் பயன்படுத்துதல்

ஆனால் உயர்த்தப்பட்ட சாண்ட்பாக்ஸ் இன்னும் அதிகம் செய்ய வேண்டும்.

• ஏற்கனவே உருவாக்கப்படவில்லை என்றால் செயற்கை SID உருவாக்குதல்
• ஏற்கனவே உருவாக்கப்படவில்லை என்றால் ஆன்லைன் மற்றும் ஆஃப்லைன் சாண்ட்பாக்ஸ் பயனர்களை உருவாக்குதல்
• புதிதாக உருவாக்கப்பட்ட பயனர்களின் நற்சான்றுகளை அகத்தில் சேமித்து, சாண்ட்பாக்ஸ் பயனர்கள் உண்மையில் படிக்க முடியாத இடத்தில் Windows தரவுப் பாதுகாப்பு API (DPAPI) பயன்படுத்தி என்கிரிப்ட் செய்தல்
• CodexSandboxOffline பயனருக்கான அனைத்து வெளிச்செல்லும் நெட்வொர்க் அணுகலையும் தடுக்கும் ஃபயர்வால் விதிகளை உருவாக்கவும் அல்லது அவை ஏற்கனவே இருந்தால் அவை சரியானவை என்பதைச் சரிபார்க்கவும்

அமைவு கட்டத்தில் கூடுதலாக ஒரு சிக்கல் உள்ளது. Codex-இன் சாண்ட்பாக்ஸுக்கு உண்மையான Windows பயனருக்கு இணையான வாசிப்பு அணுகல் இருக்கும் என எதிர்பார்க்கப்படுகிறது. உயர்த்தப்படாத சாண்ட்பாக்ஸில், கட்டுப்படுத்தப்பட்ட டோக்கனின் முதன்மை SID Windows பயனராக இருந்த இடத்தில், இது அடையப்பட்டது. இருப்பினும், பிரின்சிபல் புதிய CodexSandbox பயனராக மாறும்போது, அது இலவசமாகக் கிடைப்பதில்லை. Windows-இல் தொடர்புடைய பல கோப்பகங்கள் “அங்கீகரிக்கப்பட்ட பயனர்கள்” என்பவர்களுக்கு படிக்க/இயக்க அனுமதிகளை வழங்கும். குறிப்பிடத்தக்க ஒரு எடுத்துக்காட்டு பயனரின் சுயவிவரக் கோப்பகமாகும். இயல்பாக, 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 ஒரு சாதாரண, உயர்த்தப்படாத ஹார்னஸாகத் தொடர முடிந்தது; Windows-க்கு மட்டுமான அமைவுப் பொறிமுறை மற்ற தளங்களில் codex.exe-ஐ பெரிதாக்கவில்லை; நீண்ட அமைவுப் பணிகளை முதன்மை செயல்பாட்டின் ஆயுளிலிருந்து பிரிக்க முடிந்தது; மேலும் சாண்ட்பாக்ஸுக்கு தேவையான பல்வேறு அமைவு பாதைகளைக் கையாள ஒரு மையம் கிடைத்தது.

Windows பயனர் மற்றும் டோக்கன் உள்நுழைவு எல்லைகள் செயல்படும் விதத்தால், உயர்த்தப்படாத சாண்ட்பாக்ஸில் செய்தது போல தடுக்கப்பட்ட டோக்கனை உருவாக்கி அதின் கீழ் செயல்பாட்டைத் தொடங்குவதைத் தொடர முடியவில்லை. வேறு Windows பயனராகக கட்டளைகளை உண்மையில் தொடங்க, எங்கள் முதல் யோசனை பின்வரும் பாய்வாக இருந்தது:

• codex.exe உண்மையான Windows பயனராக இயங்குகிறது. பின்னர், வரிசையாக, Codex:
  • சாண்ட்பாக்ஸ் பயனருக்காக LogonUserW(...)-ஐ அழைக்கிறது.
  • அந்த சாண்ட்பாக்ஸ்-பயனர் டோக்கனில் CreateRestrictedToken(...) -ஐ அழைக்கிறது.
  • கட்டுப்படுத்தப்பட்ட அந்த sandbox-user டோக்கனைப் பயன்படுத்தி, இறுதி child செயல்முறையைத் தொடங்க 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 சாண்ட்பாக்ஸை செயல்பாட்டில் காண ஆர்வமா? முயற்சி செய்து பாருங்கள்⁠.