क्या exec के बाद process replacement session approval बना रहता है?

सेशन अप्रूवल को सत्यापित execution identity के साथ जुड़ना चाहिए, ऑपरेटिंग सिस्टम के process identifier के साथ नहीं। जब कोई प्रोसेस exec कॉल करता है, तो kernel उसका PID बनाए रख सकता है, लेकिन code, arguments, environment और अक्सर उस प्रोसेस का वास्तविक उद्देश्य बदल जाता है। पुराने अप्रूवल को इस replacement के बाद भी जारी रखने पर बिना समीक्षा किए गए code को वह authority मिल जाती है, जिसे किसी व्यक्ति ने किसी और चीज़ के लिए दिया था।

मैं जो नियम लागू करूंगा, वह सीधा है: अलग executable identity वाले replacement को credentialed actions करने से पहले फिर अप्रूवल मांगना होगा। Continuity केवल उसी executable image के संकीर्ण रूप से सत्यापित re-exec के लिए रखें। इससे किसी वैध workflow में कभी-कभार एक अतिरिक्त prompt आएगा। इसके बदले हर उस workflow में एक कहीं गंभीर खामी बंद होगी, जहां agent, wrapper, updater या compromised dependency यह चुन सकती है कि अगला क्या चलेगा।

अप्रूवल PID का नहीं, actor का होता है

PID kernel के bookkeeping slot की पहचान करता है, जबकि अप्रूवल को उस program की पहचान करनी होती है जो किसी इंसान के फैसले के आधार पर कार्रवाई कर सकता है। ये अलग काम हैं। जैसे ही code दूसरे code को शुरू करता है, दोनों को एक ही object मानना समस्या पैदा करता है।

Sallyport per-session authorization को एक नए agent process के अप्रूवल के रूप में बताता है, जो उस run के खत्म होने तक रहता है। यह उपयोगकर्ता के सामने रखने के लिए उपयोगी नियम है, लेकिन implementation के लिए अंदरूनी परिभाषा अधिक स्पष्ट होनी चाहिए: approved run को वही approved executable बने रहना चाहिए, केवल वही PID बनाए रखना पर्याप्त नहीं है।

यह अंतर इसलिए महत्वपूर्ण है क्योंकि secrets gateway में रहते हैं और agent को credential material के बजाय results मिलते हैं। इससे वह आम समस्या दूर होती है जिसमें child process environment variable से token पढ़ लेता है। लेकिन substituted process अब भी gateway से API कॉल करने या stored credential के साथ SSH चलाने का अनुरोध कर सकता है। अगर उसे inherited approval मिल जाए, तो secret देखे बिना भी वह वही बाहरी नुकसान कर सकता है।

अप्रूवल का subject स्पष्ट रूप से तय करें। इसमें stable executable identity, process creation event या session nonce, व्यक्ति को दिखाई गई code-signing authority और इतना launch context होना चाहिए कि यह समझाया जा सके कि प्रोसेस क्यों मौजूद है। PID को audit attribute और troubleshooting के उपयोगी handle के रूप में रखें। इसे bearer credential न बनाएं।

यह अंतर revocation को भी ईमानदार रखता है। अगर उपयोगकर्ता किसी run को revoke करता है, तो gateway को उस run से आने वाली अगली calls को अस्वीकार करना चाहिए, भले ही वह खुद को re-exec करे। अगर replacement को नया अप्रूवल मिलता है, तो उसे नया session record मिलना चाहिए जिसे उपयोगकर्ता अलग से revoke कर सके।

PID वही रहने पर भी exec executable बदल देता है

जब exec कोई अलग program लोड करता है, तो उसे authorization reset करना चाहिए, क्योंकि operating system PID बनाए रख सकता है, लेकिन program image बदल जाती है। POSIX कहता है कि exec function «current process image को replace करता है।» यह वाक्य छोटा है, लेकिन जरूरी बात सही पकड़ता है: continuity प्रशासनिक है, यह प्रमाण नहीं कि वही actor अब भी मौजूद है।

Shell में यह बात आसानी से छूट जाती है। Developer एक approved agent शुरू करता है, agent helper को बुलाता है और helper अतिरिक्त parent process छोड़े बिना काम करने के लिए exec कॉल करता है। Process listings replacement से पहले और बाद में वही PID दिखा सकती हैं। अगर आपका session lookup कहता है कि pid 4127 is approved, तो नए helper को पुराने agent की authority मिल जाती है।

Executable बदलने से जोखिम भी ऐसे तरीकों से बदल सकता है जिन्हें PID नहीं बता सकता। Replacement किसी दूसरे host से बात कर सकता है, untrusted repository file को interpret कर सकता है, extensions लोड कर सकता है, standard input पर data स्वीकार कर सकता है या केवल action requests relay करने के लिए मौजूद हो सकता है। इनमें से कोई तथ्य process number में नहीं दिखता।

फैसला इस आधार पर न लें कि नई command line जानी-पहचानी लगती है। Command arguments उपयोगी context हैं, लेकिन program उन्हें बदल सकता है और wrapper किसी सामान्य दिखने वाली command से असंबंधित target शुरू कर सकता है। Executable identity उस image से तय करें जिसे operating system ने वास्तव में शुरू किया है। इसके बाद observed path और arguments को उस व्यक्ति के लिए evidence के रूप में रखें जो request की समीक्षा कर रहा है।

posix_spawn पर भी इसी design discussion में बात होनी चाहिए, लेकिन उसका नतीजा अलग है। वह caller की image को replace करने के बजाय child process बनाता है। Child को default रूप से session approval नहीं मिलना चाहिए। fork के बाद exec करने पर भी यही परिणाम होना चाहिए: अंततः चलने वाली image के लिए नया process approval मांगे।

नए executable के लिए नया अप्रूवल चाहिए

Gateway को यह मांग करनी चाहिए कि किसी अलग executable को पहले से authorized session के जरिए कोई action करने से पहले नया अप्रूवल मिले। «अलग» की परिभाषा verified image identity से करें, filename या display name से नहीं।

एक व्यावहारिक identity record में platform का immutable executable identifier, उपलब्ध होने पर signed code का digest, signing authority और launch के समय देखा गया वास्तविक executable path शामिल हो सकता है। पहले दो fields बताते हैं कि image बदली है या नहीं। Signer reviewer को बताता है कि code की जिम्मेदारी किसने ली है। Path reviewer को बताता है कि launch कहां से हुआ। हर field अलग सवाल का जवाब देता है, इसलिए इन्हें एक string में न मिलाएं।

यही वह failure है जो permissive inheritance को तब तक आकर्षक दिखाता है, जब तक बहुत देर न हो जाए। एक approved coding agent repository helper को बुलाता है। Helper environment setting देखता है और उसी अपेक्षित path पर मौजूद locally built utility से खुद को replace कर लेता है। Utility को API credential निकालने की जरूरत नहीं है। वह HTTP action का अनुरोध करती है जो deployment हटा देता है, billing setting बदल देता है या release पोस्ट कर देता है। Gateway पुराना PID देखकर call स्वीकार कर लेता है। व्यक्ति ने coding agent को अप्रूव किया था, उस utility को नहीं जिसने approval के बाद खुद को चुन लिया।

Inherited approval के पक्ष में आम तर्क prompt fatigue है। यह चिंता वास्तविक है, लेकिन arbitrary replacement की अनुमति prompt fatigue हल नहीं करती। इससे उस व्यक्ति से एक फैसला छिप जाता है जो यह तय कर सकता है कि replacement उचित है या नहीं। सामान्य agent run को stable बनाकर approval cards कम रखें, फिर actor बदलने के क्षण पर दोबारा पूछें।

जांच credential injection, SSH execution या किसी भी दूसरे outbound action से पहले होनी चाहिए। Gateway किसी replacement को ऐसा metadata लौटाने से पहले भी जांच करे जो उसे action की योजना बनाने में मदद कर सकता है। Pending approval आधे-अधूरे authorization की स्थिति नहीं है।

Same-image re-exec एक सीमित अपवाद है

बिल्कुल उसी executable image का verified re-exec session approval बनाए रख सकता है, क्योंकि इससे नया actor नहीं आता। Programs clean restart, बदले हुए file descriptors या अपना environment update करने के बाद जानबूझकर handoff के लिए self-re-exec का इस्तेमाल करते हैं। ऐसे मामले में नया card दिखाना meaningful decision जोड़े बिना केवल noise बढ़ाता है।

अपवाद को सीमित रखें। Gateway को मौजूदा observed image की तुलना उस image से करनी चाहिए जिसे approval मिला था। अगर identity बिल्कुल समान है, तो वह session nonce बनाए रख सकता है और audit log में continuity event लिख सकता है। अगर gateway उस identity को स्थापित नहीं कर पाता, तो उसे फिर पूछना चाहिए। अस्पष्टता replacement के सुरक्षित होने का प्रमाण नहीं है।

इसे signer-wide exception न बनाएं। कोई signer agent, installer, diagnostic tool और network utility प्रकाशित कर सकता है। इन programs की action authority बहुत अलग हो सकती है। Visible signing authority उपयोगकर्ता को request पर फैसला लेने में मदद करती है, लेकिन समान authority वाले हर binary तक approval को चुपचाप नहीं बढ़ाना चाहिए।

इसे path-wide exception भी न बनाएं। Self-update fixed path पर bytes बदल सकता है। Approval के बाद symlink कहीं और point कर सकती है। कोई script filename वही रखते हुए contents बदल सकती है। Identity comparison को इन तीनों स्थितियों में भी सही रहना चाहिए।

जब कोई वैध update agent का नया version install करे, तो उसे फिर पूछने दें। यह prompt एक वास्तविक तथ्य बताता है: कार्रवाई करने वाला executable बदल गया है। जिस उपयोगकर्ता को update सामान्य लगे, वह उसे एक click में approve कर सकता है। जिस उपयोगकर्ता को बदलाव की उम्मीद नहीं थी, उसके पास उसे रोकने का अवसर रहेगा।

Code-signing authority लोगों को फैसला लेने में मदद करती है, लेकिन scope नहीं देती

Code-signing authority को प्रमुखता से दिखाएं, क्योंकि इससे उस सवाल का जवाब मिलता है जो लोग वास्तव में पूछते हैं: यह executable किसने भेजा है? इस जवाब को authorization का पूरा नियम न समझें।

Apple का code-signing model macOS को signed code की पहचान करने और लागू trust rules के तहत उसकी integrity सत्यापित करने का तरीका देता है। Approval card के लिए यह मजबूत evidence है। लेकिन इससे यह नहीं कहा जाता कि किसी एक authority का हर code एक ही operational purpose रखता है। यह भी पता नहीं चलता कि parent process ने untrusted repository setting के जरिए executable चुना था या नहीं।

एक अच्छा approval card पहले executable name और path दिखाता है, फिर signing authority, parent identity और नई request का कारण। Exec replacement के लिए उसे एक ही वाक्य में बदलाव के दोनों पक्ष बताने चाहिए: approved agent ने खुद को इस executable से replace किया। व्यक्ति को दो अलग prompts की तुलना करके transition का अनुमान नहीं लगाना चाहिए।

Signed और unsigned दोनों स्थितियों में यही boundary रखी जानी चाहिए। Unsigned local developer build development workflow का अपेक्षित हिस्सा हो सकता है, और signed utility फिर भी ऐसी process हो सकती है जिसे authority inherit नहीं करनी चाहिए। Card को evidence बताना चाहिए, लेकिन ऐसा दिखावा नहीं करना चाहिए कि signature नया executable पुराने executable में बदल देती है।

«trusted process» जैसे अस्पष्ट labels से बचें। वे लोगों को concrete request के बजाय किसी category को approve करने के लिए प्रेरित करते हैं। Executable का नाम दें और पहले से approved process के साथ उसका संबंध दिखाएं। इससे reviewer के पास ऐसी स्पष्ट जानकारी होगी जिसे वह पहचान या अस्वीकार सके।

Scripts और launchers कमजोर boundary दिखाते हैं

Script-driven launch के लिए दो identities चाहिए: चलाने वाला interpreter और वह script जिसके contents उसे नियंत्रित करते हैं। अगर आप केवल interpreter की जांच करते हैं, तो हर shell script एक ही shell जैसी दिखती है। अगर आप केवल script की जांच करते हैं, तो shebang line या wrapper से चुना गया interpreter छूट सकता है।

Shell script के लिए interpreter executable identity, resolved script path और script contents का digest दर्ज करें। अगर script approved shell के जरिए चलती है और फिर वह shell किसी दूसरे binary को exec करता है, तो binary replacement के लिए अब भी नया approval जरूरी है। Script session boundary के आर-पार जाने का रास्ता नहीं बननी चाहिए।

Launchers इससे जुड़ी एक और समस्या पैदा करते हैं। Approved launcher config file देख सकता है, PATH पर कोई tool खोज सकता है, helper download कर सकता है या version directory चुन सकता है। Launcher को approve करके उसके selected target को उसी run का हिस्सा मान लेना आम है। यह नियम गलत है, जब launcher उपयोगकर्ता के approval के बाद security-relevant choice करता है।

दो में से एक तरीका अपनाएं। अगर launcher अपनी पहली gateway call से पहले target जानता है, तो card में final target दिखाकर उसी execution identity को approve करें। अगर वह बाद में चुनता है, तो उसे action authority के बिना चलने दें और selected target के पहली बार action मांगने पर approval लें। दूसरा विकल्प अधिक ईमानदार audit trail देता है।

यही नियम runtime plug-ins और embedded interpreters पर भी लागू होता है। Native host वही रह सकता है, जबकि वह project directory से code लोड करे। अगर loaded code gateway requests तैयार कर सकता है, तो केवल host की image identity वास्तविक actor का पूरा वर्णन नहीं करती। Gateway हर runtime की सुरक्षित जांच नहीं कर सकता, इसलिए बेहतर default यह है कि session approval को एक defined agent executable तक सीमित रखें और जब वह किसी external program को action control दे, तब नया निर्णय मांगें।

Children और exec अलग delegation मामले हैं

किसी child process को केवल इसलिए session approval inherit नहीं करना चाहिए कि उसके parent के पास approval है। Process creation नया actor लाता है, जबकि exec मौजूदा actor को replace करता है। दोनों मामलों में जब अलग executable gateway calls करेगा, नया approval जरूरी है, लेकिन उनके audit relationships अलग होने चाहिए।

Child के लिए parent-session reference वाला नया session candidate बनाएं। Approval card में parent दिखाएं, क्योंकि वह उपयोगी context देता है, permission नहीं। अगर उपयोगकर्ता child को approve करता है, तो उसे अपना session nonce और अपना revocation handle दें।

Exec के लिए पुराने executable identity को बंद या supersede करें और पिछले session से जुड़ा replacement candidate बनाएं। अगर नई image approved image से बिल्कुल मेल खाती है, तो continuity बनाए रखें और यह नतीजा दर्ज करें। अगर वह अलग है, तो gate पर रुकें और निर्णय की प्रतीक्षा करें। इससे एक ऐसा बड़ा session record नहीं बनता जिसमें कई असंबंधित programs शामिल हों।

Parent को children या replacements को देने के लिए कोई general delegation token न बनाएं। «anything I start may act» कहने वाला token compromised agent या confused wrapper के लिए आसान इनाम बन जाता है। Journal में parent reference ancestry की कहानी बताने के लिए पर्याप्त है, उसे authority में बदलने की जरूरत नहीं है।

यह अलगाव incident review को भी बेहतर बनाता है। आप बता सकते हैं कि parent ने child शुरू किया था या खुद को replace किया था, और क्या किसी व्यक्ति ने resulting executable को approve किया था। Allowed requests का flat record किसी खराब action के बाद इन सवालों का जवाब नहीं दे सकता।

Replacement को अपना अलग event बनाएं

Audit log में exec replacement को अलग event के रूप में दिखना चाहिए, चाहे gateway ने approval बनाए रखा हो या फिर से मांगा हो। उस event के बिना reviewer एक session की actions देखकर मान सकता है कि वे सभी एक ही stable executable ने की थीं।

Design contract इस तरह दिख सकता है। यह persist की जाने वाली जानकारी का उदाहरण है, जरूरी wire format नहीं:

{
  "event": "execution_replaced",
  "session_id": "sess_8f2c",
  "previous_image": {
    "identity": "image:4f19...",
    "path": "/work/agent/bin/agent"
  },
  "current_image": {
    "identity": "image:b66a...",
    "path": "/work/agent/bin/release-helper",
    "signing_authority": "Example Development Team"
  },
  "decision": "approval_required",
  "parent_relation": "exec"
}

Event में केवल यह लिखना पर्याप्त नहीं है कि exec हुआ। उसमें पुरानी और मौजूदा identities भी चाहिए, साथ ही decision outcome भी। बाद के action record को current session identity का reference देना चाहिए, ताकि investigator action को उस approval से जोड़ सके जिसने उसे अनुमति दी थी।

इस record को बाकी action history की तरह append-only रखें। Sallyport का encrypted, hash-chained audit log और offline sp audit verify check यहां खास उपयोगी हैं, क्योंकि replacement event और उसके बाद की actions एक ही सत्यापित sequence में रह सकती हैं। Verification result यह साबित करता है कि stored sequence बदली नहीं है। इससे शुरुआत में बहुत व्यापक approval policy सही नहीं हो जाती।

जब उपयोगकर्ता session revoke करे, तो revocation उस executable identity के विरुद्ध दर्ज करें जिसके पास session था। अगर replacement को नया approval मिल चुका है, तो वह अलग से दिखाई देना चाहिए। यह विवरण revoke control को अपनी वास्तविक सीमा से अधिक व्यापक दिखने से रोकता है।

Approval card में पहले और बाद की जानकारी चाहिए

Exec के बाद दिखने वाला fresh-approval card replacement को एक नजर में समझाए और सुरक्षित विकल्प चुनना आसान बनाए। सामान्य prompts लोगों को बिना पढ़े click करने की आदत डालते हैं। बदले हुए executable का नाम लेने वाला card तभी रुकने का कारण देता है, जब सचमुच कुछ बदला हो।

नए executable की identity और उसके इस्तेमाल किए जाने वाले action channel से शुरुआत करें। फिर दिखाएं कि इसे पहले से approved process ने शुरू किया है, पुराना executable name और path क्या है, नया path क्या है और code-signing authority कौन है। अगर replacement script या launcher से आया है, तो उस संबंध को सरल भाषा में बताएं।

ऐसा decision model इस्तेमाल करें जो ठीक-ठीक दिखाए कि उपयोगकर्ता किस चीज़ को approve कर रहा है। Replacement approve करने पर उस executable का run उसके exit होने तक अधिकृत होना चाहिए, vault gate और per-call approval के लिए चिह्नित किसी credential के अधीन। इससे sibling processes, future replacements या उसी path पर updated file को पीछे से authorization नहीं मिलना चाहिए।

शब्दों की एक उपयोगी जांच है: क्या थका हुआ developer expected helper और surprise downloader के बीच अंतर बता सकता है? अगर नहीं, तो card में जरूरी facts नहीं हैं। अधिक सजावटी security language इसे ठीक नहीं करेगी।

Prompt की संख्या broad inheritance से नहीं, stable execution से कम रखें। सामान्य agent अगर एक ही image बनाए रखता है, तो उसे एक session card दिखना चाहिए। Actor बदलने वाला process card दिखाए, क्योंकि उसने उसी स्पष्ट boundary को पार किया है जिसे enforce करने के लिए session concept बनाया गया है।

Tests उन बचने के तरीकों पर बनाएं जिन्हें लोग वास्तव में इस्तेमाल करते हैं

Authorization boundary की जांच उन replacements से करें जो ऊपर से दिखने वाले identifiers बनाए रखते हैं। Stable binary के साथ happy-path testing उन errors को नहीं खोज पाएगी जो authority गलत executable को दे देते हैं।

इन मामलों से शुरुआत करें:

• Approved binary अपनी बिल्कुल सही copy को re-exec करता है। Gateway session बनाए रखता है और continuity event दर्ज करता है।
• Binary उसी authority के अलग signed executable को re-exec करता है। व्यक्ति के नए run को approve करने तक gateway actions अस्वीकार करता है।
• Symlink में वही path string रहती है, लेकिन वह अलग executable पर resolve होती है। Gateway फिर approval मांगता है।
• Session शुरू होने के बाद shell script के contents बदलते हैं। अगली script-controlled request पहले के decision का इस्तेमाल नहीं करती।
• Launcher child शुरू करता है और child HTTP या SSH action की कोशिश करता है। Child को अपना session decision चाहिए।

इसके बाद ordering की जांच करें। Replacement को exec के तुरंत बाद action request भेजने दें। पुष्टि करें कि gateway उसे अस्वीकार करता है या pending रखता है, और approval result आने से पहले न credential injection शुरू होती है, न SSH execution। इससे वे implementations पकड़ी जाती हैं जो काम dispatch करने के बाद journal update करती हैं।

इसी suite में revocation की भी जांच करें। Approved run को revoke करें, same-image re-exec आजमाएं और पुष्टि करें कि revoked state प्रभावी रहती है। नए replacement को approve करें, केवल original session को revoke करें और पुष्टि करें कि दोनों records product के बताए controls के अनुसार व्यवहार करते हैं। Session model पर भरोसा तभी बनता है, जब उसके edge cases उसकी दिखाई देने वाली भाषा के अनुसार व्यवहार करें।

अंत में audit output को इंसान की तरह पढ़कर देखें। आप एक action को replacement event के जरिए उस approval card तक trace कर सकें, जिसने executable को cover किया था। अगर इसके लिए PIDs मिलाने, timestamps से अनुमान लगाने या ऐसे path पर भरोसा करने की जरूरत पड़ती है जो बदल चुका हो सकता है, तो model में अब भी खामी है।

Process replacement वह क्षण है जब सख्त होना चाहिए। पुराने code के पास एक decision था। नए code को अपना decision चाहिए।