अपडेट पर वापस जाएँ
New releaseAug 8, 2026

sandbox-runtime v0.0.71

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

साझा करें

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

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

srt देशी OS सैंडबॉक्सिंग प्रिमिटिव (sandbox-exec macOS पर, bubblewrap Linux पर) और प्रॉक्सी-आधारित नेटवर्क फ़िल्टरिंग का उपयोग करता है। इसका उपयोग एजेंटों, स्थानीय 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 टूल और लाइब्रेरी दोनों के रूप में उपयोग किया जा सकता है। इसे सामान्य डेवलपर उपयोग-मामलों के लिए डिफ़ॉल्ट रूप से सुरक्षित दर्शन के साथ डिज़ाइन किया गया है: प्रक्रियाएँ न्यूनतम पहुँच के साथ शुरू होती हैं, और आप केवल उन छेदों को खोलते हैं जिनकी आपको आवश्यकता होती है।

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

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

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

एक प्रमुख उपयोग-मामला Model Context Protocol (MCP) सर्वरों की क्षमताओं को प्रतिबंधित करने के लिए उन्हें सैंडबॉक्स करना है। उदाहरण के लिए, filesystem 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 server को अस्वीकृत पथ पर लिखने से रोक दिया जाएगा:```
> 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 ईग्रेस फेंस और कार्यशील ट्री पर प्रति-सत्र स्पष्ट ACEs होते हैं।

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

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

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

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

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

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

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

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

  • 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`)।** जब कोई रैप किया गया कमांड चलता है तो देखे गए उल्लंघन (seatbelt लॉग लाइनें, seccomp इवेंट, proxy अस्वीकृतियाँ) एक आरोपण कुंजी के अंतर्गत संग्रहीत किए जाते हैं, और `annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` उन्हें उसी कुंजी द्वारा खोजते हैं। डिफ़ॉल्ट रूप से कुंजी स्वयं रैप की गई स्ट्रिंग होती है। इसके बजाय उसके द्वारा कुंजी बनाने के लिए एक अपारदर्शी प्रति-आह्वान `commandId` (जैसे कि tool-use id) पास करें — अनुशंसित: कुंजियाँ अपने पहले 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) के लिए, कारण इन-बैंड भी दिया जाता है: एक SSH क्लाइंट जो बिना-प्रमाणीकरण SOCKS ProxyCommand (जैसे BSD `nc -X 5`) के माध्यम से टनल किया गया है, उसे कुंजी-विनिमय-पूर्व SSH डिस्कनेक्ट प्राप्त होता है जिसका विवरण कारण होता है, जिसे OpenSSH शब्दशः प्रिंट करता है — ऐसे कारणों को लगभग 400 ASCII वर्णों से कम रखें, पहले आज्ञार्थक (imperative) रखें, क्योंकि 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 अपस्ट्रीम** - केवल सैंडबॉक्स के अंदर का क्लाइंट क्लाइंट प्रमाणपत्र रखता है, इसलिए प्रॉक्सी उसकी ओर से कनेक्शन को पुनः-आरंभ नहीं कर सकता।
  - **प्रमाणपत्र-पिनिंग क्लाइंट** - ऐसे क्लाइंट जो अपस्ट्रीम की पहचान स्वयं सत्यापित करते हैं (कस्टम CA, SAN पिनिंग) और MITM प्रमाणपत्र को अस्वीकार करते हैं।
- `network.tlsTerminate.extraCaCertPaths` - PEM CA प्रमाणपत्र फ़ाइलों के पथ जो उस ट्रस्ट बंडल में जुड़ते हैं, MITM CA और होस्ट के नियमित रूट के बाद। बहिष्कृत (गैर-समाप्त) होस्ट सैंडबॉक्स के अंदर क्लाइंट द्वारा सत्यापित किए जाते हैं, और SRT द्वारा सेट किए गए ट्रस्ट env vars (`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-शैली ग्लॉब पैटर्न का समर्थन करते हैं, जो .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 वर्तमान में ग्लॉब मिलान का समर्थन नहीं करता। केवल शाब्दिक पथों का उपयोग करें:

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

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

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

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

  • ignoreViolations - कमांड पैटर्न को पथों की सरणियों में मैप करने वाली ऑब्जेक्ट जहाँ उल्लंघनों को अनदेखा किया जाना चाहिए
  • enableWeakerNestedSandbox - Docker वातावरण के लिए कमज़ोर सैंडबॉक्स मोड सक्षम करें (boolean, default: false)
  • enableWeakerNetworkIsolation - macOS सैंडबॉक्स में com.apple.trustd.agent तक पहुंच की अनुमति दें (boolean, default: false)। MITM प्रॉक्सी और कस्टम CA के साथ httpProxyPort का उपयोग करते समय Go प्रोग्रामों (gh, gcloud, terraform, kubectl, आदि) को TLS प्रमाणपत्र सत्यापित करने के लिए इसकी आवश्यकता होती है। सुरक्षा चेतावनी: इसे सक्षम करने से trustd सेवा के माध्यम से डेटा बाहर निकालने का संभावित वेक्टर खुल जाता है।
  • allowAppleEvents - macOS सैंडबॉक्स से Apple Events और Launch Services खोलने के अनुरोध भेजने की अनुमति दें (boolean, default: false)। इसके बिना, open, osascript, और ऐसी कोई भी चीज़ जो URL खोलती है या AppleScript के माध्यम से अन्य ऐप्स को स्क्रिप्ट करती है, AppleScript त्रुटि -600 ("Application isn't running") या 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 (alpha) देखें।

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

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 - deny path का पता लगाने के लिए तेज़ खोज उपकरण
    • 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` - deny path का पता लगाने के लिए तेज़ खोज उपकरण
  - Homebrew के माध्यम से इंस्टॉल करें: `brew install ripgrep`
  - या यहाँ से डाउनलोड करें: https://github.com/BurntSushi/ripgrep/releases

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

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

## Windows (alpha)

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

### सेटअप

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

यह srt-sandbox स्थानीय उपयोगकर्ता खाता (जिसका यादृच्छिक पासवर्ड %LOCALAPPDATA%\sandbox-runtime\state.db के अंतर्गत DPAPI-एन्क्रिप्टेड संग्रहीत होता है), sandbox-runtime-users स्थानीय समूह प्रावधानित करता है, और srt-sandbox SID पर आधारित एक मशीन-व्यापी WFP फ़िल्टर सेट स्थापित करता है। यह आइडेम्पोटेंट है — इसे दोबारा चलाने से सैंडबॉक्स खाते का पासवर्ड रोटेट होता है और फ़िल्टर सेट समेकित होता है।

कोई लॉगआउट आवश्यक नहीं है। 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 discretionary 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 को हटा देता है (समवर्ती होस्टों के बीच state.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` अनुदान में जोड़ा जाता है ताकि सैंडबॉक्स खाता इसे खोल सके।

### विंडोज़-विशिष्ट कॉन्फ़िगरेशन

क्रॉस-प्लेटफ़ॉर्म `filesystem` और `network` ब्लॉक ऊपर वर्णित अनुसार लागू होते हैं। केवल विंडोज़ सेटिंग्स `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 समूह को हटाता है, और state.db से क्रेडेंशियल/सेटअप मार्कर साफ़ करता है (एक UAC प्रॉम्प्ट)। %LOCALAPPDATA%\sandbox-runtime\state.db स्वयं अपने स्थान पर रहता है (यह ACL-स्टैम्प्ड ब्रोकर-ओनली है); पूर्ण सफाई के लिए निर्देशिका को मैन्युअल रूप से हटाएँ।

विकास```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 के लिए additive `(OI)(CI)` explicit ACEs लिखता है (ALLOW `allowRead`/`allowWrite` पर, DENY `denyRead`/`denyWrite` पर), फिर उन्हें `reset()` पर हटा देता है

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

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

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

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

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

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

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

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

- शेल कॉन्फ़िगरेशन फ़ाइलें: `.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 पर, अनिवार्य अस्वीकृति पथ (mandatory deny paths) केवल उन फाइलों को ब्लॉक करते हैं जो पहले से मौजूद हैं। इन पैटर्न में मौजूद न होने वाली फाइलों को bubblewrap की bind-mount विधि से ब्लॉक नहीं किया जा सकता। macOS glob पैटर्न का उपयोग करता है जो मौजूदा और नई दोनों फाइलों को ब्लॉक करते हैं।

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

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

### Unix Socket प्रतिबंध (Linux)

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

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

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

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

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

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

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

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

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

**आर्किटेक्चर समर्थन**: x64 और arm64 पहले से निर्मित बाइनरी के साथ पूरी तरह समर्थित हैं। अन्य आर्किटेक्चर वर्तमान में समर्थित नहीं हैं। असमर्थित आर्किटेक्चर पर Unix socket ब्लॉकिंग के बिना सैंडबॉक्सिंग का उपयोग करने के लिए, अपने कॉन्फ़िगरेशन में `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

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

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

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

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

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

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

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

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

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

और पढ़ें

श्रेणियाँ

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