सैंडबॉक्स में कोड निष्पादन

adk-sandbox क्रेट ADK एजेंट के लिए पृथक कोड निष्पादन प्रदान करता है, जिसमें पृथक्करण के दो स्तर हैं:

  1. प्रक्रिया पृथक्करण — पर्यावरण पृथक्करण और समय-सीमा प्रवर्तन वाली चाइल्ड प्रक्रियाएँ
  2. OS-स्तरीय सैंडबॉक्स प्रोफ़ाइल — फ़ाइल सिस्टम, नेटवर्क और प्रक्रिया स्पॉनिंग पर कर्नेल-स्तरीय प्रतिबंध

बैकएंड

बैकएंडपृथक्करण स्तरभाषाएँफीचर फ़्लैग
ProcessBackendपर्यावरण + टाइमआउटRust, Python, JS, TS, Commandprocess (डिफ़ॉल्ट)
ProcessBackend + sandboxकर्नेल-स्तरऊपर जैसाprocess + sandbox-native
WasmBackendपूर्ण (मेमोरी, fs, नेटवर्क)केवल WASMwasm

आपको कौन-सा पृथक्करण मिल रहा है?

ProcessBackend::isolation() इसकी रिपोर्ट करता है, इसलिए इसे क्रेट के नाम से अनुमानित नहीं किया जा सकता:

परिणामअर्थ
IsolationClass::SubprocessOnlyसाफ़ किए गए वातावरण, टाइमआउट और अपने स्वयं के प्रक्रिया समूह वाली चाइल्ड प्रक्रिया। OS कोई अतिरिक्त प्रतिबंध लागू नहीं करता: कोड होस्ट फ़ाइल सिस्टम को पढ़ सकता है और नेटवर्क तक पहुँच सकता है। यही आपको ProcessBackend::default() देता है।
IsolationClass::OsEnforcedएक प्रवर्तक और एक नीति संलग्न हैं, इसलिए OS चाइल्ड प्रक्रिया को प्रतिबंधित करता है।

प्रोसेस बैकएंड के बारे में जानने योग्य दो बातें:

  • प्रोग्राम का समाधान पर्यावरण साफ़ किए जाने से पहले किया जाता है। किसी पथ के बिना दिए गए python3, node, या rustc को कॉलर के PATH में खोजा जाता है और चाइल्ड को एक पूर्ण पथ के रूप में दिया जाता है। इसका अर्थ है कि चाइल्ड को शुरू होने के लिए अपने स्वयं के PATH की आवश्यकता नहीं होती — पहले कॉलर को PATH को ExecRequest::env में रखना पड़ता था, जिससे निष्पादित कोड उस पर कोई भी अन्य चीज़ स्पॉन कर सकता था।
  • कम्पाइलेशन उसी सीमा से होकर चलता है जिससे निष्पादन चलता है। Rust स्रोत को पहले साझा पथ के बाहर बनाए गए कमांड द्वारा कम्पाइल किया जाता था, इसलिए कम्पाइल में कोई enforcer wrapper, टाइमआउट या प्रोसेस समूह नहीं होता था। यह महत्वपूर्ण है क्योंकि कम्पाइलेशन निष्क्रिय नहीं होता: include_str! फ़ाइलें पढ़ता है और उत्पादित बाइनरी के मौजूद होने से पहले procedural macros मनमाना कोड चलाते हैं। कम्पाइल चरण को प्लेटफ़ॉर्म-विशिष्ट टूलचेन allow-list मिलती है; Windows पर इसमें MSVC और Windows SDK पथ शामिल हैं, जिन्हें इंस्टॉल किए गए टूलचेन से तब खोजा जाता है जब कॉलर पहले से Developer shell में न हो। कम्पाइलेशन Rust टूलचेन के rust-lld linker का उपयोग करता है, ताकि PATH में पहले मौजूद कोई असंबंधित link.exe चुना न जा सके। OS enforcer ही इस चरण को सीमित करता है।

पर्यावरण प्राथमिकता

SandboxPolicy::env प्रत्येक निष्पादन के लिए डिफ़ॉल्ट मान प्रदान करता है और ExecRequest::env प्रति कॉल उन्हें ओवरराइड करता है। नीति के वेरिएबल पहले पूरी तरह अनदेखे किए जाते थे।

OS सैंडबॉक्स प्रोफ़ाइल

OS-स्तरीय सैंडबॉक्स प्रवर्तन चाइल्ड प्रोसेस को कर्नेल स्तर पर प्रतिबंधित करता है। यह पर्यावरण आइसोलेशन से आगे जाता है — OS स्वयं अनधिकृत फ़ाइल सिस्टम एक्सेस, नेटवर्क कनेक्शन और प्रोसेस स्पॉनिंग को रोकता है।

प्लेटफ़ॉर्म समर्थन

प्लेटफ़ॉर्मप्रवर्तनकर्तायह कैसे काम करता है
macOSSeatbelt (sandbox-exec)Syscall-स्तरीय नियम: "डिफ़ॉल्ट रूप से अनुमति दें, खतरनाक को अस्वीकार करें" — लेखन, नेटवर्क और fork को अस्वीकार करता है; पठन प्रतिबंधित नहीं हैं
Linuxbubblewrap (bwrap)फ़ाइल सिस्टम नेमस्पेस पृथक्करण (श्वेतसूची माउंट)
WindowsAppContainerकार्यान्वित नहीं — एनफोर्सर स्वयं को अनुपलब्ध बताता है

त्वरित प्रारंभ

use adk_sandbox::{
    ProcessBackend, ProcessConfig, SandboxBackend,
    SandboxPolicyBuilder, get_enforcer,
};

// 1. Define what the sandboxed process can do
let policy = SandboxPolicyBuilder::new()
    .allow_read("/usr")           // Read system libraries
    .allow_read_write("/tmp/work") // Write to work directory
    .allow_process_spawn()         // Python needs to exec
    // Network is denied by default
    .env("PATH", "/usr/bin:/usr/local/bin")
    .build();

// 2. Get the platform-appropriate enforcer
let enforcer = get_enforcer()?;

// 3. Create a sandboxed backend
let backend = ProcessBackend::with_sandbox(
    ProcessConfig::default(),
    enforcer,
    policy,
);

// 4. Execute code — network is blocked, writes restricted
let result = backend.execute(request).await?;

फ़ीचर फ़्लैग

[dependencies]
# Auto-detect platform enforcer
adk-sandbox = { version = "2.1.0", features = ["process", "sandbox-native"] }

# Or pick a specific platform
adk-sandbox = { version = "2.1.0", features = ["process", "sandbox-macos"] }
adk-sandbox = { version = "2.1.0", features = ["process", "sandbox-linux"] }

SandboxPolicy

नीति यह निर्धारित करती है कि सैंडबॉक्स किया गया प्रोसेस क्या कर सकता है:

फ़ील्डडिफ़ॉल्टविवरण
allowed_paths[] (सभी को अस्वीकार करें)केवल-पठन या पठन-लेखन पहुँच वाले फ़ाइल सिस्टम पथ
allow_networkfalseक्या नेटवर्क पहुँच की अनुमति है
allow_process_spawnfalseक्या चाइल्ड प्रोसेस को शुरू करने की अनुमति है
env{}सैंडबॉक्स किए गए प्रोसेस के लिए एनवायरनमेंट वेरिएबल्स

प्लेटफ़ॉर्म में अंतर

macOS (Seatbelt): "डिफ़ॉल्ट रूप से अनुमति दें, ख़तरनाक को अस्वीकार करें" का उपयोग करता है — पूरी पहुँच से शुरू होता है, फिर नेटवर्क, फ़ाइल लिखने और प्रक्रिया शुरू करने को अवरुद्ध करता है। शुद्ध श्वेतसूची दृष्टिकोण काम नहीं करता, क्योंकि Python को स्टार्टअप के समय macOS-विशिष्ट syscall श्रेणियों की दर्जनों श्रेणियों की आवश्यकता होती है।

Linux (bubblewrap): नेमस्पेस-आधारित श्वेतसूची का उपयोग करता है — डिफ़ॉल्ट रूप से कुछ भी मौजूद नहीं होता, केवल आवश्यक चीज़ों को माउंट किया जाता है। apt install bubblewrap या dnf install bubblewrap के साथ इंस्टॉल करें।

Windows (AppContainer): लागू नहीं किया गया है। डिज़ाइन token-आधारित ACLs पर आधारित है — डिफ़ॉल्ट रूप से बिना किसी पहुँच वाला प्रतिबंधित SID, फिर विशिष्ट पथों पर ACLs प्रदान किए जाते हैं — लेकिन container निर्माण, ACLs, क्षमताएँ और job-object cleanup अनुपस्थित हैं, इसलिए probe(), EnforcerUnavailable लौटाता है। Windows पर बिना enforcer के चलाएँ, या macOS अथवा Linux का उपयोग करें, जहाँ enforcement वास्तविक है।

उदाहरण

पूर्ण LLM-agent-driven उदाहरण के लिए examples/sandbox_agent/ देखें, जो sandboxed environment में Python code निष्पादित करता है और OS kernel द्वारा network access को अवरुद्ध रखता है।