Windows లో Codex ను ప్రారంభించడానికి సురక్షితమైన, ప్రభావవంతమైన sandbox నిర్మాణం

నేను 2025 సెప్టెంబరులో Codex ఇంజినీరింగ్ బృందంలో చేరినప్పుడు, Windows కోసం Codex లో sandbox అమలు లేదు. అంటే OpenAI యొక్క కోడింగ్ ఏజెంట్‌లను ఉపయోగించే సమయంలో Windows వినియోగదారులు రెండు నాసిరకమైన ఎంపికల మధ్య ఎంచుకోవాల్సి వచ్చేది:

1. ఒక కోడింగ్ ఏజెంట్ నడపాలనుకునే దాదాపు ప్రతి కమాండ్‌కి (రీడ్స్‌కూ కూడా) ఆమోదం ఇవ్వాల్సి రావడం, ఇది సమర్థవంతం కాదు మరియు ఇబ్బందికరంగా ఉంటుంది. Codex ఉపయోగించడం వల్ల కలిగే ఒక ప్రధాన ప్రయోజనం ఏమిటంటే, విసుగు తెప్పించే పనంతా మీరే చేయాల్సిన అవసరం ఉండదు.
2. ఫుల్ యాక్సెస్ మోడ్‌ను ప్రారంభించడం: ఎటువంటి ఆమోదాలు లేదా పరిమితులు లేకుండా Codex అన్ని కమాండ్‌లను నడపడానికి అనుమతించడం. ఇది పర్యవేక్షణ తగ్గినా ఘర్షణను తగ్గిస్తుంది.

Codex⁠, మా కోడింగ్ ఏజెంట్, డెవలపర్ ల్యాప్‌టాప్‌లపై నడుస్తుంది—అది CLI, IDE ఎక్స్‌టెన్షన్ లేదా డెస్క్‌టాప్ యాప్ ద్వారా అయినా సరే. ఇది ఇన్ఫరెన్స్‌ను నిర్వహించడానికి, కీబోర్డ్ వద్ద ఉన్న వ్యక్తి మరియు క్లౌడ్‌లో నడుస్తున్న మోడల్ మధ్య సంభాషణను నిర్వహిస్తుంది.

డిఫాల్ట్‌గా Codex నిజమైన వినియోగదారుని అనుమతులతో నడుస్తుంది. అంటే వినియోగదారు చేయగలిగిన ప్రతిదీ ఇది కూడా చేయగలదు. ఇది శక్తివంతమైనదే కానీ ప్రమాదకరమయ్యే అవకాశం ఉంది. కోడింగ్ మోడల్ హార్నెస్కు స్థానికంగా కమాండ్‌లను నడపమని చెప్పవచ్చు—టెస్టులు నడపడం నుంచి ఫైల్ చదవడం లేదా సవరించడం వరకు, Git branch సృష్టించడం వరకు. అందుకే Codex యొక్క డిఫాల్ట్ మోడ్ ప్రభావవంతత మరియు భద్రత మధ్య సరైన సమతుల్యతను కనుగొనడానికి ప్రయత్నిస్తుంది. ఈ డిఫాల్ట్ మోడ్ వల్ల Codex దాదాపు ఎక్కడైనా ఫైళ్లను చదవగలదు మరియు మీ వర్క్‌స్పేస్‌లో (అంటే మీరు Codex నడుపుతున్న డైరెక్టరీలో) ఫైళ్లను వ్రాయగలదు. మీరు ప్రత్యేకంగా అనుమతించకపోతే ఇంటర్నెట్ యాక్సెస్ ఉండదు. ఫైల్ రాతలను మరియు నెట్‌వర్క్ యాక్సెస్‌ను సురక్షిత పరిమితులలో ఆటోమేటిక్‌గా నియంత్రించేందుకు, ఈ పరిమితులను నిజంగా అమలు చేసే sandbox వాతావరణం Codex కు అవసరం.

sandbox అనేది నియంత్రిత అమలు వాతావరణం. ఒక డెవలపర్ Codex‌ను ఉపయోగించినప్పుడు, వారి కంప్యూటర్ ఆపరేటింగ్ సిస్టమ్ తగ్గించిన అనుమతులతో ఒక కమాండ్‌ను ప్రారంభిస్తుంది, మరియు ఆ పరిమితులు మొత్తం ప్రాసెస్ ట్రీ అంతటా వ్యాపిస్తాయి. ప్రతి Codex కమాండ్ ప్రారంభం నుంచే sandbox‌లో వేరుచేయబడుతుంది, మరియు దాని నుండి ఉత్పన్నమయ్యే ప్రతి డిసెండెంట్ ప్రాసెస్ అదే పరిమితి లోపలే ఉంటుంది.

ప్రభావవంతమైన sandbox ను అమలు చేయడానికి Codex కు కంప్యూటర్ యొక్క ఆపరేటింగ్ సిస్టమ్ అమలు చేసే ఐసోలేషన్ లక్షణాలు అవసరం. కొన్ని ఆపరేటింగ్ సిస్టమ్‌లు దీన్ని బాగా చేసే యుటిలిటీలను అందిస్తాయి (ఉదా., MacOs లో Seatbelt, Linux లో seccomp లేదా bubblewrap); అయితే Windows ప్రస్తుతం ఈ రకమైన సామర్థ్యాన్ని సిద్ధంగా అందించదు.

Windows లో కూడా Codex ను ఇప్పటికే ఇతరత్రా ఉన్నంత సురక్షితంగా, సులభంగా ఉపయోగించదగినదిగా చేయడానికి, మేమే మా 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 SKUలలో అసలు అందుబాటులోనే లేదు.

Mandatory Integrity Control (MIC) ఇంటెగ్రిటీ లేబెలింగ్

• ఏమిటి: సిస్టమ్ ఆబ్జెక్టులు మరియు ప్రాసెస్‌లను ఎంతవరకు విశ్వసిస్తుందో నిర్ణయించే తక్కువ, మధ్యస్థ మరియు అధిక వంటి “సమగ్రత స్థాయిలు” అనే భావన Windows‌లో ఉంది. ప్రాథమిక నియమం ఏమిటంటే, సాధారణ ACL అనుమతించినప్పటికీ, తక్కువ సమగ్రత స్థాయి కలిగిన ప్రాసెస్ అధిక సమగ్రత స్థాయి కలిగిన ఆబ్జెక్ట్‌కు వ్రాయలదు. ఉదాహరణకు, తక్కువ సమగ్రత స్థాయి గల ప్రాసెస్‌ను తక్కువగా విశ్వసనీయమైనదిగా పరిగణిస్తారు, కాబట్టి ఆ ఆబ్జెక్ట్‌లు దానికి అనుమతించేలా స్పష్టంగా మళ్లీ లేబుల్ చేయబడితే తప్ప, Windows దాన్ని సాధారణ మధ్యస్థ సమగ్రత స్థాయి గల ఆబ్జెక్ట్‌లకు వ్రాయడం నుండి నిరోధిస్తుంది.
• ఎందుకు: MIC కాగితంపై ఎంతో సొగసుగా కనిపించింది—Codex‌ను లో-ఇంటెగ్రిటీ‌లో నడపడం, writable roots‌ను లో-ఇంటెగ్రిటీ‌గా రీలేబుల్ చేయడం, మరియు మిగతా అన్ని చోట్ల నో-రైట్స్‌ను Windows అమలు చేయనివ్వడం. అది మాకు నిజమైన OS మెకానిజం ఆధారంగా పనిచేసే నాన్-అడ్మిన్ మార్గాన్ని అందించేది.
• ఎందుకు కాదు: ACLల మాదిరిగానే, సమగ్రత లేబుళ్లు నిజమైన హోస్ట్ ఫైల్‌సిస్టమ్‌ను సవరించుతాయి, మరియు ఈ సందర్భంలో అర్థపరమైన మార్పు ముఖ్యంగా విస్తృతంగా ఉంటుంది. వర్క్‌స్పేస్‌ను తక్కువ సమగ్రతగా గుర్తించడం అంటే కేవలం “Codex ఇక్కడ రాయగలదు” అని మాత్రమే కాదు. దీని అర్థం, తక్కువ సమగ్రత ప్రాసెస్‌లు సాధారణంగా అక్కడ వ్రాయగలవు. నిజమైన డెవలపర్ మెషీన్‌లో, ఇది వినియోగదారి యొక్క అసలు checkout‌ను హోస్ట్‌కు low-integrity sink‌గా మారుస్తుంది. ఇది ఒక sandbox డిజైన్‌కు జాగ్రత్తగా లక్ష్యంగా పెట్టిన ACLs‌ను ఇవ్వడంకంటే చాలా ఎక్కువ ప్రమాదకరం. మీడియం-ఇంటెగ్రిటీ డెవలపర్ టూల్స్ పని చేయడం కొనసాగించినప్పటికీ, వర్క్‌స్పేస్‌కు సంబంధించిన అంతర్లీన ట్రస్ట్ మోడల్ అదుపులో ఉంచడం కష్టంగా, సమర్థించడం మరింత కష్టంగా ఉండే విధంగా మారింది.

ఈ అన్ని ఎంపికలను అనుపయోగకరమైనవిగా అంచనా వేసిన తర్వాత, Windows వినియోగదారులకు మంచి Codex అనుభవాన్ని అందించేందుకు మా స్వంత పరిష్కారాన్ని రూపొందించడం ప్రారంభించాం.

మాకు అవసరమైన ఐసోలేషన్‌ను అమలు చేయడానికి మా మొదటి పని చేసే ప్రోటోటైప్ Windows భావనలు మరియు సాధనాల కలయికను ఉపయోగించింది. ప్రారంభం నుంచే, ఎలివేషన్ అవసరం లేకుండా ఇది పని చేసేలా చేయడం ఒక లక్ష్యంగా పెట్టుకున్నారు, అంటే సాండ్‌బాక్స్‌ను సెటప్ చేయడానికి లేదా అమలు చేయడానికి మాత్రమే Codex వినియోగదారుని అడ్మినిస్ట్రేటర్ అధికారాల కోసం ప్రాంప్ట్ చేయాల్సిన అవసరం ఉండదు. దాని అర్థం రెండు విషయాలపై సముచిత పరిమితులను ఎలా పెట్టాలో గుర్తించడం: ఫైల్ రైట్‌లు మరియు నెట్‌వర్క్ యాక్సెస్.

మనం ఫైల్ రైట్స్‌ను అసలు పరిమితం చేయకపోతే భద్రతా సమస్య వచ్చేది. చాలా ఎక్కువగా పరిమితం చేస్తే, sandbox వినియోగదారుల ఉత్పాదకతను దెబ్బతీసి, నిరంతరం ఆమోదాలు కోరేది. ఈ సమస్యను పరిష్కరించడానికి, మేము Windows‌లోని రెండు ముఖ్యమైన బిల్డింగ్ బ్లాక్స్‌పై ఆధారపడ్డాం: SIDs మరియు రైట్-రిస్ట్రిక్టెడ్ టోకెన్లు.

SID, లేదా భద్రతా గుర్తింపుదారు, అనేది Windows అనుమతులతో అనుసంధానించే గుర్తింపు. ప్రతి వినియోగదారుకు ఒక SID ఉంటుంది, గ్రూప్‌లకు SIDలు ఉంటాయి, అలాగే ఒక్క లాగిన్ సెషన్‌కైనా దాని స్వంత SID లభిస్తుంది. ఉదాహరణకు, ప్రస్తుతం లాగిన్ అయి ఉన్న సెషన్‌కు S-1-5-5-X-Y వంటి SID ఉండవచ్చు. స్థానిక నిర్వాహకుల సమూహానికి కేటాయించిన SID S-1-5-32-544 అయి ఉండవచ్చు.

నిజమైన వినియోగదారునికి సరిపోని synthetic SIDs ను కూడా Windows సృష్టించనిస్తుంది, కానీ అవి ACLs (యాక్సెస్ కంట్రోల్ లిస్ట్స్) లో కనిపించగలవు. ఇవే నిర్దిష్ట ఫైళ్లు లేదా డైరెక్టరీలను ఎవరు చదవగలరు/వ్రాయగలరు/నిర్వహించగలరు అనేది నిర్వచిస్తాయి. దీని వల్ల SIDs మా sandbox కు ఉపయోగకరమైన ప్రిమిటివ్ అయ్యాయి: యంత్రంలోని ఇతర ఏదిపైనా ప్రభావం లేకుండా, ప్రత్యేకంగా Codex sandbox ఉపయోగం కోసం SIDs సృష్టించవచ్చు.

ప్రాసెస్ టోకెన్‌లు అనేవి Windowsలోని భద్రతా ఆబ్జెక్టులు, ఇవి నడుస్తున్న ప్రాసెస్‌కు సంబంధించిన గుర్తింపు మరియు అధికారాలను నిర్వచిస్తాయి. ఒక ప్రాసెస్ ఏ చర్యలను నిర్వహించగలదో అవి నిర్ణయిస్తాయి. వ్రాయడం-పరిమితం చేయబడిన టోకెన్ అనేది ఒక నిర్దిష్ట రకమైన ప్రాసెస్ టోకెన్; ఇది వ్రాత ఆపరేషన్‌లపై అదనపు యాక్సెస్ తనిఖీని Windows నిర్వహించేలా చేస్తుంది.

ఒక write విజయవంతం కావాలంటే, రెండు తనిఖీలు ఉత్తీర్ణం కావాలి:

1. సాధారణ వినియోగదారు గుర్తింపుకు (టోకెన్ “owner”) దాన్ని చేయడానికి అనుమతి ఉండాలి
2. టోకెన్ యొక్క రిస్ట్రిక్టెడ్ SID జాబితాలో కనీసం ఒక SID‌కు కూడా యాక్సెస్ మంజూరు చేయబడి ఉండాలి

ప్రయోగంలో, ఈ తనిఖీలు sandbox ఎక్కడ ఫైల్‌సిస్టమ్‌ను సవరించగలదో ACLs ద్వారా ఖచ్చితంగా నిర్వచించడానికి మాకు వీలు కల్పించాయి. రైట్ ఆపరేషన్స్ చుట్టూ మాకు అవసరమైన సూక్ష్మ నియంత్రణ అందింది.

SIDs మరియు రైట్-రిస్ట్రిక్టెడ్ టోకెన్లతో, మా అన్‌ఎలివేటెడ్ sandbox ఇలా పని చేసింది:

1. sandbox సెటప్ sandbox-write అనే సింథటిక్ SID‌ను సృష్టించింది.
2. sandbox-write SID కి రాయడం, అమలు చేయడం మరియు తొలగించడం కోసం యాక్సెస్ మంజూరు చేయబడింది
   1. ప్రస్తుత వర్కింగ్ డైరెక్టరీ
   2. config.toml లో కాన్ఫిగర్ చేసిన ఏవైనా అదనపు writable_roots.
3. అదే SID కు “writable లో read-only” స్థానాలు వంటి చోట్లకు write యాక్సెస్‌ను sandbox సెటప్ స్పష్టంగా నిరాకరించింది:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex, రిస్ట్రిక్టెడ్ SID జాబితాలో Everyone, ప్రస్తుత లాగ్డ్-ఇన్ సెషన్ SID, మరియు sandbox-write సింథటిక్ SID ఉన్న రైట్-రిస్ట్రిక్టెడ్ టోకెన్ కింద కమాండ్‌లను ప్రారంభించింది.

ఈ ప్రవాహం ఫైల్ రాతలను పరిమితం చేసే సమస్యను సమర్థవంతంగా పరిష్కరించింది మరియు ఆశాజనకంగా కనిపించింది. ఇప్పుడు sandbox యొక్క నెట్‌వర్క్ యాక్సెస్‌ను పరిమితం చేయడానికి పరిష్కారం అవసరమైంది.

నెట్‌వర్క్ యాక్సెస్‌ను పరిమితం చేయడం sandbox‌లో ముఖ్యమైన భాగం; అది లేకుంటే దుష్ట కోడ్ యంత్రం నుంచి ఇంటర్నెట్‌కు డేటాను ఎక్స్‌ఫిల్ట్రేట్ చేయగలదు. మేము ఎలివేషన్ అవసరాన్ని తప్పించుకోవాలని భావించినందున, నెట్‌వర్క్ ట్రాఫిక్‌ను బలంగా నిరోధించడానికి మా వద్ద పరిమిత ఎంపికలే ఉన్నాయి. సాధారణంగా ఉపయోగించాలని అనుకునే Windows Firewall వంటి టూల్స్‌ను అడ్మినిస్ట్రేటర్ permissions లేకుండా ఇన్‌స్టాల్ చేయలేం.

Windows Firewall ఒక ఎంపికగా అందుబాటులో లేకపోవడంతో, మేము నియంత్రించగలిగిన అంశాలను పరిమితం చేసాము. డెవలపర్‌లు ఉపయోగించే నెట్‌వర్క్ టూల్స్ కోసం చైల్డ్ ఎన్విరాన్‌మెంట్‌ను fail-closedగా చేయడానికి మేము ప్రయత్నించాము, తద్వారా Git కమాండ్‌లు, ప్యాకేజ్ ఇన్‌స్టాలర్‌లు మొదలైనవి శాండ్‌బాక్స్‌లో విఫలమవుతాయి మరియు వినియోగదారు ఇంటర్నెట్ ఆపరేషన్‌లను అనుమతించాలి. ఆలోచన స్పష్టంగా కనిపించే తప్పించుకునే మార్గాలను పనికిరాకుండా చేయడం: ప్రాక్సీ-అవేర్ ట్రాఫిక్‌ను పనిచేయని ఎండ్‌పాయింట్‌కు పంపడం, Git యొక్క HTTP(S) ట్రాన్స్‌పోర్ట్ కూడా అదే చేయడం, అలాగే SSH ద్వారా Git వెంటనే విఫలమయ్యేలా చేయడం. దానికి తోడు, మేము చిన్న denybin డైరెక్టరీని PATH ప్రారంభంలో చేర్చాము మరియు 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

ఇది సాధారణ tool-driven ట్రాఫిక్‌లో చాలా భాగాన్ని అడ్డుకుంది, కానీ ఇది ఇంకా సలహా-స్థాయి పరిమితిగానే ఉంది. ఒక ప్రాసెస్ ఎన్విరాన్‌మెంట్‌ను పట్టించుకోకపోవచ్చు, PATH‌ను దాటవేయవచ్చు, లేదా నేరుగా సాకెట్స్ తెరవవచ్చు—ఇది చాలా ప్రమాదకరం.

ఏ ఆసక్తికరమైన సాఫ్ట్‌వేర్ అమలులోనైనా ఉండేలా, మొదటి ప్రోటోటైప్‌కు కొన్ని ప్రయోజనాలు మరియు లోపాలు ఉన్నాయి. ఇది కేవలం కొద్దిపాటి ప్రామాణిక Windows సామర్థ్యాలతో పని పూర్తి చేసింది, చాలా స్పష్టమైన మరియు సూక్ష్మమైన ఫైల్సిస్టమ్ రైట్స్‌ను అనుమతించింది, మరియు అన్‌ఎలివేటెడ్‌గా నడిచింది—దాంతో వినియోగదారులు అధిక ఎలివేషన్ ప్రాంప్ట్‌లను అంగీకరించాల్సిన అవసరం లేదా తమ స్థానిక యంత్రంలో అడ్మిన్లు కావాల్సిన అవసరం తగ్గింది—అయితే, దీంట్లో కొన్ని నిజమైన లోపాలు ఉన్నాయి; వాటిలో కొన్ని దీన్ని మా తుది రూపకల్పనగా మారకుండా అనర్హం చేశాయి:

• సెటప్ వేగం: వర్క్‌స్పేస్ ACLs‌ను వర్తింపజేయడం, వర్క్‌స్పేస్ డైరెక్టరీ టోపాలజీపై ఆధారపడి ఖరీదైన పని కావచ్చు.
• ఫుట్‌ప్రింట్: మేము డెవలపర్ సిస్టమ్‌పై నిజమైన ACLs‌ను వర్తింపజేశాం. అయితే ఫుట్‌ప్రింట్ ప్రత్యేకంగా చొరబాటు చేసే విధంగా లేదు, ఎందుకంటే వర్తింపజేసిన ACLs అన్నీ sandbox మాత్రమే ఉపయోగించే కస్టమ్-క్రియేటెడ్ సింథటిక్ SID‌కు సంబంధించినవే.
• మార్చడం కష్టమైన సెమాంటిక్స్: ఫైల్-ఆధారిత పరిమితుల కోసం ACLలపై ఆధారపడడం వల్ల శాండ్‌బాక్స్ సెమాంటిక్స్‌ను మార్చడం ఖర్చుతో కూడుకున్నదిగా మరియు క్లిష్టంగా మారుతుంది. అయితే macOSలో, మనం .sbpl ను రూపొందించే విధానాన్ని డైనమిక్‌గా మార్చగలం Seatbelt‌ను కాన్ఫిగర్ చేయడానికి ఉపయోగించే ఫైల్ అయితే, ACLలను సర్దుబాటు చేయడానికి Windows sandbox‌కు నెమ్మదిగా జరిగే మరియు వనరులు ఎక్కువగా వినియోగించే చర్య అవసరం కావచ్చు.
• నెట్‌వర్క్ రక్షణ బలహీనంగా ఉంది. ముందే చెప్పినట్లుగా, ఇది “advisory” మాత్రమే. తమ స్వంత నెట్‌వర్కింగ్ స్టాక్ అమలు చేసిన కొన్ని ప్రోగ్రామ్‌లు దీన్ని ఖచ్చితంగా దాటవేసేవి, మరియు ప్రతికూల కోడ్‌ను తట్టుకునేలా ఇది రూపొందించబడలేదు.

మొదటి మూడు సమస్యలు ఏజెంటిక్ ఫ్లోస్‌కు సరిపడేంత ఫ్లెక్సిబుల్‌గా ఉండే కస్టమ్ sandbox ఇంప్లిమెంటేషన్‌కు సహజసిద్ధమైనవే. కానీ నెట్‌వర్క్ సప్రెషన్ విషయం మాత్రం వేరు.

ఒక దుష్ట ఏజెంట్ ఎన్విరాన్‌మెంట్ ఆధారిత నెట్‌వర్క్ సప్రెషన్‌ను సులభంగా దాటవేయగలగడమే కాక, ఎన్విరాన్‌మెంట్ ప్రాక్సీ వేరియబుల్స్‌ను గౌరవించని లేదా తమ స్వంత సాకెట్-ఆధారిత నెట్‌వర్కింగ్‌ను అమలు చేసే మంచి ఉద్దేశ్యంతో ఉన్న చాల కోడ్ లేదా బైనరీస్ కూడా దాన్ని దాటవేస్తాయి. ఈ అంశం ఒక్కటే మెరుగైన sandbox మోడ్‌లో పెట్టుబడి పెట్టడానికి సరిపోతుందని మేము భావించాం.

మరింత మెరుగైన నెట్‌వర్క్ సప్రెషన్ కోసం, outbound నెట్‌వర్క్ ట్రాఫిక్‌ను వినియోగదారులు లేదా ప్రోగ్రామ్‌లకు బ్లాక్ చేయగల Windows Firewall‌ను ఉపయోగించాలని అనుకున్నాం. దురదృష్టవశాత్తు, Codex harness సృష్టించే కమాండ్‌లకే వర్తించేలా firewall rule‌ను మేము సమర్థవంతంగా రూపొందించలేకపోయాం. దానికి కొన్ని కారణాలు ఉన్నాయి:

• పరిమిత టోకెన్ యొక్క ప్రధానంకాని గుర్తింపుతో ఫైర్‌వాల్ నియమాన్ని సరిపోల్చడానికి Windows అనుమతించదు. దీని అర్థం, “దాని restricted SID జాబితాలో మా సింథటిక్ SID ఉన్న ఏ టోకెన్‌కైనా” ఫైర్‌వాల్ రూల్‌ను మేము వర్తింపజేయలేకపోయాం.
• ఒక నిర్దిష్ట బైనరీ‌కు సరిపోలే ఫైర్‌వాల్ రూల్‌ను సృష్టించగలిగినా, దాంతో codex.exe కు మాత్రమే నెట్‌వర్కింగ్‌ను పరిమితం చేయగలం. వినియోగదారు తరఫున ఏజెంట్ ప్రారంభించే Git లేదా Python ప్రాసెస్‌ల వంటి ప్రాసెస్‌లకు ఇది వర్తించదు.
• ఇతర ఫైర్‌వాల్ మ్యాచ్ డైమెన్షన్లు కూడా తప్పు ఆకృతిలో ఉన్నాయి. ఎలివేట్ చేయని డిజైన్‌లో, వినియోగదారు-పరిధి నియమాలు పరిమితం చేయబడిన చైల్డ్‌తో మాత్రమే కాకుండా, నిజమైన Windows వినియోగదారుతో కూడా సరిపోలాయి. ప్రోగ్రామ్-పాత్ నియమాలు చాలా స్థూలంగా ఉండేవి: అవి సాధారణంగా codex.exe లేదా python.exe ను బ్లాక్ చేయగలిగేవి, కానీ ఈ సాండ్‌బాక్స్‌లో నడిపిన python.exe యొక్క నిర్దిష్ట అమలును కాదు. పోర్ట్- లేదా చిరునామా-ఆధారిత నియమాలు కూడా పూర్తిగా తప్పుడు విధానం. ఉదాహరణకు, మేము పోర్ట్ 443ని బ్లాక్ చేయాలనుకోలేదు; ఈ నిర్దిష్ట పరిమిత ప్రాసెస్ ట్రీ కోసం అనియంత్రిత అవుట్‌బౌండ్ యాక్సెస్‌ను బ్లాక్ చేయాలనుకున్నాము.

మా sandboxed కమాండ్‌లకు ప్రత్యేకంగా ఫైర్‌వాల్ రూల్‌ను వర్తింపజేయాలంటే, వాటిని “నిజమైన” యూజర్‌గా కాకుండా వేరు ప్రిన్సిపల్‌గా నడపాల్సి వచ్చింది. ఈ విధానం మమ్మల్ని కొత్త మార్గంలోకి నడిపించింది—అందులో మా “no elevation” పరిమితిని సడలించాం.

మా ప్రస్తుత అమలులో ఉన్న సాండ్‌బాక్స్ యొక్క తదుపరి పునరావృతం సెటప్ సమయంలో అధిక స్థాయి నిర్వాహక అనుమతులను అవసరం చేస్తుంది. కాబట్టి, నేను దానిని “ఎలివేటెడ్ సాండ్‌బాక్స్” అని పిలుస్తాను. సిస్టమ్‌లో Codex ఒక కమాండ్‌ను ప్రారంభించే సరిహద్దు వద్ద, ఎలివేటెడ్ సాండ్‌బాక్స్ ఎలివేట్ చేయని సాండ్‌బాక్స్ లాగా కనిపిస్తుంది. ఇది ఇప్పటికీ చైల్డ్ ప్రాసెస్‌లను ఒక restricted టోకెన్ కింద రన్ చేస్తుంది—అలాగే [Everyone, Logon, Synthetic]అనే అదే restricted SID జాబితాతో ఉన్నwrite_restricted టోకెన్—అయితే, ఈ టోకెన్ యొక్క ప్రిన్సిపల్ ఇకపై అసలు Windows యూజర్ కాదు, Codex స్వయంగా సృష్టించిన రెండు లోకల్ యూజర్లలో ఒకటి:

• CodexSandboxOffline (firewall rules లక్ష్యంగా చేసేది)
• CodexSandboxOnline (firewall rules లక్ష్యంగా చేయనిది)

చిన్న వివరంలా కనిపించినా, ఇది sandbox పై, దాన్ని ఎవరు ఉపయోగించగలరో, అలాగే దాని setup మరియు runtime execution సంక్లిష్టతపై పెద్ద ప్రభావాన్ని చూపుతుంది.

దృశ్యపరంగా ఇది అన్‌ఎలివేటెడ్ ప్రోటోటైప్‌కు పోలి ఉంటుంది, కానీ ఫైర్‌వాల్ rules మరియు కమాండ్‌లను నిజంగా నడిపే dedicated Windows యూజర్ ఇక్కడ ప్రవేశించాయి. (అయితే, ఈ కొత్త భావనల ప్రవేశం వల్ల sandbox కమాండ్‌లను నడపడం ప్రారంభించే ముందు మరింత setup పని చేయాలి.)

Unelevated sandbox రూపకల్పనలో setup దశ సరళంగా ఉండేది, కానీ అది తక్కువ పరిమాణంలో ఉండేది:

• అవసరమైతే synthetic SID సృష్టించండి
• sandbox-write synthetic SID కోసం ACLs ను వర్తింపజేయండి

కానీ elevated sandbox లో చేయాల్సింది ఇంకా ఎక్కువ.

• ఇప్పటికే సృష్టించకపోతే synthetic SID సృష్టించండి
• ఇప్పటికే సృష్టించకపోతే online మరియు offline sandbox వినియోగదారులను సృష్టించండి
• కొత్తగా సృష్టించిన వినియోగదారుల క్రెడెన్షియల్స్‌ను స్థానికంగా నిల్వచేసి, sandbox వినియోగదారులు నిజంగా చదవలేని ప్రదేశంలో Windows Data Protection API (DPAPI) ఉపయోగించి ఎన్‌క్రిప్ట్ చేయండి
• అన్ని outbound నెట్‌వర్క్ యాక్సెస్‌ను బ్లాక్ చేసే ఫైర్‌వాల్ రూల్స్‌ను సృష్టించండి CodexSandboxOffline యూజర్ కోసం లేదా అవి ఇప్పటికే ఉంటే, అవి సరైనవని ధృవీకరించండి

సెటప్ దశలో మరో అదనపు చిక్కు ఉంది. Codex యొక్క శాండ్‌బాక్స్‌కు అసలు Windows వినియోగదారునికి సమానమైన రీడ్ యాక్సెస్ ఉండాలని అంచనా వేయబడుతుంది. ఎలివేట్ చేయని సాండ్‌బాక్స్‌లో, పరిమిత టోకెన్ యొక్క ప్రధాన SID Windows వినియోగదారు అయిన చోట, ఇది సాధించబడింది. అయితే, ప్రిన్సిపల్ కొత్త CodexSandbox వినియోగదారుగా మారినప్పుడు అది ఉచితంగా రాదు. Windows లోని అనేక సంబంధిత డైరెక్టరీలు “Authenticated Users” కు చదవడం/అమలు చేయడం అనుమతులను మంజూరు చేస్తాయి. గమనించదగిన ఉదాహరణల్లో ఒకటి వినియోగదారు ప్రొఫైల్ డైరెక్టరీ. డిఫాల్ట్‌గా, Windows వినియోగదారులు ఇతర Windows వినియోగదారుల ప్రొఫైల్ డైరెక్టరీలను చదవలేరు, కాబట్టి అనేక సందర్భాల్లో సాధారణ ఫైల్ చదవడాలు కూడా విఫలమవుతాయి.

దీనిని పరిష్కరించడానికి, sandbox వినియోగదారులకు ఇప్పటికే అలాంటి ACLs లేకపోవచ్చిన చోట్ల read ACLs మంజూరు చేసే మరొక పొరను sandbox setup ప్రక్రియకు జోడించాం. ఉదాహరణకు, సాధారణంగా ఉపయోగించే కొన్ని Windows డైరెక్టరీలకు:

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

ఈ డైరెక్టరీల జాబితా సాధ్యమైనంత మేరకు మాత్రమే ఉంటుంది, మరియు ఒక్కో దానిపై ACLs‌ను ఇన్‌స్టాల్ చేయడం ఖరీదైన పని కావచ్చు. కాబట్టి వినియోగదారులకు బ్లాకింగ్‌గా ఉండే sandbox సెటప్ దశ, అవి పూర్తయ్యేంత వరకు వేచి ఉండాల్సిన అవసరం లేకుండా, మేము ఈ లాజిక్‌ను అసింక్రోనస్‌గా నడుపుతాం.

సెటప్ లాజిక్‌ను దాని స్వంత బైనరీలో ఎన్‌క్యాప్సులేట్ చేశాము; దానికి ఒక కారణం, UAC సరిహద్దును అవసరమైనప్పుడు మాత్రమే దాటడమే. కానీ మరింత లోతైన కారణం ఆర్కిటెక్చర్‌కు సంబంధించినది: సాండ్‌బాక్స్ సెటప్‌కు codex.exe కంటే మౌలికంగా భిన్నమైన పని ఉంది. sandbox సెటప్ లాజిక్‌ను డెడికేటెడ్ బైనరీలో ఉంచడం వల్ల codex.exe సాధారణ, unelevated హార్నెస్‌గానే ఉండగలిగింది; ఇతర ప్లాట్‌ఫారమ్‌లపై Windows-only setup machinery వల్ల codex.exe భారంగా మారకుండా నివారించింది; ఎక్కువసేపు నడిచే సెటప్ పనిని ప్రధాన ప్రాసెస్ జీవితకాలం నుంచి వేరు చేసింది; మరియు sandbox‌కు అవసరమైన భిన్న సెటప్ మార్గాలన్నింటినీ నిర్వహించడానికి ఒకే స్థలం ఇచ్చింది.

Windows‌లో యూజర్ మరియు టోకెన్ లాగిన్ బౌండరీస్ పని చేసే విధానంవల్ల, అన్‌ఎలివేటెడ్ sandbox‌లో చేసినట్టుగా రిస్ట్రిక్టెడ్ టోకెన్‌ను సృష్టించి దాని కింద ప్రాసెస్‌ను spawn చేయడం మేము కొనసాగించలేకపోయాం. నిజంగా వేరే Windows యూజర్‌గా కమాండ్‌లను spawn చేయడానికి, మొదట మేము ఈ ప్రవాహాన్ని అనుకున్నాం:

• codex.exe నిజమైన Windows వినియోగదారుగా నడుస్తుంది. తర్వాత, ఒక క్రమంలో, Codex:
  • శాండ్‌బాక్స్ వినియోగదారు కోసం LogonUserW(...) ని కాల్ చేస్తుంది.
  • ఆ sandbox-user టోకెన్‌పై CreateRestrictedToken(...) ని కాల్ చేస్తుంది.
  • ఆ పరిమితం చేయబడిన sandbox-user టోకెన్‌ను ఉపయోగించి, తుది చైల్డ్ ప్రాసెస్‌ను ప్రారంభించడానికి CreateProcessAsUserW(...) ను కాల్ చేస్తుంది.

ఆచరణలో, CreateProcessAsUserW(...) వద్ద అధికారాల అడ్డంకి కారణంగా ఆ కోరుకున్న ఫ్లో పనిచేయలేదు. దీని అర్థం codex.exe శాండ్‌బాక్స్ వినియోగదారుని కోసం ఒక పరిమిత టోకెన్‌ను సృష్టించగలిగింది, కానీ సరిహద్దు యొక్క నిజమైన-వినియోగదారు వైపు నుంచి ఆ టోకెన్‌తో ఒక చైల్డ్ ప్రాసెస్‌ను విశ్వసనీయంగా ప్రారంభించలేకపోయింది. సాండ్‌బాక్స్ వినియోగదారుగా ఇప్పటికే నడుస్తున్న ఒక ప్రాసెస్ మాకు అవసరమైంది—దీనివల్ల పరిమితి విధించే దశ మరియు చివరి స్పాన్, నిజమైన-వినియోగదారు వైపు కాకుండా సరిహద్దు యొక్క సాండ్‌బాక్స్-వినియోగదారు వైపున జరుగుతాయి.

ఆ అవసరం codex-command-runner.exe అనే కొత్త బైనరీకి దారితీసింది, దీని ఏకైక పని పరిమితం చేయబడిన టోకెన్‌ను సృష్టించి, అభ్యర్థించిన కమాండ్‌ను ప్రారంభించడం. codex.exe మొత్తం ప్రవాహాన్ని స్వయంగా చేయమని అడగడం బదులు (నిజమైన యూజర్ → sandbox యూజర్ → రిస్ట్రిక్టెడ్ టోకెన్ → child process), మేము ప్రవాహాన్ని రెండుగా విభజించాం:

భాగం 1

• codex.exe restricted టోకెన్‌ను ఇంకా ఉపయోగించకుండా, sandbox యూజర్‌గా codex-command-runner.exe ను ప్రారంభించడానికి CreateProcessWithLogonW(...) ను కాల్ చేస్తుంది.

భాగం 2

• runner లోపల, OpenProcessToken(GetCurrentProcess(), ...) runner యొక్క స్వంత టోకెన్‌ను తెరుస్తుంది, అది ఇప్పటికే sandbox వినియోగదారుకు చెందినది.
• runner sandbox logon SID ను సంగ్రహించడానికి GetTokenInformation(...) ను కాల్ చేసి, తరువాత తుది పరిమిత టోకెన్‌ను నిర్మించడానికి CreateRestrictedToken(...) ను కాల్ చేస్తుంది.
• ఇంకా runner లోపలే, నిజమైన child ను ప్రారంభించడానికి ఆ పరిమితం చేసిన టోకెన్‌తో CreateProcessAsUserW(...) ను అది కాల్ చేస్తుంది.

ఆల్బర్ట్ ఐన్‌స్టీన్ ఇలా అన్నాడు: “Everything should be made as simple as possible, but no simpler.” ఆ భావనతో, మా రూపకల్పన ప్రతి సమస్యను తగిన విధంగా పరిష్కరించింది. తుది ఆర్కిటెక్చర్ లో మేము ముందుగా కవర్ చేసిన నాలుగు పొరలు ఉన్నాయి:

• codex.exe స్వయంగా
• codex-windows-sandbox-setup.exe అన్ని ఎలివేటెడ్ సెటప్-సంబంధిత పనులను హ్యాండిల్ చేయడానికి
• codex-command-runner.exe రిస్ట్రిక్టెడ్ టోకెన్ కమాండ్‌లను రన్ చేయడానికి
• child process

నేను ఈ ప్రాజెక్ట్‌కి మొదట చేరుకున్నప్పుడు, ఇది చివరకు ఎక్కడికి చేరుతుందో నాకు స్పష్టమైన అంచనా లేదు. నా విధానం, Codex మరియు ఆపరేటింగ్ సిస్టమ్ మధ్య బౌండరీలో sandboxing సామర్థ్యాన్ని ఇన్‌స్ట్రుమెంట్ చేయడం నుంచి ప్రారంభమైంది. ఈ విధానం MacOS మరియు Linux లో Codex యొక్క sandbox ఇంప్లిమెంటేషన్‌కు దగ్గరగా సరిపోతుంది.

Windows అందించే నిర్దిష్ట టూల్స్ గురించి మరింత నేర్చుకుంటూ, భద్రత మరియు వినియోగ సౌలభ్యం మధ్య డజన్ల కొద్దీ ట్రేడ్‌ఆఫ్స్ తీసుకుంటూ, ఈ సిస్టమ్ ప్రస్తుత రూపానికి చేరుకుంది—అనేక బైనరీస్, కస్టమ్ యూజర్లు, ఫైర్‌వాల్ రూల్స్, ఎలివేటెడ్ సెటప్ దశ, అసింక్రోనస్ ప్రాసెస్‌లు, ఇంకా మరెన్నో.

ఇది ప్రత్యేకంగా సులభమైన వ్యవస్థ కాదు, కానీ ప్రతి సంక్లిష్టత భాగం అవసరం వల్లే జోడించబడింది—భద్రమైనదిగా ఉండే, మరియు సాధ్యమైనంత వరకు వినియోగదారుని పనికి అడ్డంకి కాకుండా ఉండే sandbox ను నిర్మించడానికి.

Windows లో Codex వినియోగదారులకు మంచి అనుభవాన్ని అందించేందుకు పని చేస్తూ, ఉపయోగకరతను త్యాగం చేయకుండా సురక్షితమైనదాన్ని తయారుచేయడం మా లక్ష్యం—Codex ను ఉపయోగించే అసలు ఉద్దేశ్యం, మీ నిరంతర శ్రద్ధ లేకుండానే ఏజెంట్‌లు పని చేయగలగడం.

ఈ ప్రాజెక్ట్ నుంచి వచ్చిన అతిపెద్ద పాఠాలలో ఒకటి ఏమిటంటే, “సురక్షిత స్వయంచాలక కోడింగ్ ఏజెంట్” కు నేరుగా సరిపడే ఒకే primitive ను Windows మాకు ఇవ్వలేదు. మేము అనేక టూల్స్ మరియు భావనలను కలిపి ఒక సుసంబద్ధమైన సిస్టమ్‌ను నిర్మించాం. కొన్ని ప్రారంభ ఆలోచనలు dead ends గా మారాయి. తుది డిజైన్, ముందున్న ప్రోటోటైప్‌లలో ప్రతి ఒక్కటి సమస్యలోని ఒక భాగాన్ని పరిష్కరించిన వాటి హైబ్రిడ్‌గా మారింది.

మరొక పాఠం ఏమిటంటే, కోడింగ్ ఏజెంట్ కోసం భద్రత అనేది సాంప్రదాయ అప్లికేషన్ భద్రతతో పోలిస్తే భిన్నమైనది. Codex నిజమైన డెవలపర్ workflows కోసం పని చేయాలి. ఇంజినీరింగ్ పని అనేది agentic workloads‌కు అనుకూలతను, నిజమైన అమలు భద్రతతో సమతుల్యం చేయడంపైనే నిలిచింది. ఆ ఉద్రిక్తతే తుది రూపకల్పనలో ట్రేడ్‌ఆఫ్స్‌ను మలిచింది.

Codex sandbox ను పనిచేస్తూ చూడాలనే ఆసక్తి ఉందా? ప్రయత్నించండి⁠.