Gateway

सैंडबॉक्स बनाम टूल नीति बनाम उन्नत विशेषाधिकार

Status: active

OpenClaw में तीन संबंधित लेकिन अलग नियंत्रण हैं:

  1. सैंडबॉक्स (agents.defaults.sandbox.* / agents.entries.*.sandbox.*) तय करता है कि टूल कहाँ चलते हैं (सैंडबॉक्स बैकएंड बनाम होस्ट)।
  2. टूल नीति (tools.*, tools.sandbox.tools.*, agents.entries.*.tools.*) तय करती है कि कौन-से टूल उपलब्ध/अनुमत हैं
  3. उन्नत (tools.elevated.*, agents.entries.*.tools.elevated.*) सैंडबॉक्स में होने पर उसके बाहर चलाने के लिए केवल exec का निकास मार्ग है (डिफ़ॉल्ट रूप से gateway, या जब exec लक्ष्य को node पर कॉन्फ़िगर किया गया हो तब node)।

त्वरित डीबगिंग

यह देखने के लिए इंस्पेक्टर का उपयोग करें कि OpenClaw वास्तव में क्या कर रहा है:

bash
openclaw sandbox explainopenclaw sandbox explain --session agent:main:mainopenclaw sandbox explain --agent workopenclaw sandbox explain --json

यह ये जानकारी प्रिंट करता है:

  • प्रभावी सैंडबॉक्स मोड/दायरा/वर्कस्पेस पहुँच
  • क्या सत्र वर्तमान में सैंडबॉक्स में है (मुख्य बनाम गैर-मुख्य)
  • प्रभावी सैंडबॉक्स टूल अनुमति/अस्वीकृति (और यह एजेंट/वैश्विक/डिफ़ॉल्ट में से कहाँ से आई)
  • उन्नत गेट और सुधार हेतु कुंजी पथ

सैंडबॉक्स: टूल कहाँ चलते हैं

सैंडबॉक्सिंग को agents.defaults.sandbox.mode नियंत्रित करता है:

  • "off": सब कुछ होस्ट पर चलता है।
  • "non-main": केवल गैर-मुख्य सत्र सैंडबॉक्स में होते हैं (समूहों/चैनलों के लिए आम "आश्चर्य")।
  • "all": सब कुछ सैंडबॉक्स में होता है।

agents.defaults.sandbox.workspaceAccess नियंत्रित करता है कि सैंडबॉक्स क्या देख सकता है: "none", "ro", या "rw"

पूरी मैट्रिक्स (दायरा, वर्कस्पेस माउंट, इमेज) के लिए सैंडबॉक्सिंग देखें।

बाइंड माउंट (त्वरित सुरक्षा जाँच)

  • docker.binds सैंडबॉक्स फ़ाइल सिस्टम को भेद देता है: आप जो भी माउंट करते हैं, वह आपके निर्धारित मोड (:ro या :rw) के साथ कंटेनर के भीतर दिखाई देता है।
  • यदि आप मोड छोड़ देते हैं, तो डिफ़ॉल्ट पढ़ना-लिखना है; स्रोत/सीक्रेट के लिए :ro को प्राथमिकता दें।
  • scope: "shared" प्रति-एजेंट बाइंड को अनदेखा करता है (केवल वैश्विक बाइंड लागू होते हैं)।
  • OpenClaw बाइंड स्रोतों को दो बार सत्यापित करता है: पहले सामान्यीकृत स्रोत पथ पर, फिर सबसे गहरे मौजूदा पूर्वज के माध्यम से समाधान के बाद। सिमलिंक-पैरेंट निकास अवरुद्ध-पथ या अनुमत-रूट जाँच को बायपास नहीं करते।
  • अस्तित्वहीन अंतिम पथों की भी सुरक्षित रूप से जाँच की जाती है। यदि /workspace/alias-out/new-file किसी सिमलिंक वाले पैरेंट के माध्यम से किसी अवरुद्ध पथ या कॉन्फ़िगर किए गए अनुमत रूट से बाहर समाधान होता है, तो बाइंड अस्वीकार कर दिया जाता है।
  • /var/run/docker.sock को बाइंड करना प्रभावी रूप से होस्ट का नियंत्रण सैंडबॉक्स को सौंप देता है; ऐसा केवल जानबूझकर करें।
  • वर्कस्पेस पहुँच (workspaceAccess) बाइंड मोड से स्वतंत्र है।

कई होस्ट फ़ोल्डर, पहुँच मोड और बाहरी-स्रोत सुरक्षा की स्पष्ट सहमति वाले प्रति-एजेंट कॉन्फ़िगरेशन के लिए, एक एजेंट के लिए कई फ़ोल्डर देखें।

टूल नीति: कौन-से टूल मौजूद हैं/कॉल किए जा सकते हैं

दो परतें मायने रखती हैं:

  • टूल प्रोफ़ाइल: tools.profile और agents.entries.*.tools.profile (आधार अनुमति-सूची)
  • प्रदाता टूल प्रोफ़ाइल: tools.byProvider[provider].profile और agents.entries.*.tools.byProvider[provider].profile
  • वैश्विक/प्रति-एजेंट टूल नीति: tools.allow/tools.deny और agents.entries.*.tools.allow/agents.entries.*.tools.deny
  • प्रदाता टूल नीति: tools.byProvider[provider].allow/deny और agents.entries.*.tools.byProvider[provider].allow/deny
  • सैंडबॉक्स टूल नीति (केवल सैंडबॉक्स में होने पर लागू): tools.sandbox.tools.allow/tools.sandbox.tools.deny और agents.entries.*.tools.sandbox.tools.*

सामान्य नियम:

  • deny हमेशा प्रभावी होता है।
  • यदि allow खाली नहीं है, तो बाकी सब कुछ अवरुद्ध माना जाता है।
  • टूल नीति अंतिम रोक है: /exec अस्वीकृत exec टूल को ओवरराइड नहीं कर सकता।
  • टूल नीति टूल की उपलब्धता को नाम के अनुसार फ़िल्टर करती है; यह exec के भीतर होने वाले दुष्प्रभावों की जाँच नहीं करती। यदि exec अनुमत है, तो write, edit, या apply_patch को अस्वीकार करने से शेल कमांड केवल-पढ़ने योग्य नहीं हो जाते।
  • /exec केवल अधिकृत प्रेषकों के लिए सत्र के डिफ़ॉल्ट बदलता है; यह टूल पहुँच प्रदान नहीं करता।
  • प्रदाता टूल कुंजियाँ provider (जैसे google-antigravity) या provider/model (जैसे openai/gpt-5.4) में से किसी एक को स्वीकार करती हैं।
  • जब टूल नीति का कोई चरण टूल हटाता है या सैंडबॉक्स टूल नीति किसी कॉल को अवरुद्ध करती है, तब Gateway लॉग में agents/tool-policy ऑडिट प्रविष्टियाँ शामिल होती हैं। नियम लेबल, कॉन्फ़िगरेशन कुंजी और प्रभावित टूल नाम देखने के लिए openclaw logs का उपयोग करें।

टूल समूह (संक्षिप्त रूप)

टूल नीतियाँ (वैश्विक, एजेंट, सैंडबॉक्स) ऐसी group:* प्रविष्टियों का समर्थन करती हैं जो कई टूल में विस्तृत होती हैं:

json5
{  tools: {    sandbox: {      tools: {        allow: ["group:runtime", "group:fs", "group:sessions", "group:memory"],      },    },  },}

उपलब्ध समूह:

समूह टूल
group:runtime exec, process, code_execution (bash को exec के उपनाम के रूप में स्वीकार किया जाता है)
group:fs read, write, edit, apply_patch
group:sessions sessions, sessions_list, sessions_history, sessions_search, conversations_list, conversations_send, conversations_turn, sessions_send, sessions_spawn, sessions_yield, subagents, session_status, spawn_task, dismiss_task
group:memory memory_search, memory_get
group:web web_search, x_search, web_fetch
group:ui browser, screen, terminal, canvas, show_widget
group:automation heartbeat_respond, cron, gateway
group:messaging message
group:nodes nodes, computer
group:agents agents_list, get_goal, create_goal, update_goal, update_plan, ask_user, skill_workshop
group:media image, image_generate, music_generate, video_generate, tts
group:openclaw अधिकांश अंतर्निहित OpenClaw टूल (read/write/edit/apply_patch/exec/process फ़ाइल सिस्टम और रनटाइम मूल घटकों, canvas, और प्रदाता Plugin को छोड़कर)
group:plugins लोड किए गए सभी Plugin-स्वामित्व वाले टूल, जिनमें bundle-mcp के माध्यम से उपलब्ध कराए गए कॉन्फ़िगर किए गए MCP सर्वर शामिल हैं

केवल-पढ़ने योग्य एजेंटों के लिए, परिवर्तनीय फ़ाइल सिस्टम टूल के साथ-साथ group:runtime को भी अस्वीकार करें, जब तक कि सैंडबॉक्स फ़ाइल सिस्टम नीति या कोई अलग होस्ट सीमा केवल-पढ़ने योग्य प्रतिबंध लागू न करती हो।

सैंडबॉक्स किए गए MCP सर्वरों के लिए, सैंडबॉक्स टूल नीति दूसरा अनुमति गेट है। यदि mcp.servers कॉन्फ़िगर किया गया है, लेकिन सैंडबॉक्स किए गए चरणों में केवल अंतर्निहित टूल दिखाई देते हैं, तो bundle-mcp, group:plugins, या सर्वर-उपसर्ग वाला कोई MCP टूल नाम/ग्लोब, जैसे outlook__send_mail या outlook__*, को tools.sandbox.tools.alsoAllow में जोड़ें, फिर Gateway को पुनः आरंभ/रीलोड करें और टूल सूची दोबारा कैप्चर करें। सर्वर ग्लोब प्रदाता-सुरक्षित MCP सर्वर उपसर्ग का उपयोग करते हैं: गैर-[A-Za-z0-9_-] वर्ण - बन जाते हैं, जो नाम किसी अक्षर से शुरू नहीं होते उन्हें mcp- उपसर्ग मिलता है, और लंबे या डुप्लिकेट उपसर्ग काटे जा सकते हैं या उनमें प्रत्यय जोड़े जा सकते हैं।

openclaw doctor वर्तमान में mcp.servers में OpenClaw द्वारा प्रबंधित सर्वरों के लिए इस आकार की जाँच करता है। बंडल किए गए Plugin मैनिफ़ेस्ट या Claude .mcp.json से लोड किए गए MCP सर्वर उसी सैंडबॉक्स गेट का उपयोग करते हैं, लेकिन यह निदान अभी उन स्रोतों को सूचीबद्ध नहीं करता; यदि उनके टूल सैंडबॉक्स किए गए चरणों में गायब हो जाएँ, तो उन्हीं अनुमति-सूची प्रविष्टियों का उपयोग करें।

उन्नत: केवल exec के लिए "होस्ट पर चलाएँ"

उन्नत सुविधा अतिरिक्त टूल प्रदान नहीं करती; यह केवल exec को प्रभावित करती है।

  • यदि आप सैंडबॉक्स में हैं, तो /elevated on (या elevated: true के साथ exec) सैंडबॉक्स के बाहर चलता है (स्वीकृतियाँ फिर भी लागू हो सकती हैं)।
  • सत्र के लिए exec स्वीकृतियाँ छोड़ने हेतु /elevated full का उपयोग करें।
  • यदि आप पहले से सीधे चला रहे हैं, तो उन्नत सुविधा प्रभावी रूप से कुछ नहीं करती (फिर भी गेट द्वारा नियंत्रित रहती है)।
  • उन्नत सुविधा Skills-दायरे तक सीमित नहीं है और टूल अनुमति/अस्वीकृति को ओवरराइड नहीं करती।
  • उन्नत सुविधा host=auto से मनमाने क्रॉस-होस्ट ओवरराइड प्रदान नहीं करती; यह सामान्य exec लक्ष्य नियमों का पालन करती है और node को केवल तभी बनाए रखती है, जब कॉन्फ़िगर किया गया/सत्र लक्ष्य पहले से node हो।
  • /exec उन्नत सुविधा से अलग है। यह केवल अधिकृत प्रेषकों के लिए प्रति-सत्र exec डिफ़ॉल्ट समायोजित करता है।

गेट:

  • सक्षमता: tools.elevated.enabled (और वैकल्पिक रूप से agents.entries.*.tools.elevated.enabled)
  • प्रेषक अनुमति-सूचियाँ: tools.elevated.allowFrom.<provider> (और वैकल्पिक रूप से agents.entries.*.tools.elevated.allowFrom.<provider>)

उन्नत मोड देखें।

सामान्य "सैंडबॉक्स जेल" सुधार

"टूल X सैंडबॉक्स टूल नीति द्वारा अवरुद्ध है"

सुधार हेतु कुंजियाँ (कोई एक चुनें):

  • सैंडबॉक्स अक्षम करें: agents.defaults.sandbox.mode=off (या प्रति-एजेंट agents.entries.*.sandbox.mode=off)
  • सैंडबॉक्स के अंदर टूल को अनुमति दें:
    • इसे tools.sandbox.tools.deny से हटाएँ (या प्रति-एजेंट agents.entries.*.tools.sandbox.tools.deny)
    • या इसे tools.sandbox.tools.allow में जोड़ें (या प्रति-एजेंट अनुमति)
  • agents/tool-policy प्रविष्टि के लिए openclaw logs जाँचें। यह सैंडबॉक्स मोड और यह दर्ज करता है कि अनुमति या निषेध नियम ने टूल को अवरुद्ध किया था या नहीं।

"मुझे लगा कि यह मुख्य सत्र था, फिर यह सैंडबॉक्स में क्यों है?"

"non-main" मोड में, समूह/चैनल कुंजियाँ मुख्य नहीं होती हैं। मुख्य सत्र कुंजी (जिसे sandbox explain दिखाता है) का उपयोग करें या मोड को "off" में बदलें।

संबंधित

Was this useful?
On this page

On this page