अपडेट पर वापस जाएँ
New releaseJul 23, 2026

sandbox-runtime v0.0.67

एक हल्का सैंडबॉक्सिंग टूल जो OS स्तर पर मनमाने प्रक्रियाओं पर फाइलसिस्टम और नेटवर्क प्रतिबंध लागू करने के लिए है, बिना किसी कंटेनर की आवश्यकता के।

साझा करें

Anthropic सैंडबॉक्स रनटाइम (srt)

कंटेनर की आवश्यकता के बिना, OS स्तर पर मनमाने प्रोसेस पर फाइलसिस्टम और नेटवर्क प्रतिबंध लागू करने के लिए एक हल्का सैंडबॉक्सिंग टूल।

srt मूल OS सैंडबॉक्सिंग प्रिमिटिव्स (macOS पर sandbox-exec, Linux पर bubblewrap) और प्रॉक्सी-आधारित नेटवर्क फ़िल्टरिंग का उपयोग करता है। इसका उपयोग एजेंटों, स्थानीय MCP सर्वरों, bash कमांड और मनमाने प्रोसेस के व्यवहार को सैंडबॉक्स करने के लिए किया जा सकता है।

बीटा रिसर्च प्रीव्यू

सैंडबॉक्स रनटाइम Claude Code के लिए सुरक्षित AI एजेंट सक्षम करने हेतु विकसित एक रिसर्च प्रीव्यू है। इसे व्यापक इकोसिस्टम को अधिक सुरक्षित एजेंटिक सिस्टम बनाने में मदद करने के लिए एक प्रारंभिक ओपन सोर्स प्रीव्यू के रूप में उपलब्ध कराया जा रहा है। चूंकि यह एक प्रारंभिक रिसर्च प्रीव्यू है, API और कॉन्फ़िगरेशन प्रारूप विकसित हो सकते हैं। हम AI एजेंटों को डिफ़ॉल्ट रूप से अधिक सुरक्षित बनाने के लिए फीडबैक और योगदान का स्वागत करते हैं!

इंस्टॉलेशन```bash

npm install -g @anthropic-ai/sandbox-runtime

## मूल उपयोग```bash
# Network restrictions
$ srt "curl anthropic.com"
Running: curl anthropic.com
<html>...</html>  # Request succeeds

$ srt "curl example.com"
Running: curl example.com
Connection blocked by network allowlist  # Request blocked

# Filesystem restrictions
$ srt "cat README.md"
Running: cat README.md
# Anthropic Sandb...  # Current directory access allowed

$ srt "cat ~/.ssh/id_rsa"
Running: cat ~/.ssh/id_rsa
cat: /Users/ollie/.ssh/id_rsa: Operation not permitted  # Specific file blocked

अवलोकन

यह पैकेज एक स्टैंडअलोन सैंडबॉक्स कार्यान्वयन प्रदान करता है जिसे CLI टूल और लाइब्रेरी दोनों के रूप में उपयोग किया जा सकता है। इसे सामान्य डेवलपर उपयोग-मामलों के लिए तैयार secure-by-default दर्शन के साथ डिज़ाइन किया गया है: प्रक्रियाएँ न्यूनतम पहुँच के साथ शुरू होती हैं, और आप केवल उन्हीं छिद्रों को स्पष्ट रूप से खोलते हैं जिनकी आपको आवश्यकता होती है।

मुख्य क्षमताएँ:

  • नेटवर्क प्रतिबंध: नियंत्रित करें कि HTTP/HTTPS और अन्य प्रोटोकॉल के माध्यम से किन होस्ट/डोमेन तक पहुँचा जा सकता है
  • फाइलसिस्टम प्रतिबंध: नियंत्रित करें कि कौन सी फाइलें/निर्देशिकाएँ पढ़ी/लिखी जा सकती हैं
  • यूनिक्स सॉकेट प्रतिबंध: स्थानीय IPC सॉकेट्स तक पहुँच को नियंत्रित करें
  • उल्लंघन निगरानी: macOS पर, वास्तविक समय के अलर्ट के लिए सिस्टम के सैंडबॉक्स उल्लंघन लॉग स्टोर में टैप करें

उदाहरण उपयोग-मामला: MCP सर्वर को सैंडबॉक्स करना

एक प्रमुख उपयोग-मामला Model Context Protocol (MCP) सर्वर को सैंडबॉक्स करना है ताकि उनकी क्षमताओं को प्रतिबंधित किया जा सके। उदाहरण के लिए, फाइलसिस्टम MCP सर्वर को सैंडबॉक्स करने के लिए:

सैंडबॉक्सिंग के बिना (.mcp.json):```json { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem"] } } }

**सैंडबॉक्सिंग के साथ** (`.mcp.json`):```json
{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

फिर ~/.srt-settings.json में प्रतिबंध कॉन्फ़िगर करें:```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

अब MCP सर्वर को अस्वीकृत पथ पर लिखने से रोक दिया जाएगा:```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

यह कैसे काम करता है

सैंडबॉक्स OS-स्तरीय प्राइमिटिव का उपयोग करके प्रतिबंध लागू करता है जो पूरे प्रोसेस ट्री पर लागू होते हैं:

  • macOS: गतिशील रूप से उत्पन्न Seatbelt प्रोफाइल के साथ sandbox-exec का उपयोग करता है
  • Linux: नेटवर्क नेमस्पेस अलगाव के साथ कंटेनरीकरण के लिए bubblewrap का उपयोग करता है
  • Windows: सैंडबॉक्स किए गए प्रोसेस को एक समर्पित srt-sandbox स्थानीय उपयोगकर्ता खाते के अंतर्गत चलाता है, जिसमें उस खाते के SID पर आधारित Windows Filtering Platform ईग्रेस फेंस और कार्यशील ट्री पर प्रति-सत्र स्पष्ट ACE होते हैं

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

दोहरा अलगाव मॉडल

प्रभावी सैंडबॉक्सिंग के लिए फाइलसिस्टम और नेटवर्क दोनों का अलगाव आवश्यक है। फाइल अलगाव के बिना, एक समझौता किया गया प्रोसेस SSH कुंजियाँ या अन्य संवेदनशील फाइलें बाहर निकाल सकता है। नेटवर्क अलगाव के बिना, एक प्रोसेस सैंडबॉक्स से बचकर अप्रतिबंधित नेटवर्क एक्सेस प्राप्त कर सकता है।

फाइलसिस्टम अलगाव पढ़ने और लिखने के प्रतिबंध लागू करता है:

  • पढ़ना (पहले अस्वीकार-फिर-अनुमति पैटर्न): डिफ़ॉल्ट रूप से, पढ़ने की पहुंच हर जगह अनुमत है। आप व्यापक क्षेत्रों (जैसे, /Users) को अस्वीकार कर सकते हैं और फिर उनके भीतर विशिष्ट पथों (जैसे, .) को फिर से अनुमति दे सकते हैं। allowRead denyRead पर प्राथमिकता लेता है — लिखने के विपरीत, जहाँ denyWrite allowWrite पर प्राथमिकता लेता है। एक denyRead प्रविष्टि जो उस allowRead क्षेत्र से अधिक विशिष्ट है जिसके भीतर वह आती है (जैसे denyRead: ["**/.env"] या ["./secrets"] के साथ allowRead: ["."]) फिर भी अस्वीकृत रहती है।
  • लिखना (केवल-अनुमति पैटर्न): डिफ़ॉल्ट रूप से, लिखने की पहुंच हर जगह अस्वीकृत है। आपको स्पष्ट रूप से पथों (जैसे, ., /tmp) की अनुमति देनी होगी। एक खाली अनुमति सूची का मतलब कोई लिखने की पहुंच नहीं है।

नेटवर्क अलगाव (केवल-अनुमति पैटर्न): डिफ़ॉल्ट रूप से, सभी नेटवर्क एक्सेस अस्वीकृत है। आपको स्पष्ट रूप से डोमेन की अनुमति देनी होगी। एक खाली allowedDomains सूची का मतलब कोई नेटवर्क एक्सेस नहीं है। नेटवर्क ट्रैफ़िक होस्ट पर चलने वाले प्रॉक्सी सर्वरों के माध्यम से रूट किया जाता है:

  • Linux: अनुरोध फाइलसिस्टम के माध्यम से एक Unix डोमेन सॉकेट पर रूट किए जाते हैं। सैंडबॉक्स किए गए प्रोसेस का नेटवर्क नेमस्पेस पूरी तरह से हटा दिया जाता है, इसलिए सभी नेटवर्क ट्रैफ़िक को होस्ट पर चलने वाले प्रॉक्सी (Unix सॉकेट पर सुनने वाले जो सैंडबॉक्स में बाइंड-माउंट किए गए हैं) से गुजरना होगा

  • macOS: Seatbelt प्रोफाइल केवल एक विशिष्ट localhost पोर्ट के साथ संचार की अनुमति देता है। प्रॉक्सी इस पोर्ट पर सुनते हैं, जिससे सभी नेटवर्क एक्सेस के लिए एक नियंत्रित चैनल बनता है

  • Windows: एक मशीन-व्यापी WFP फ़िल्टर सेट srt-sandbox खाते से उत्पन्न सभी आउटबाउंड कनेक्शनों को ब्लॉक करता है, सिवाय प्रॉक्सी पोर्ट रेंज के लूपबैक के। प्रॉक्सी उस रेंज के भीतर सुनते हैं, जिससे सभी नेटवर्क एक्सेस के लिए एक नियंत्रित चैनल बनता है

HTTP/HTTPS (HTTP प्रॉक्सी के माध्यम से) और अन्य TCP ट्रैफ़िक (SOCKS5 प्रॉक्सी के माध्यम से) दोनों इन प्रॉक्सी द्वारा मध्यस्थ होते हैं, जो आपकी डोमेन अनुमति सूचियों और अस्वीकृति सूचियों को लागू करते हैं।

Claude Code में सैंडबॉक्सिंग के बारे में अधिक विवरण के लिए, देखें:

आर्किटेक्चर```

src/ ├── index.ts # Library exports ├── cli.ts # CLI entrypoint (srt command) ├── utils/ # Shared utilities │ ├── debug.ts # Debug logging │ ├── settings.ts # Settings reader (permissions + sandbox config) │ ├── platform.ts # Platform detection │ └── exec.ts # Command execution utilities └── sandbox/ # Sandbox implementation ├── sandbox-manager.ts # Main sandbox manager ├── sandbox-schemas.ts # Zod schemas for validation ├── sandbox-violation-store.ts # Violation tracking ├── sandbox-utils.ts # Shared sandbox utilities ├── http-proxy.ts # HTTP/HTTPS proxy for network filtering ├── socks-proxy.ts # SOCKS5 proxy for network filtering ├── linux-sandbox-utils.ts # Linux bubblewrap sandboxing ├── macos-sandbox-utils.ts # macOS sandbox-exec sandboxing └── windows-sandbox-utils.ts # Windows srt-win sandboxing

## उपयोग

### CLI टूल के रूप में

`srt` कमांड (Anthropic Sandbox Runtime) किसी भी कमांड को सुरक्षा सीमाओं के साथ लपेटता है:```bash
# Run a command in the sandbox
srt echo "hello world"

# With debug logging
srt --debug curl https://example.com

# Specify custom settings file
srt --settings /path/to/srt-settings.json npm install

एक लाइब्रेरी के रूप में```typescript

import { SandboxManager, type SandboxRuntimeConfig, } from '@anthropic-ai/sandbox-runtime' import { spawn } from 'child_process'

// Define your sandbox configuration const config: SandboxRuntimeConfig = { network: { allowedDomains: ['example.com', 'api.github.com'], deniedDomains: [], }, filesystem: { denyRead: ['~/.ssh'], allowWrite: ['.', '/tmp'], denyWrite: ['.env'], }, }

// Initialize the sandbox (starts proxy servers, etc.) await SandboxManager.initialize(config)

// Wrap a command with sandbox restrictions const sandboxedCommand = await SandboxManager.wrapWithSandbox( 'curl https://example.com', )

// Execute the sandboxed command const child = spawn(sandboxedCommand, { shell: true, stdio: 'inherit' })

// Handle exit and cleanup after child process completes child.on('exit', async code => { console.log(Command exited with code ${code}) // Cleanup when done (optional, happens automatically on process exit) await SandboxManager.reset() })

**उल्लंघन आरोपण (`commandId` / `commandText`).** जब कोई रैप किया गया कमांड चलता है (सीटबेल्ट लॉग लाइनें, सीकॉम्प इवेंट, प्रॉक्सी अस्वीकृतियाँ) तो देखे गए उल्लंघन एक आरोपण कुंजी के अंतर्गत संग्रहीत होते हैं, और `annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` उन्हें उसी कुंजी द्वारा खोजते हैं। डिफ़ॉल्ट रूप से कुंजी स्वयं रैप किया गया स्ट्रिंग होती है। इसके बजाय उससे कुंजी बनाने के लिए एक अपारदर्शी प्रति-आह्वान `commandId` (जैसे कि टूल-उपयोग आईडी) पास करें — अनुशंसित: कुंजियाँ अपने पहले 100 वर्णों पर तुलना करती हैं, इसलिए एक साझा उपसर्ग वाले लंबे कमांड अन्यथा क्रॉस-आरोपित हो जाएँगे, और उसी पाठ का पुनः चलाना पिछले रन की घटनाओं को विरासत में ले लेगा। यदि आप जो स्ट्रिंग *निष्पादित* करते हैं वह वह कमांड नहीं है जिसे आह्वान *दर्शाता* है (जैसे कि आप एक इकट्ठे `source <snapshot> && eval '<cmd>'` को रैप करते हैं), तो `commandText: '<cmd>'` भी पास करें: यह वही है जिससे `ignoreViolations` कमांड पैटर्न मेल खाते हैं और जिसे प्रत्येक उल्लंघन अपने `command` के रूप में रिपोर्ट करता है।```typescript
const wrapped = await SandboxManager.wrapWithSandbox(
  assembledCommand, // what actually runs
  undefined,
  undefined,
  undefined,
  { commandId: invocationId, commandText: rawCommand },
)
// ... run it ...
const annotated = SandboxManager.annotateStderrWithSandboxFailures(invocationId, stderr)

उपलब्ध निर्यात```typescript

// Main sandbox manager export { SandboxManager } from '@anthropic-ai/sandbox-runtime'

// Violation tracking export { SandboxViolationStore } from '@anthropic-ai/sandbox-runtime'

// TypeScript types export type { SandboxRuntimeConfig, NetworkConfig, FilesystemConfig, IgnoreViolationsConfig, SandboxAskCallback, FsReadRestrictionConfig, FsWriteRestrictionConfig, NetworkRestrictionConfig, } from '@anthropic-ai/sandbox-runtime'

## कॉन्फ़िगरेशन

### सेटिंग्स फ़ाइल का स्थान

डिफ़ॉल्ट रूप से, सैंडबॉक्स रनटाइम कॉन्फ़िगरेशन `~/.srt-settings.json` पर खोजता है। आप `--settings` फ़्लैग का उपयोग करके एक कस्टम पथ निर्दिष्ट कर सकते हैं:```bash
srt --settings /path/to/srt-settings.json <command>

पूर्ण कॉन्फ़िगरेशन उदाहरण```json

{ "network": { "allowedDomains": [ "github.com", ".github.com", "lfs.github.com", "api.github.com", "npmjs.org", ".npmjs.org" ], "deniedDomains": ["malicious.com"], "allowUnixSockets": ["/var/run/docker.sock"], "allowLocalBinding": false }, "filesystem": { "denyRead": ["~/.ssh"], "allowRead": [], "allowWrite": [".", "src/", "test/", "/tmp"], "denyWrite": [".env", "config/production.json"] }, "ignoreViolations": { "*": ["/usr/bin", "/System"], "git push": ["/usr/bin/nc"], "npm": ["/private/tmp"] }, "enableWeakerNestedSandbox": false, "enableWeakerNetworkIsolation": false, "allowAppleEvents": false }

### कॉन्फ़िगरेशन विकल्प

#### नेटवर्क कॉन्फ़िगरेशन

**केवल-अनुमति पैटर्न** का उपयोग करता है - डिफ़ॉल्ट रूप से सभी नेटवर्क एक्सेस अस्वीकृत है।

- `network.allowedDomains` - अनुमत डोमेन की सूची (वाइल्डकार्ड जैसे `*.example.com` का समर्थन करता है)। खाली सूची = कोई नेटवर्क एक्सेस नहीं। एक वैकल्पिक `:port` प्रत्यय (`api.example.com:443`, `*.example.com:8443`) किसी प्रविष्टि को उस गंतव्य पोर्ट तक सीमित करता है; बिना पोर्ट वाली प्रविष्टियाँ किसी भी पोर्ट से मेल खाती हैं।
  - IPv6 लिटरल को RFC 3986-शैली में ब्रैकेट में होना चाहिए: `[::1]`, `[2001:db8::1]:443`. बिना ब्रैकेट वाली बहु-कोलन प्रविष्टि अस्पष्ट होने के कारण अस्वीकृत कर दी जाती है (`2001:db8::1:443` स्वयं एक मान्य पता है)।
- `network.deniedDomains` - अस्वीकृत डोमेन की सूची (पहले जाँची जाती है, allowedDomains पर प्राथमिकता लेती है)। समान `:port` प्रत्यय, और सब-कुछ-अस्वीकार करने के लिए एक सादा `*` (या `*:22`) स्वीकार्य है।
- `network.deniedDomainReasons` - वैकल्पिक मैप जो `deniedDomains` प्रविष्टि (सटीक स्ट्रिंग द्वारा मिलान) से मॉडल-सामना करने वाले कारण तक जाता है, जो उस प्रविष्टि द्वारा कनेक्शन अस्वीकृत होने पर `<sandbox_violations>` पंक्ति में दिखाई देता है — बताएं कि क्या अवरुद्ध है और स्वीकृत विकल्प (जैसे `{"github.com:22": "SSH pushes to GitHub are blocked; use an https:// remote"}`)। बिना कारण वाली प्रविष्टियाँ एक सामान्य कारण रिपोर्ट करती हैं। SSH गंतव्यों (पोर्ट 22) के लिए, कारण इन-बैंड भी दिया जाता है: एक no-auth SOCKS ProxyCommand (जैसे BSD `nc -X 5`) के माध्यम से टनल किया गया SSH क्लाइंट एक pre-key-exchange SSH डिस्कनेक्ट प्राप्त करता है जिसका विवरण कारण होता है, जिसे OpenSSH शब्दशः प्रिंट करता है — ऐसे कारणों को ~400 ASCII वर्णों से कम, पहले अनिवार्य रखें, क्योंकि OpenSSH गैर-ASCII को छोटा और एस्केप करता है।
- `network.allowLocalBinding` - स्थानीय पोर्ट पर बाइंडिंग की अनुमति दें (बूलियन, डिफ़ॉल्ट: false)

**TLS समाप्ति** (`network.tlsTerminate`, प्रयोगात्मक): सेट होने पर, HTTPS CONNECTs को इन-प्रोसेस समाप्त किया जाता है ताकि SRT डिक्रिप्टेड अनुरोधों को देख (और `network.filterRequest` के माध्यम से फ़िल्टर) सके। सैंडबॉक्स किया गया प्रोसेस MITM CA (`caCertPath`/`caKeyPath`, या छोड़े जाने पर एक अस्थायी CA) के साथ-साथ होस्ट के नियमित रूट्स वाले ट्रस्ट बंडल की ओर इंगित किया जाता है, ताकि प्रॉक्सी-निर्मित प्रमाणपत्र और वास्तविक अपस्ट्रीम प्रमाणपत्र दोनों सत्यापित हों।

- `network.tlsTerminate.excludeDomains` - डोमेन पैटर्न (allowedDomains के समान सिंटैक्स) जो **समाप्त नहीं** होते। मेल खाने वाले CONNECTs को अपारदर्शी रूप से टनल किया जाता है: वे अभी भी डोमेन अनुमतिसूची के अधीन हैं, लेकिन सैंडबॉक्स के अंदर का क्लाइंट वास्तविक अपस्ट्रीम के साथ अपना स्वयं का TLS हैंडशेक पूरा करता है, और `filterRequest` / क्रेडेंशियल इंजेक्शन उनके HTTPS ट्रैफ़िक पर लागू नहीं होते। इसका उपयोग उन दो मामलों के लिए करें जिन्हें TLS समाप्ति मौलिक रूप से तोड़ती है:
  - **mTLS अपस्ट्रीम** - केवल सैंडबॉक्स के अंदर का क्लाइंट क्लाइंट प्रमाणपत्र रखता है, इसलिए प्रॉक्सी उसकी ओर से कनेक्शन को फिर से शुरू नहीं कर सकता।
  - **प्रमाणपत्र-पिनिंग क्लाइंट** - क्लाइंट जो अपस्ट्रीम की पहचान स्वयं सत्यापित करते हैं (कस्टम CAs, SAN पिनिंग) और MITM प्रमाणपत्र को अस्वीकार करते हैं।
- `network.tlsTerminate.extraCaCertPaths` - PEM CA प्रमाणपत्र फ़ाइलों के पथ जो उस ट्रस्ट बंडल में जोड़े जाते हैं, MITM CA और होस्ट के नियमित रूट्स के बाद। बहिष्कृत (गैर-समाप्त) होस्ट सैंडबॉक्स के अंदर क्लाइंट द्वारा सत्यापित किए जाते हैं, और SRT द्वारा सेट किए गए ट्रस्ट env वेरिएबल्स (`SSL_CERT_FILE`, `GIT_SSL_CAINFO`, ...) प्रत्येक टूल के स्वयं के ट्रस्ट कॉन्फ़िगरेशन को _प्रतिस्थापित_ करते हैं, इसलिए एक साइट-स्थानीय रूट (जैसे एक आंतरिक mTLS CA) बंडल में होना चाहिए या उन होस्ट को कभी सत्यापित नहीं किया जा सकता। प्रत्येक फ़ाइल के केवल `CERTIFICATE` ब्लॉक बंडल में कॉपी किए जाते हैं (कुछ और, जैसे संयुक्त PEM में एक निजी कुंजी, सैंडबॉक्स को कभी उजागर नहीं होती); जो फ़ाइलें गायब, अपठनीय, या कोई PEM `CERTIFICATE` ब्लॉक नहीं रखतीं, उन्हें छोड़ दिया जाता है, इसलिए केवल कुछ होस्ट पर मौजूद पथों को सूचीबद्ध करना सुरक्षित है।```json
{
  "network": {
    "allowedDomains": ["*.example.com", "internal-mtls.example.net"],
    "deniedDomains": [],
    "tlsTerminate": {
      "excludeDomains": ["internal-mtls.example.net"],
      "extraCaCertPaths": ["/etc/internal-mtls-roots.pem"]
    }
  }
}

यूनिक्स सॉकेट सेटिंग्स (प्लेटफ़ॉर्म-विशिष्ट व्यवहार):

सेटिंगmacOSLinux
allowUnixSockets: string[]सॉकेट पथों की अनुमति सूचीअनदेखा (seccomp पथ द्वारा फ़िल्टर नहीं कर सकता)
allowAllUnixSockets: booleanसभी सॉकेट की अनुमति देंseccomp ब्लॉकिंग अक्षम करें

यूनिक्स सॉकेट दोनों प्लेटफ़ॉर्म पर डिफ़ॉल्ट रूप से ब्लॉक होते हैं।

  • macOS: विशिष्ट पथों की अनुमति देने के लिए allowUnixSockets का उपयोग करें (जैसे, ["/var/run/docker.sock"]), या सभी की अनुमति देने के लिए allowAllUnixSockets: true।
  • Linux: ब्लॉकिंग seccomp फ़िल्टर (केवल x64/arm64) का उपयोग करती है। यदि seccomp उपलब्ध नहीं है, तो सॉकेट अप्रतिबंधित होते हैं और एक चेतावनी दिखाई जाती है। ब्लॉकिंग को स्पष्ट रूप से अक्षम करने के लिए allowAllUnixSockets: true का उपयोग करें।

फ़ाइलसिस्टम कॉन्फ़िगरेशन

दो अलग-अलग पैटर्न का उपयोग करता है:

पढ़ने के प्रतिबंध (पहले अस्वीकार-फिर-अनुमति पैटर्न) - डिफ़ॉल्ट रूप से सभी पढ़ने की अनुमति है:

  • filesystem.denyRead - पढ़ने की पहुंच अस्वीकार करने के लिए पथों की सरणी। खाली सरणी = पूर्ण पढ़ने की पहुंच।
  • filesystem.allowRead - अस्वीकृत क्षेत्रों के भीतर पढ़ने की पहुंच फिर से अनुमति देने के लिए पथों की सरणी (denyRead पर प्राथमिकता लेता है)। नोट: यह लिखने के विपरीत है, जहाँ denyWrite allowWrite पर प्राथमिकता लेता है।

लिखने के प्रतिबंध (केवल-अनुमति पैटर्न) - डिफ़ॉल्ट रूप से सभी लिखने की अनुमति अस्वीकार है:

  • filesystem.allowWrite - लिखने की पहुंच की अनुमति देने के लिए पथों की सरणी। खाली सरणी = कोई लिखने की पहुंच नहीं।
  • filesystem.denyWrite - अनुमत पथों के भीतर लिखने की पहुंच अस्वीकार करने के लिए पथों की सरणी (allowWrite पर प्राथमिकता लेता है)

पथ सिंटैक्स (macOS):

macOS पर पथ git-style glob पैटर्न का समर्थन करते हैं, जो .gitignore सिंटैक्स के समान है:

  • * - / को छोड़कर किसी भी वर्ण से मेल खाता है (जैसे, *.ts foo.ts से मेल खाता है लेकिन foo/bar.ts से नहीं)
  • ** - / सहित किसी भी वर्ण से मेल खाता है (जैसे, src/**/*.ts src/ में सभी .ts फ़ाइलों से मेल खाता है)
  • ? - / को छोड़कर किसी भी एक वर्ण से मेल खाता है (जैसे, file?.txt file1.txt से मेल खाता है)
  • [abc] - सेट में किसी भी वर्ण से मेल खाता है (जैसे, file[0-9].txt file3.txt से मेल खाता है)

उदाहरण:

  • "allowWrite": ["src/"] - पूरे src/ निर्देशिका में लिखने की अनुमति दें
  • "allowWrite": ["src/**/*.ts"] - src/ और उपनिर्देशिकाओं में सभी .ts फ़ाइलों में लिखने की अनुमति दें
  • "denyRead": ["~/.ssh"] - SSH निर्देशिका को पढ़ने से अस्वीकार करें
  • "denyRead": ["/Users"], "allowRead": ["."] - /Users के सभी को पढ़ने से अस्वीकार करें, लेकिन वर्तमान निर्देशिका को फिर से अनुमति दें
  • "denyWrite": [".env"] - .env फ़ाइल में लिखने से अस्वीकार करें (भले ही वर्तमान निर्देशिका अनुमत हो)

पथ सिंटैक्स (Linux):

Linux वर्तमान में glob मिलान का समर्थन नहीं करता है। केवल शाब्दिक पथों का उपयोग करें:

  • "allowWrite": ["src/"] - src/ निर्देशिका में लिखने की अनुमति दें
  • "denyRead": ["/home/user/.ssh"] - SSH निर्देशिका को पढ़ने से अस्वीकार करें
  • "denyRead": ["/home"], "allowRead": ["."] - /home के सभी को पढ़ने से अस्वीकार करें, लेकिन वर्तमान निर्देशिका को फिर से अनुमति दें

सभी प्लेटफ़ॉर्म:

  • पथ निरपेक्ष (जैसे, /home/user/.ssh) या वर्तमान कार्यशील निर्देशिका के सापेक्ष (जैसे, ./src) हो सकते हैं
  • ~ उपयोगकर्ता की होम निर्देशिका में विस्तारित होता है

अन्य कॉन्फ़िगरेशन

  • ignoreViolations - कमांड पैटर्न को पथों की सरणियों में मैप करने वाली वस्तु जहाँ उल्लंघनों को अनदेखा किया जाना चाहिए
  • enableWeakerNestedSandbox - Docker वातावरण के लिए कमज़ोर सैंडबॉक्स मोड सक्षम करें (बूलियन, डिफ़ॉल्ट: false)
  • enableWeakerNetworkIsolation - macOS सैंडबॉक्स में com.apple.trustd.agent तक पहुंच की अनुमति दें (बूलियन, डिफ़ॉल्ट: false)। यह Go प्रोग्राम (gh, gcloud, terraform, kubectl, आदि) के लिए आवश्यक है ताकि httpProxyPort के साथ MITM प्रॉक्सी और कस्टम CA का उपयोग करते समय TLS प्रमाणपत्र सत्यापित किए जा सकें। सुरक्षा चेतावनी: इसे सक्षम करने से trustd सेवा के माध्यम से डेटा बाहर निकालने का संभावित वेक्टर खुल जाता है।
  • allowAppleEvents - macOS सैंडबॉक्स से Apple Events और Launch Services खोलने के अनुरोध भेजने की अनुमति दें (बूलियन, डिफ़ॉल्ट: false)। इसके बिना, open, osascript, और AppleScript के माध्यम से URL या अन्य ऐप्स की स्क्रिप्ट खोलने वाली कोई भी चीज़ AppleScript त्रुटि -600 ("एप्लिकेशन नहीं चल रहा है") या LaunchServices त्रुटियों (-10822, -54) के साथ विफल हो जाती है। सुरक्षा चेतावनी: इसे सक्षम करने का मतलब है कि सैंडबॉक्स अब कोड-निष्पादन अलगाव प्रदान नहीं करता है। एक सैंडबॉक्स किया गया कमांड उपयोगकर्ता के संकेत के बिना open के माध्यम से अन्य एप्लिकेशन लॉन्च कर सकता है, और यह जो कुछ भी लॉन्च करता है वह सैंडबॉक्स की फ़ाइलसिस्टम और नेटवर्क प्रतिबंधों के बाहर चलता है; पहले से चल रहे ऐप्स को Apple Events के माध्यम से स्क्रिप्ट करना अतिरिक्त रूप से उपयोगकर्ता की प्रति-ऐप TCC स्वचालन सहमति द्वारा गेट किया जाता है। एम्बेडर्स को यह विकल्प केवल विश्वसनीय उपयोगकर्ता-स्तरीय कॉन्फ़िगरेशन से लेना चाहिए — कभी भी चेक-आउट किए गए रिपॉजिटरी में प्रोजेक्ट-स्थानीय फ़ाइलों से नहीं, जो एक हमलावर-निर्मित प्रोजेक्ट को अपने स्वयं के सैंडबॉक्स अनुमतियों को बढ़ाने की अनुमति देगा।

सामान्य कॉन्फ़िगरेशन रेसिपी

GitHub पहुंच की अनुमति दें (सभी आवश्यक एंडपॉइंट):```json { "network": { "allowedDomains": [ "github.com", "*.github.com", "lfs.github.com", "api.github.com" ], "deniedDomains": [] }, "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": [] } }

**विशिष्ट निर्देशिकाओं तक सीमित रखें:**```json
{
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh"],
    "allowWrite": [".", "src/", "test/"],
    "denyWrite": [".env", "secrets/"]
  }
}

केवल-वर्कस्पेस फ़ाइलसिस्टम एक्सेस (वर्कस्पेस के बाहर पढ़ने से इनकार करें):```json { "network": { "allowedDomains": [], "deniedDomains": [] }, "filesystem": { "denyRead": ["/Users"], "allowRead": ["."], "allowWrite": ["."], "denyWrite": [] } }

यह `/Users` (या Linux पर `/home`) के अंतर्गत कुछ भी पढ़ने से मना करता है, फिर वर्तमान कार्यशील निर्देशिका को फिर से अनुमति देता है। सिस्टम पथ (`/usr`, `/lib`, आदि) पठनीय बने रहते हैं।

### सामान्य समस्याएँ और सुझाव

**Jest चलाना:** सैंडबॉक्स उल्लंघनों से बचने के लिए `--no-watchman` फ्लैग का उपयोग करें:```bash
srt "jest --no-watchman"

Watchman सैंडबॉक्स सीमाओं के बाहर फ़ाइलों तक पहुँचता है, जिससे अनुमति संबंधी त्रुटियाँ उत्पन्न होंगी। इसे अक्षम करने से Jest अंतर्निहित फ़ाइल वॉचर के साथ चल सकता है।

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

  • macOS: कस्टम प्रोफ़ाइल के साथ sandbox-exec का उपयोग करता है (कोई अतिरिक्त निर्भरता नहीं)
  • Linux: कंटेनरीकरण के लिए bubblewrap (bwrap) का उपयोग करता है
  • Windows: अल्फ़ा — बंडल किए गए srt-win.exe सहायक का उपयोग करता है (कोई अतिरिक्त निर्भरता नहीं)। सेटअप, सुरक्षा मॉडल और ज्ञात सीमाओं के लिए Windows (अल्फ़ा) देखें

प्लेटफ़ॉर्म-विशिष्ट निर्भरताएँ

Linux को आवश्यकता है:

  • bubblewrap - कंटेनर रनटाइम
    • Ubuntu/Debian: apt-get install bubblewrap
    • Fedora: dnf install bubblewrap
    • Arch: pacman -S bubblewrap
  • socat - प्रॉक्सी ब्रिजिंग के लिए सॉकेट रिले
    • Ubuntu/Debian: apt-get install socat
    • Fedora: dnf install socat
    • Arch: pacman -S socat
  • ripgrep - अस्वीकृत पथ का पता लगाने के लिए तेज़ खोज उपकरण
    • Ubuntu/Debian: apt-get install ripgrep
    • Fedora: dnf install ripgrep
    • Arch: pacman -S ripgrep

Ubuntu 24.04+ नोट: ये रिलीज़ डिफ़ॉल्ट रूप से kernel.apparmor_restrict_unprivileged_userns सक्षम करती हैं, जो unshare(CLONE_NEWUSER) की अनुमति देता है लेकिन परिणामी नेमस्पेस से क्षमताएँ हटा देता है। bubblewrap और seccomp आइसोलेशन परत दोनों को क्षमता-युक्त यूज़र नेमस्पेस की आवश्यकता होती है। प्रतिबंध को अक्षम करें:```bash sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

या एक AppArmor प्रोफ़ाइल जोड़ें जो प्रासंगिक बाइनरीज़ को `userns` अनुदान देती है।

**वैकल्पिक Linux निर्भरताएँ (seccomp फ़ॉलबैक के लिए):**

पैकेज में x86-64 और arm आर्किटेक्चर के लिए पहले से जनरेट किए गए seccomp BPF फ़िल्टर शामिल हैं। ये निर्भरताएँ केवल तभी आवश्यक हैं जब आप किसी भिन्न आर्किटेक्चर पर हों जहाँ पहले से जनरेट किए गए फ़िल्टर उपलब्ध नहीं हैं:

- `gcc` या `clang` - C कंपाइलर
- `libseccomp-dev` - Seccomp लाइब्रेरी विकास फ़ाइलें
  - Ubuntu/Debian: `apt-get install gcc libseccomp-dev`
  - Fedora: `dnf install gcc libseccomp-devel`
  - Arch: `pacman -S gcc libseccomp`

**macOS के लिए आवश्यक:**

- `ripgrep` - अस्वीकृत पथ का पता लगाने के लिए तेज़ खोज उपकरण
  - Homebrew के माध्यम से इंस्टॉल करें: `brew install ripgrep`
  - या यहाँ से डाउनलोड करें: https://github.com/BurntSushi/ripgrep/releases

**Windows के लिए आवश्यक:**

- कोई अतिरिक्त निर्भरता नहीं। `srt-win.exe` हेल्पर (x64 और arm64) npm पैकेज के साथ बंडल किया गया है। एक बार का उन्नत `windows-install` चरण आवश्यक है — नीचे देखें।

## Windows (alpha)

Windows समर्थन **alpha** है। सैंडबॉक्स किया गया प्रोसेस एक समर्पित `srt-sandbox` स्थानीय उपयोगकर्ता खाते के अंतर्गत चलता है, जो मूल Windows सुरक्षा प्रिमिटिव्स द्वारा कॉल करने वाले उपयोगकर्ता से अलग किया जाता है — एक Windows Filtering Platform (WFP) ईग्रेस फ़ेंस जो सैंडबॉक्स खाते के SID पर कुंजीबद्ध है, और प्रति-सत्र स्पष्ट ACEs जो कॉन्फ़िगर किए गए फ़ाइलसिस्टम पथों तक उस SID की पहुँच को अनुदान या अस्वीकार करते हैं।

### सेटअप

प्रति मशीन एक बार चलाएँ (स्वयं-उन्नत होता है; एक UAC प्रॉम्प्ट):```powershell
npx @anthropic-ai/sandbox-runtime windows-install

This provisions the srt-sandbox local user account (with a random password stored DPAPI-encrypted in HKLM\SOFTWARE\sandbox-runtime — machine-wide, so fleet installs running as SYSTEM work and one user's rotation updates the copy the others read), the sandbox-runtime-users local group, and installs a machine-wide WFP filter set keyed on the srt-sandbox SID. It is idempotent — re-running it rotates the sandbox account's password and reconciles the filter set.

कोई लॉगआउट आवश्यक नहीं है। WFP फ़िल्टर समर्पित सैंडबॉक्स खाते के SID पर कुंजीबद्ध होते हैं, इसलिए आपका अपना नेटवर्क, सेवाएँ, और मशीन पर हर अन्य प्रिंसिपल अप्रभावित रहते हैं।

इंस्टॉल के बाद, SandboxManager.initialize() और srt CLI अन्य प्लेटफ़ॉर्म की तरह काम करते हैं। initialize() सत्यापित करता है कि सैंडबॉक्स खाता और WFP फेंस सक्रिय हैं, और यदि नहीं हैं तो एक कार्रवाई योग्य त्रुटि के साथ विफल हो जाता है।

प्रोग्रामेटिक इंस्टॉल/अनइंस्टॉल को installWindowsSandbox() / uninstallWindowsSandbox() के रूप में निर्यात किया जाता है।

सुरक्षा मॉडल

सैंडबॉक्स किया गया कमांड srt-sandbox खाते के रूप में चलता है, न कि कॉल करने वाले उपयोगकर्ता के रूप में। बंडल किया गया srt-win.exe हेल्पर दो-हॉप लॉन्च करता है: ब्रोकर CreateProcessWithLogonW को कॉल करके एक रनर को srt-sandbox के रूप में शुरू करता है, और रनर लक्ष्य को एक जॉब ऑब्जेक्ट के अंदर एक प्रतिबंधित टोकन के तहत स्पॉन करता है। चाइल्ड सैंडबॉक्स खाते की पृथक प्रोफ़ाइल (%USERPROFILE%, %TEMP%, HKCU) और एक नया वातावरण प्राप्त करता है जो केवल ब्रोकर के PATH और उत्पन्न प्रॉक्सी वेरिएबल्स के साथ ओवरले किया गया है।

एक अलग उपयोगकर्ता SID के तहत चलना संरचनात्मक रूप से सरोगेट-स्पॉन वर्ग के एस्केप को बंद करता है (टास्क शेड्यूलर, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS एक ब्रोकर-स्वामित्व वाली प्रक्रिया पर, BITS, RunAs="Interactive User" के साथ आउट-ऑफ-प्रोसेस COM): कोई भी प्रक्रिया जिसे चाइल्ड ऑफ-बैंड स्पॉन करने में सफल होता है, वह अभी भी srt-sandbox SID रखती है, इसलिए यह WFP ईग्रेस फेंस के अधीन रहती है और कॉल करने वाले उपयोगकर्ता की फ़ाइलों पर कोई अधिकार नहीं रखती है।

नेटवर्क अलगाव FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6 पर एक दो-फ़िल्टर WFP सेट है: कॉन्फ़िगर किए गए प्रॉक्सी पोर्ट रेंज (डिफ़ॉल्ट 60080–60089) के अंदर लूपबैक गंतव्यों के लिए एक PERMIT, और किसी भी कनेक्ट के लिए एक BLOCK जिसका टोकन srt-sandbox SID रखता है। सैंडबॉक्स की गई प्रक्रिया इंटरनेट तक केवल उस रेंज में सुनने वाले JS HTTP/SOCKS5 प्रॉक्सी के माध्यम से पहुँचती है; एक प्रक्रिया जो अपने प्रॉक्सी वातावरण को हटा देती है और सीधे कनेक्ट करती है, कर्नेल पर ब्लॉक हो जाती है।

फ़ाइलसिस्टम अलगाव NTFS विवेकाधीन ACL द्वारा लागू किया जाता है। srt-sandbox खाते के पास कॉल करने वाले उपयोगकर्ता की फ़ाइलों पर कोई अंतर्निहित अधिकार नहीं है, इसलिए initialize() पर सैंडबॉक्स केवल srt-sandbox SID के लिए योगात्मक, विरासत में मिलने वाले स्पष्ट ACE लिखता है — यह किसी पथ के मौजूदा सुरक्षा विवरणक को कभी फिर से नहीं लिखता या प्रतिस्थापित नहीं करता:

  • filesystem.allowWrite → एक विरासत में मिलने वाला MODIFY ALLOW ACE (READ|WRITE|EXECUTE|DELETE, जिसमें FILE_DELETE_CHILD रोका गया है)। सैंडबॉक्स की गई प्रक्रिया वर्किंग ट्री के अंदर फ़ाइलें बना, संशोधित और हटा सकती है; अनुदान से FILE_DELETE_CHILD को रोकना नीचे दिए गए डेनी स्टैम्प के लिए डिफेंस-इन-डेप्थ है, न कि ट्री रूट पर एक गार्ड।
  • filesystem.allowRead → एक विरासत में मिलने वाला READ|EXECUTE ALLOW ACE
  • filesystem.denyRead / filesystem.denyWrite → लक्ष्य पर एक विरासत में मिलने वाला DENY ACE, साथ ही उसके पैरेंट पर एक विरासत में मिलने वाला FILE_DELETE_CHILD DENY — वर्किंग-ट्री अनुदान पर रोके गए FILE_DELETE_CHILD के साथ मिलकर, यह सैंडबॉक्स की गई प्रक्रिया को अपने पैरेंट डायरेक्टरी के माध्यम से किसी अस्वीकृत पथ का नाम बदलने या हटाने से रोकता है

reset() इस सत्र द्वारा जोड़े गए हर ACE को हटा देता है (प्रति-उपयोगकर्ता सत्र DB के माध्यम से इस उपयोगकर्ता के समवर्ती होस्टों में रेफ़काउंटेड; अगले initialize() पर एक क्रैश-रिकवरी पास अस्वच्छ निकास के बाद सफाई करता है)। डायरेक्टरी लक्ष्य समर्थित हैं (ACE पूरे सबट्री में विरासत में मिलते हैं)। ग्लोब पैटर्न को initialize() समय पर ठोस पथों में विस्तारित किया जाता है — एक मिलान पथ जो बाद में दिखाई देता है, कवर नहीं होता।

Windows पर TLS समाप्ति

network.tlsTerminate के लिए MITM CA को सैंडबॉक्स उपयोगकर्ता के CurrentUser\Root प्रमाणपत्र स्टोर में मौजूद होना आवश्यक है (schannel — System32\curl.exe, PowerShell Invoke-WebRequest, .NET, और डिफ़ॉल्ट-बैकएंड git द्वारा उपयोग किया जाने वाला TLS बैकएंड — केवल OS स्टोर पर भरोसा करता है, पर्यावरण वेरिएबल्स पर नहीं)। यह एक इंस्टॉल-समय चरण है, जो windows-install से अलग है:```typescript import { windowsTrustCa } from '@anthropic-ai/sandbox-runtime' windowsTrustCa('/path/to/mitm-ca.crt') // or: srt-win user trust-ca 

`initialize()` सत्र CA के थंबप्रिंट की तुलना इंस्टॉल किए गए CA से करता है और बेमेल होने पर एक कार्रवाई योग्य संदेश के साथ विफल हो जाता है, ताकि इंस्टॉल-समय का पुराना CA सैंडबॉक्स के अंदर TLS को चुपचाप तोड़ न सके।

OpenSSL-आधारित क्लाइंट (msys2 `curl`, `git -c http.sslBackend=openssl`, Node, Python, cargo) env-var ट्रस्ट लेयर द्वारा कवर किए जाते हैं: macOS/Linux पर उपयोग किया जाने वाला वही ट्रस्ट बंडल `NODE_EXTRA_CA_CERTS`, `SSL_CERT_FILE`, `CURL_CA_BUNDLE`, `GIT_SSL_CAINFO`, `CARGO_HTTP_CAINFO`, आदि के माध्यम से सैंडबॉक्स में पास किया जाता है, और बंडल पथ को सत्र के `allowRead` अनुदान में जोड़ा जाता है ताकि सैंडबॉक्स खाता इसे खोल सके।

### Windows-विशिष्ट कॉन्फ़िगरेशन

क्रॉस-प्लेटफ़ॉर्म `filesystem` और `network` ब्लॉक ऊपर वर्णित अनुसार लागू होते हैं। Windows-केवल सेटिंग्स `windows` के अंतर्गत आती हैं:

- `windows.proxyPortRange` — `[low, high]` समावेशी पोर्ट रेंज जिसके भीतर JS प्रॉक्सी बाइंड होते हैं। **उस रेंज से मेल खाना चाहिए** जो `windows-install --proxy-port-range` (डिफ़ॉल्ट `[60080, 60089]`) को दी गई है — WFP लूपबैक PERMIT केवल उस रेंज को कवर करता है।
- `windows.sublayerGuid` — WFP सबलेयर GUID जिसके अंतर्गत फ़िल्टर इंस्टॉल किए गए थे। कंपाइल-टाइम डिफ़ॉल्ट का उपयोग करने के लिए इसे छोड़ दें; केवल तभी सेट करें जब एंटरप्राइज़ टूलिंग ने फ़िल्टर को कस्टम सबलेयर के अंतर्गत इंस्टॉल किया हो।
- `windows.srtWin.path` — `srt-win` बाइनरी का पथ। पैकेज किए गए `vendor/srt-win/<arch>/srt-win.exe` को हल करने के लिए इसे छोड़ दें। `srt-win` के CLI को मल्टीकॉल बाइनरी में एम्बेड करते समय सेट करें; स्पॉन तब `--srt-win` को `argv[1]` के रूप में पास करते हैं ताकि एम्बेडर का डिस्पैचर `srt_win::run_from_args` पर रूट कर सके।

### ज्ञात सीमाएँ

- **schannel के अंतर्गत प्रमाणपत्र निरस्तीकरण।** CryptoAPI का CRL/OCSP फ़ेच कॉलर के टोकन के अंतर्गत WinHTTP के माध्यम से जाता है, प्रॉक्सी पर्यावरण को अनदेखा करते हुए, इसलिए यह WFP ईग्रेस फेंस द्वारा अवरुद्ध होता है। जो टूल्स डिफ़ॉल्ट रूप से रिवोकेशन जाँच के साथ schannel का उपयोग करते हैं, वे `CRYPT_E_REVOCATION_OFFLINE` (`0x80092013`) के साथ विफल होते हैं, जब तक कि रिवोकेशन प्रति टूल अक्षम न किया जाए: `curl --ssl-no-revoke`, `git -c http.schannelCheckRevoke=false`, `CARGO_HTTP_CHECK_REVOKE=false`। `Invoke-WebRequest`, .NET `HttpClient`, और `gh` डिफ़ॉल्ट रूप से रिवोकेशन की जाँच नहीं करते और प्रभावित नहीं होते। लूपबैक प्रॉक्सी से परोसा गया CRL वितरण बिंदु इस वर्कअराउंड को हटाने के लिए योजनाबद्ध है।
- **प्रति-उपयोगकर्ता टूल इंस्टॉल पहुंच योग्य नहीं हैं।** सैंडबॉक्स किया गया प्रोसेस `srt-sandbox` के रूप में चलता है, आपके रूप में नहीं, इसलिए आपके प्रोफ़ाइल के अंतर्गत इंस्टॉल किए गए टूल (nvm/fnm-प्रबंधित Node, प्रति-उपयोगकर्ता `winget`/Scoop पैकेज, `pip install --user`, `%LOCALAPPDATA%\Programs\…`) विरासत में मिले `PATH` पर हल होते हैं लेकिन सैंडबॉक्स खाते द्वारा नहीं खोले जा सकते। मशीन-व्यापी इंस्टॉल (`Program Files`, `choco`/`winget --scope machine`) पसंद करें, या विशिष्ट प्रोफ़ाइल पथों को `filesystem.allowRead` में जोड़ें।
- **प्रति-निष्पादन `filesystem.allowRead` / `filesystem.allowWrite` ओवरराइड समर्थित नहीं हैं।** सत्र-स्तरीय `allowRead`/`allowWrite` (`initialize()` को दिए गए कॉन्फ़िग में) ऊपर वर्णित अनुसार काम करते हैं; उन्हें `wrapWithSandbox` के `customConfig` में प्रति-कमांड पास करना फेंकता है — अनुदान `initialize()` पर `srt-win acl grant` के माध्यम से सत्र-व्यापी रूप से लागू होते हैं, और `srt-win exec` केवल प्रति-निष्पादन अस्वीकृतियों को उजागर करता है।
- **`proxyAuthToken` रनर की कमांड लाइन में दिखाई देता है।** प्रॉक्सी पर्यावरण (`HTTP_PROXY=http://srt:<token>@127.0.0.1:…` सहित) को दो-हॉप रनर को `srt-win exec` के argv पर `--env` तर्कों के रूप में पास किया जाता है, इसलिए टोकन किसी भी स्थानीय प्रिंसिपल द्वारा पठनीय है जो `PROCESS_QUERY_LIMITED_INFORMATION` के लिए रनर प्रोसेस को खोल सकता है। टोकन इसलिए मौजूद है ताकि सैंडबॉक्स किया गया प्रोसेस लूपबैक प्रॉक्सी को प्रमाणित कर सके, इसलिए यह सैंडबॉक्स से ही एक रहस्य नहीं है; एकल-उपयोगकर्ता विकास मशीन पर यह आम तौर पर स्वीकार्य है, लेकिन साझा होस्ट पर प्रॉक्सी अनुमतिसूची को अन्य समान-सत्र प्रिंसिपलों द्वारा पहुंच योग्य मानें।
- **सिस्टम रिज़ॉल्वर के माध्यम से DNS रिज़ॉल्यूशन फेंस नहीं किया गया है।** `getaddrinfo()` को `NETWORK SERVICE` के रूप में चल रही `Dnscache` सेवा द्वारा सेवा दी जाती है, इसलिए नाम रिज़ॉल्यूशन सफल होता है, भले ही सैंडबॉक्स किए गए प्रोसेस से बाद का `connect()` अवरुद्ध हो। जो टूल्स अपना स्वयं का UDP/53 (`nslookup`, `dig`) करते हैं, वे फेंस किए जाते हैं। यह macOS व्यवहार को दर्शाता है।

### अनइंस्टॉल```powershell
npx @anthropic-ai/sandbox-runtime windows-uninstall

WFP फ़िल्टर सेट, srt-sandbox खाता और उसकी प्रोफ़ाइल, sandbox-runtime-users समूह को हटाता है, और HKLM\SOFTWARE\sandbox-runtime कुंजी (क्रेडेंशियल, मार्कर, CA रिकॉर्ड) को हटाता है — एक UAC प्रॉम्प्ट। %ProgramData%\sandbox-runtime (CA कुंजी सामग्री) को यथावत छोड़ दिया जाता है; पूर्ण सफाई के लिए इसे (और प्रति उपयोगकर्ता %LOCALAPPDATA%\sandbox-runtime) मैन्युअल रूप से हटाएँ।

विकास```bash

Install dependencies

npm install

Build the project

npm run build

Run tests

npm test

Type checking

npm run typecheck

Lint code

npm run lint

Format code

npm run format

### Seccomp बाइनरी बनाना

BPF फ़िल्टर और `apply-seccomp` लोडर को `vendor/seccomp-src/` में C सोर्स से `npm run build:seccomp` के माध्यम से संकलित किया जाता है (केवल Linux; `gcc` और `libseccomp-dev` की आवश्यकता है)। CI इसे प्रत्येक Linux आर्किटेक्चर पर परीक्षणों से पहले चलाता है, और रिलीज़ वर्कफ़्लो दोनों आर्किटेक्चर बनाता है और उन्हें प्रकाशित पैकेज में बंडल करता है।

## कार्यान्वयन विवरण

### नेटवर्क आइसोलेशन आर्किटेक्चर

सैंडबॉक्स होस्ट मशीन पर HTTP और SOCKS5 प्रॉक्सी सर्वर चलाता है जो अनुमति नियमों के आधार पर सभी नेटवर्क अनुरोधों को फ़िल्टर करते हैं:

1. **HTTP/HTTPS ट्रैफ़िक**: एक HTTP प्रॉक्सी सर्वर अनुरोधों को इंटरसेप्ट करता है और उन्हें अनुमत/अस्वीकृत डोमेन के विरुद्ध मान्य करता है
2. **अन्य नेटवर्क ट्रैफ़िक**: एक SOCKS5 प्रॉक्सी अन्य सभी TCP कनेक्शनों को संभालता है (SSH, डेटाबेस कनेक्शन, आदि)
3. **अनुमति प्रवर्तन**: प्रॉक्सी आपके कॉन्फ़िगरेशन से `permissions` नियमों को लागू करते हैं

**प्लेटफ़ॉर्म-विशिष्ट प्रॉक्सी संचार:**

- **Linux**: अनुरोधों को Unix डोमेन सॉकेट्स पर फ़ाइलसिस्टम के माध्यम से रूट किया जाता है (ब्रिजिंग के लिए `socat` का उपयोग करके)। नेटवर्क नेमस्पेस को bubblewrap कंटेनर से हटा दिया जाता है, यह सुनिश्चित करते हुए कि सभी नेटवर्क ट्रैफ़िक को प्रॉक्सी से गुज़रना होगा।

- **macOS**: Seatbelt प्रोफ़ाइल केवल विशिष्ट localhost पोर्ट्स पर संचार की अनुमति देती है जहाँ प्रॉक्सी सुनते हैं। अन्य सभी नेटवर्क एक्सेस अवरुद्ध है।

- **Windows**: एक WFP `ALE_AUTH_CONNECT` फ़िल्टर `srt-sandbox` खाते से हर आउटबाउंड कनेक्ट को ब्लॉक करता है, सिवाय कॉन्फ़िगर किए गए प्रॉक्सी पोर्ट रेंज में लूपबैक के। प्रॉक्सी उस रेंज के भीतर बाइंड होते हैं। पर्यावरण चर (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, …) टूल्स को प्रॉक्सी की ओर इंगित करते हैं, लेकिन WFP फ़िल्टर सीमा है — एक प्रक्रिया जो उन्हें अनदेखा या अनसेट करती है, फिर भी बाड़े में रहती है।

### फ़ाइलसिस्टम आइसोलेशन

फ़ाइलसिस्टम प्रतिबंध OS स्तर पर लागू किए जाते हैं:

- **macOS**: गतिशील रूप से उत्पन्न Seatbelt प्रोफ़ाइल्स के साथ `sandbox-exec` का उपयोग करता है जो अनुमत पढ़ने/लिखने के पथ निर्दिष्ट करते हैं
- **Linux**: बाइंड माउंट्स के साथ `bubblewrap` का उपयोग करता है, कॉन्फ़िगरेशन के आधार पर निर्देशिकाओं को केवल-पढ़ने या पढ़ने-लिखने के रूप में चिह्नित करता है
- **Windows**: कॉन्फ़िगर किए गए पथों पर `srt-sandbox` SID के लिए योगात्मक `(OI)(CI)` स्पष्ट ACEs लिखता है (`allowRead`/`allowWrite` पर ALLOW, `denyRead`/`denyWrite` पर DENY), फिर उन्हें `reset()` पर हटा देता है

**डिफ़ॉल्ट फ़ाइलसिस्टम अनुमतियाँ:**

- **पढ़ना** (पहले अस्वीकार, फिर अनुमति): डिफ़ॉल्ट रूप से हर जगह अनुमत। आप व्यापक क्षेत्रों को अस्वीकार कर सकते हैं, फिर उनके भीतर विशिष्ट पथों को फिर से अनुमति दे सकते हैं। `allowRead` `denyRead` पर प्राथमिकता लेता है।

  - उदाहरण: SSH कुंजियों तक पहुँच को ब्लॉक करने के लिए `denyRead: ["~/.ssh"]`
  - उदाहरण: वर्कस्पेस को छोड़कर `/Users` के सभी को ब्लॉक करने के लिए `denyRead: ["/Users"], allowRead: ["."]`
  - खाली `denyRead: []` = पूर्ण पढ़ने की पहुँच (कुछ भी अस्वीकृत नहीं)

- **लिखना** (केवल-अनुमति): डिफ़ॉल्ट रूप से हर जगह अस्वीकृत। आपको स्पष्ट रूप से पथों की अनुमति देनी होगी।
  - उदाहरण: वर्तमान निर्देशिका और /tmp में लिखने की अनुमति देने के लिए `allowWrite: [".", "/tmp"]`
  - खाली `allowWrite: []` = कोई लिखने की पहुँच नहीं (कुछ भी अनुमत नहीं)
  - `denyWrite` अनुमत पथों के भीतर अपवाद बनाता है (अस्वीकार प्राथमिकता लेता है)

**प्राथमिकता पढ़ने बनाम लिखने के लिए जानबूझकर विपरीत है:** `allowRead` `denyRead` को ओवरराइड करता है, जबकि `denyWrite` `allowWrite` को ओवरराइड करता है। यह आपको अस्वीकृत क्षेत्रों के भीतर पठनीय क्षेत्रों को तराशने और लिखने योग्य क्षेत्रों के भीतर संरक्षित क्षेत्रों को तराशने की अनुमति देता है।

### अनिवार्य अस्वीकृत पथ (स्वतः-संरक्षित फ़ाइलें)

कुछ संवेदनशील फ़ाइलें और निर्देशिकाएँ **हमेशा लिखने से अवरुद्ध** होती हैं, भले ही वे अनुमत लिखने के पथ के भीतर आती हों। यह सैंडबॉक्स एस्केप और कॉन्फ़िगरेशन छेड़छाड़ के खिलाफ गहराई में सुरक्षा प्रदान करता है।

**हमेशा-अवरुद्ध फ़ाइलें:**

- शेल कॉन्फ़िग फ़ाइलें: `.bashrc`, `.bash_profile`, `.zshrc`, `.zprofile`, `.profile`
- Git कॉन्फ़िग फ़ाइलें: `.gitconfig`, `.gitmodules`
- अन्य संवेदनशील फ़ाइलें: `.ripgreprc`, `.mcp.json`

**हमेशा-अवरुद्ध निर्देशिकाएँ:**

- IDE निर्देशिकाएँ: `.vscode/`, `.idea/`
- Claude कॉन्फ़िग निर्देशिकाएँ: `.claude/commands/`, `.claude/agents/`
- Git हुक्स और कॉन्फ़िग: `.git/hooks/`, `.git/config`

ये पथ स्वचालित रूप से अवरुद्ध हैं - आपको उन्हें `denyWrite` में जोड़ने की आवश्यकता नहीं है। उदाहरण के लिए, `allowWrite: ["."]` के साथ भी, `.bashrc` या `.git/hooks/pre-commit` में लिखना विफल हो जाएगा:```bash
$ srt 'echo "malicious" >> .bashrc'
/bin/bash: .bashrc: Operation not permitted

$ srt 'echo "bad" > .git/hooks/pre-commit'
/bin/bash: .git/hooks/pre-commit: Operation not permitted

नोट (Linux): Linux पर, अनिवार्य अस्वीकार पथ केवल उन फ़ाइलों को ब्लॉक करते हैं जो पहले से मौजूद हैं। इन पैटर्न में गैर-मौजूद फ़ाइलों को bubblewrap की bind-mount विधि द्वारा ब्लॉक नहीं किया जा सकता। macOS glob पैटर्न का उपयोग करता है जो मौजूदा और नई दोनों फ़ाइलों को ब्लॉक करते हैं।

Linux खोज गहराई: Linux पर, सैंडबॉक्स अनुमत लेखन पथों के भीतर उपनिर्देशिकाओं में खतरनाक फ़ाइलों को स्कैन करने के लिए ripgrep का उपयोग करता है। डिफ़ॉल्ट रूप से, यह प्रदर्शन के लिए 3 स्तरों तक गहराई से खोज करता है। आप इसे mandatoryDenySearchDepth के साथ कॉन्फ़िगर कर सकते हैं:```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- डिफ़ॉल्ट: `3` (3 स्तरों तक गहराई में खोज करता है)
- सीमा: `1` से `10`
- उच्च मान अधिक सुरक्षा प्रदान करते हैं लेकिन प्रदर्शन धीमा करते हैं
- CWD (गहराई 0) में फ़ाइलें इस सेटिंग की परवाह किए बिना हमेशा सुरक्षित रहती हैं

### यूनिक्स सॉकेट प्रतिबंध (Linux)

Linux पर, सैंडबॉक्स syscall स्तर पर यूनिक्स डोमेन सॉकेट निर्माण को रोकने के लिए **seccomp BPF (Berkeley Packet Filter)** का उपयोग करता है। यह प्रक्रियाओं को स्थानीय IPC के लिए नए यूनिक्स डोमेन सॉकेट बनाने से रोकने के लिए सुरक्षा की एक अतिरिक्त परत प्रदान करता है (जब तक स्पष्ट रूप से अनुमति न दी गई हो)।

**यह कैसे काम करता है:**

1. **बेक्ड-इन BPF फ़िल्टर**: पैकेज x64 और arm64 के लिए एक स्थिर `apply-seccomp` बाइनरी शिप करता है जिसमें seccomp BPF फ़िल्टर संकलित होता है। फ़िल्टर आर्किटेक्चर-विशिष्ट है लेकिन libc-स्वतंत्र है, इसलिए बाइनरी glibc और musl दोनों के साथ काम करती है।

2. **रनटाइम पहचान**: सैंडबॉक्स स्वचालित रूप से आपके सिस्टम के आर्किटेक्चर का पता लगाता है और मेल खाते `apply-seccomp` बाइनरी का उपयोग करता है।

3. **Syscall फ़िल्टरिंग**: BPF फ़िल्टर `socket()` syscall को इंटरसेप्ट करता है और `EPERM` लौटाकर `AF_UNIX` सॉकेट के निर्माण को रोकता है। यह सैंडबॉक्स किए गए कोड को नए यूनिक्स डोमेन सॉकेट बनाने से रोकता है।

4. **apply-seccomp बाइनरी का उपयोग करके दो-चरणीय अनुप्रयोग**:
   - बाहरी bwrap फ़ाइलसिस्टम, नेटवर्क और PID नेमस्पेस प्रतिबंधों के साथ सैंडबॉक्स बनाता है
   - नेटवर्क ब्रिजिंग प्रक्रियाएँ (socat) सैंडबॉक्स के अंदर शुरू होती हैं (यूनिक्स सॉकेट की आवश्यकता होती है)
   - apply-seccomp एक नेस्टेड user+PID+mount नेमस्पेस बनाता है और `/proc` को रीमाउंट करता है
   - नेस्टेड नेमस्पेस के अंदर, apply-seccomp PID 1 के रूप में कार्य करता है (non-dumpable init/reaper)
   - apply-seccomp फोर्क करता है, `prctl()` के माध्यम से seccomp फ़िल्टर लागू करता है, और उपयोगकर्ता कमांड को exec करता है
   - उपयोगकर्ता कमांड सभी सैंडबॉक्स प्रतिबंधों के साथ-साथ यूनिक्स सॉकेट निर्माण अवरोधन के साथ चलता है

**PID नेमस्पेस अलगाव**: नेस्टेड PID नेमस्पेस यह सुनिश्चित करता है कि उपयोगकर्ता कमांड किसी भी प्रक्रिया को नहीं देख सकता या संबोधित नहीं कर सकता जो seccomp फ़िल्टर के बिना चलती है (bwrap का init, शेल रैपर, या socat हेल्पर्स)। यह `kernel.yama.ptrace_scope` की परवाह किए बिना seccomp सीमा को बरकरार रखता है, क्योंकि अनफ़िल्टर्ड हेल्पर्स `ptrace` या `/proc/N/mem` के माध्यम से पहुंच योग्य नहीं हैं। आंतरिक PID 1 `PR_SET_DUMPABLE=0` सेट करता है ताकि यह भी ptraceable न हो। यदि नेस्टेड नेमस्पेस निर्माण विफल हो जाता है, तो apply-seccomp अलगाव के बिना चलने के बजाय रुक जाता है।

**सुरक्षा सीमाएँ**: फ़िल्टर `socket(AF_UNIX, ...)` और `io_uring_setup`/`io_uring_enter`/`io_uring_register` syscalls को रोकता है (बाद वाले तीन क्योंकि Linux 5.19+ पर `IORING_OP_SOCKET` अन्यथा `socket()` नियम को बायपास कर देगा)। यह मूल प्रक्रियाओं से विरासत में मिले या `SCM_RIGHTS` के माध्यम से पारित यूनिक्स सॉकेट फ़ाइल डिस्क्रिप्टर पर संचालन को नहीं रोकता है। अधिकांश सैंडबॉक्सिंग परिदृश्यों के लिए, अनधिकृत IPC को रोकने के लिए सॉकेट निर्माण को अवरुद्ध करना पर्याप्त है।

**शून्य रनटाइम निर्भरताएँ**: x64 और arm64 आर्किटेक्चर के लिए पूर्व-निर्मित स्थिर apply-seccomp बाइनरी और पूर्व-जनरेटेड BPF फ़िल्टर शामिल हैं। रनटाइम पर कोई संकलन उपकरण या बाहरी निर्भरता की आवश्यकता नहीं है।

**आर्किटेक्चर समर्थन**: x64 और arm64 पूर्व-निर्मित बाइनरी के साथ पूरी तरह से समर्थित हैं। अन्य आर्किटेक्चर वर्तमान में समर्थित नहीं हैं। असमर्थित आर्किटेक्चर पर यूनिक्स सॉकेट अवरोधन के बिना सैंडबॉक्सिंग का उपयोग करने के लिए, अपने कॉन्फ़िगरेशन में `allowAllUnixSockets: true` सेट करें।

### उल्लंघन का पता लगाना और निगरानी

जब एक सैंडबॉक्स की गई प्रक्रिया किसी प्रतिबंधित संसाधन तक पहुँचने का प्रयास करती है:

1. **ऑपरेशन को OS स्तर पर रोकता है** (`EPERM` त्रुटि लौटाता है)
2. **उल्लंघन को लॉग करता है** (प्लेटफ़ॉर्म-विशिष्ट तंत्र)
3. **उपयोगकर्ता को सूचित करता है** (Claude Code में, यह एक अनुमति संकेत ट्रिगर करता है)

**macOS**: सैंडबॉक्स रनटाइम macOS के सिस्टम सैंडबॉक्स उल्लंघन लॉग स्टोर में टैप करता है। यह विस्तृत जानकारी के साथ वास्तविक समय की सूचनाएँ प्रदान करता है कि क्या प्रयास किया गया था और इसे क्यों रोका गया था। यह वही तंत्र है जिसका उपयोग Claude Code उल्लंघन का पता लगाने के लिए करता है।```bash
# View sandbox violations in real-time
log stream --predicate 'process == "sandbox-exec"' --style syslog

Linux: Bubblewrap अंतर्निहित उल्लंघन रिपोर्टिंग प्रदान नहीं करता है। सिस्टम कॉल को ट्रेस करने और अवरुद्ध ऑपरेशनों की पहचान करने के लिए strace का उपयोग करें:```bash

Trace all denied operations

strace -f srt 2>&1 | grep EPERM

Trace specific file operations

strace -f -e trace=open,openat,stat,access srt 2>&1 | grep EPERM

Trace network operations

strace -f -e trace=network srt 2>&1 | grep EPERM

### उन्नत: अपना स्वयं का प्रॉक्सी लाएं

अधिक परिष्कृत नेटवर्क फ़िल्टरिंग के लिए, आप सैंडबॉक्स को अंतर्निहित प्रॉक्सी के बजाय अपने स्वयं के प्रॉक्सी का उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं। यह सक्षम करता है:

- **ट्रैफ़िक निरीक्षण**: [mitmproxy](https://mitmproxy.org/) जैसे टूल का उपयोग करके ट्रैफ़िक का निरीक्षण और संशोधन करें
- **कस्टम फ़िल्टरिंग तर्क**: सरल डोमेन अनुमतियों से परे जटिल नियम लागू करें
- **ऑडिट लॉगिंग**: अनुपालन या डिबगिंग के लिए सभी नेटवर्क अनुरोधों को लॉग करें

**mitmproxy के साथ उदाहरण:**```bash
# Start mitmproxy with custom filtering script
mitmproxy -s custom_filter.py --listen-port 8888

नोट: नए कॉन्फ़िगरेशन प्रारूप में कस्टम प्रॉक्सी कॉन्फ़िगरेशन अभी तक समर्थित नहीं है। यह सुविधा भविष्य के रिलीज़ में जोड़ी जाएगी।

महत्वपूर्ण सुरक्षा विचार: डोमेन अनुमत सूची (allowlists) के बावजूद, डेटा निष्कासन (exfiltration) वेक्टर मौजूद हो सकते हैं। उदाहरण के लिए, github.com की अनुमति देने से एक प्रक्रिया किसी भी रिपॉजिटरी में पुश कर सकती है। कस्टम MITM प्रॉक्सी और उचित प्रमाणपत्र सेटअप के साथ, आप इसे रोकने के लिए विशिष्ट API कॉल्स का निरीक्षण और फ़िल्टर कर सकते हैं।

सुरक्षा सीमाएँ

  • नेटवर्क सैंडबॉक्सिंग सीमाएँ: नेटवर्क फ़िल्टरिंग प्रणाली उन डोमेन को प्रतिबंधित करके काम करती है जिनसे प्रक्रियाओं को कनेक्ट करने की अनुमति है। यह प्रॉक्सी से गुजरने वाले ट्रैफ़िक का अन्यथा निरीक्षण नहीं करती है, और उपयोगकर्ता यह सुनिश्चित करने के लिए ज़िम्मेदार हैं कि वे अपनी नीति में केवल विश्वसनीय डोमेन की अनुमति दें।
उपयोगकर्ताओं को `github.com` जैसे व्यापक डोमेन की अनुमति देने से उत्पन्न होने वाले संभावित जोखिमों के बारे में पता होना चाहिए, जो डेटा निष्कासन की अनुमति दे सकते हैं। साथ ही, कुछ मामलों में [डोमेन फ्रंटिंग](https://en.wikipedia.org/wiki/Domain_fronting) के माध्यम से नेटवर्क फ़िल्टरिंग को बायपास करना संभव हो सकता है।
  • यूनिक्स सॉकेट के माध्यम से विशेषाधिकार वृद्धि (Privilege Escalation): allowUnixSockets कॉन्फ़िगरेशन अनजाने में शक्तिशाली सिस्टम सेवाओं तक पहुँच प्रदान कर सकता है जो सैंडबॉक्स बायपास का कारण बन सकती हैं। उदाहरण के लिए, यदि इसका उपयोग /var/run/docker.sock तक पहुँच की अनुमति देने के लिए किया जाता है, तो यह डॉकर सॉकेट का शोषण करके होस्ट सिस्टम तक प्रभावी रूप से पहुँच प्रदान करेगा। उपयोगकर्ताओं को सैंडबॉक्स के माध्यम से अनुमति दिए जाने वाले किसी भी यूनिक्स सॉकेट पर सावधानीपूर्वक विचार करने के लिए प्रोत्साहित किया जाता है।
  • फ़ाइलसिस्टम अनुमति वृद्धि: अत्यधिक व्यापक फ़ाइलसिस्टम लेखन अनुमतियाँ विशेषाधिकार वृद्धि हमलों को सक्षम कर सकती हैं। $PATH में निष्पादन योग्य फ़ाइलों वाले निर्देशिकाओं, सिस्टम कॉन्फ़िगरेशन निर्देशिकाओं, या उपयोगकर्ता शेल कॉन्फ़िगरेशन फ़ाइलों (.bashrc, .zshrc) में लेखन की अनुमति देना, जब अन्य उपयोगकर्ता या सिस्टम प्रक्रियाएँ इन फ़ाइलों तक पहुँचती हैं, तो विभिन्न सुरक्षा संदर्भों में कोड निष्पादन का कारण बन सकता है।
  • लिनक्स सैंडबॉक्स शक्ति: लिनक्स कार्यान्वयन मजबूत फ़ाइलसिस्टम और नेटवर्क अलगाव प्रदान करता है, लेकिन इसमें enableWeakerNestedSandbox मोड शामिल है जो इसे विशेषाधिकार प्राप्त नेमस्पेस के बिना डॉकर वातावरण के अंदर काम करने में सक्षम बनाता है। यह विकल्प सुरक्षा को काफी कमजोर करता है और इसका उपयोग केवल उन मामलों में किया जाना चाहिए जहाँ अन्यथा अतिरिक्त अलगाव लागू किया जाता है।
  • कमजोर नेटवर्क अलगाव (macOS): enableWeakerNetworkIsolation विकल्प com.apple.trustd.agent तक पहुँच को फिर से सक्षम करता है, जो Go प्रोग्रामों को macOS सुरक्षा फ्रेमवर्क के माध्यम से TLS प्रमाणपत्र सत्यापित करने के लिए आवश्यक है। यह trustd सेवा के माध्यम से डेटा निष्कासन का एक संभावित वेक्टर खोलता है और इसे केवल तभी सक्षम किया जाना चाहिए जब Go TLS सत्यापन की आवश्यकता हो (जैसे, MITM प्रॉक्सी और कस्टम CA के साथ httpProxyPort का उपयोग करते समय)।
  • एप्पल इवेंट्स (macOS): allowAppleEvents विकल्प एप्पल इवेंट्स और लॉन्च सेवाओं के खुले अनुरोधों को भेजने को फिर से सक्षम करता है ((allow appleevent-send), (allow lsopen), और com.apple.coreservices.appleevents, com.apple.CoreServices.coreservicesd, और com.apple.coreservices.quarantine-resolver के लिए mach-lookups), जिनकी open, osascript, और URL-खोलने वाले सहायकों को आवश्यकता होती है। इनकी अनुमति के साथ, एक सैंडबॉक्स्ड कमांड बिना किसी उपयोगकर्ता संकेत के मनमाने एप्लिकेशन लॉन्च कर सकता है, और लॉन्च किए गए एप्लिकेशन पूरी तरह से सैंडबॉक्स के बाहर चलते हैं — इसलिए यह विकल्प कोड-निष्पादन अलगाव को हटा देता है, न कि केवल कमजोर करता है। एप्पल इवेंट्स के माध्यम से पहले से चल रहे एप्लिकेशनों को स्क्रिप्ट करना अतिरिक्त रूप से macOS TCC स्वचालन सहमति द्वारा नियंत्रित है, लेकिन open के माध्यम से लॉन्च करना नियंत्रित नहीं है। इसे केवल तभी सक्षम करें जब सैंडबॉक्स के अंदर के कमांड को वास्तव में URL या एप्लिकेशन खोलने की आवश्यकता हो।

ज्ञात सीमाएँ और भविष्य का कार्य

लिनक्स प्रॉक्सी बायपास: वर्तमान में ट्रैफ़िक को प्रॉक्सी के माध्यम से निर्देशित करने के लिए पर्यावरण चर (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY) का उपयोग करता है। यह अधिकांश एप्लिकेशनों के लिए काम करता है, लेकिन उन प्रोग्रामों द्वारा अनदेखा किया जा सकता है जो इन चरों का सम्मान नहीं करते हैं, जिससे वे इंटरनेट से कनेक्ट नहीं हो पाते हैं।

भविष्य में सुधार:

  • Proxychains समर्थन: लिनक्स पर LD_PRELOAD के साथ proxychains के लिए समर्थन जोड़ना, ताकि नेटवर्क कॉल्स को निचले स्तर पर इंटरसेप्ट किया जा सके, जिससे बायपास अधिक कठिन हो जाए

  • लिनक्स उल्लंघन निगरानी: लिनक्स के लिए उल्लंघन स्टोर के साथ एकीकृत स्वचालित strace-आधारित उल्लंघन पहचान लागू करना। वर्तमान में, लिनक्स उपयोगकर्ताओं को उल्लंघन देखने के लिए मैन्युअल रूप से strace चलाना पड़ता है, macOS के विपरीत जिसमें सिस्टम लॉग स्टोर के माध्यम से स्वचालित उल्लंघन निगरानी होती है

और पढ़ें

श्रेणियाँ

रक्षात्मक उपकरणकंटेनर सुरक्षागतिशील विश्लेषण (सैंडबॉक्सिंग)कॉन्फ़िगरेशन ऑडिटिंगसुरक्षा वर्चुअलाइजेशननेटवर्क सुरक्षाघटना प्रतिक्रिया