Z-Jail

Linux पर नेटिव कोड निष्पादन के लिए मल्टी-लेयर सैंडबॉक्स।
सात स्वतंत्र रक्षा परतें — कोई बाहरी निर्भरता नहीं, ~73 KiB PIE बाइनरी।

┌──────────────────────────────────────────────────────┐
│                    Z-Jail                            │
├──────────────────────────────────────────────────────┤
│  Truthimatics PV  (evidence-based verdict engine)    │
│  Namespaces       (mount, pid, net, ipc, uts)        │
│  pivot_root       (chroot on steroids)               │
│  Capabilities     (drop all, lock securebits)        │
│  NO_NEW_PRIVS     (no privilege escalation)          │
│  seccomp-BPF      (whitelist: 15 syscalls only)      │
│  Audit            (JSON logging + BLAKE2b hashing)   │
└──────────────────────────────────────────────────────┘

विषय-सूची

• त्वरित प्रारंभ
• Z-Jail क्यों?
• आर्किटेक्चर
• परतें
• उपयोग
• निर्माण और इंस्टॉल
• परीक्षण
• प्रदर्शन
• खतरा मॉडल
• दस्तावेज़ीकरण
• रोडमैप
• लाइसेंस

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

git clone https://github.com/Division-36/Z-Jail.git
cd Z-Jail
make
sudo ./z_jail --root=/path/to/rootfs --seccomp-enforce -- /bin/ls

--root निर्देशिका में लक्ष्य बाइनरी और उसकी निर्भरताओं के साथ एक न्यूनतम फाइलसिस्टम होना चाहिए (स्टैटिक बाइनरी के लिए, केवल बाइनरी ही पर्याप्त है)।

Z-Jail क्यों?

मौजूदा सैंडबॉक्सिंग समाधान कुछ समझौते करते हैं:

Z-Jail, bwrap (न्यूनतम, डिफ़ॉल्ट रूप से seccomp नहीं) और nsjail (फीचर-संपन्न, भारी निर्भरताएं) के बीच की जगह भरता है। इसे CI पाइपलाइनों, CTF जेल चुनौतियों और हल्के कोड मूल्यांकन के लिए डिज़ाइन किया गया है, जहाँ आपको कंटेनर रनटाइम शामिल किए बिना गहराई में सुरक्षा (defence-in-depth) की आवश्यकता होती है।

आर्किटेक्चर

डेटा प्रवाह

flowchart LR
    CLI[CLI args] --> P[parse_args]
    P --> C{clone namespaces}
    C -->|child| CR[child_run]
    C -->|parent| W[waitpid]
    CR --> RL[setrlimit]
    RL --> FD[close fds >= 3]
    FD --> DUMP[PR_SET_DUMPABLE=0]
    DUMP --> PV[pivot_root]
    PV --> NNP[PR_SET_NO_NEW_PRIVS]
    NNP --> CAP[drop capabilities]
    CAP --> SC[seccomp-BPF]
    SC --> SIG[signal parent]
    SIG --> EX[execve target]
    W --> A[audit JSON]
    A --> EXIT[exit]

परतों का क्रम

प्रत्येक परत इस क्रम में व्यवस्थित है कि बाद वाली परत को पहले वाली परत द्वारा पूर्ववत नहीं किया जा सकता:

1. setrlimit — किसी भी चीज़ से पहले CPU, एड्रेस स्पेस, फ़ाइल संख्या और प्रोसेस सीमित करें
2. fd scrub — सभी इनहेरिटेड fd बंद करें, सिवाय रिपोर्ट पाइप के
3. PR_SET_DUMPABLE=0 — कोर डंप अक्षम, /proc/self/mem लॉक
4. pivot_root — होस्ट फाइलसिस्टम से अलग करें; पुराना रूट आलसी ढंग से अनमाउंट हो जाता है
5. PR_SET_NO_NEW_PRIVS — इस बिंदु के बाद कोई setuid नहीं, कोई capset एस्केलेशन नहीं
6. drop_caps — सभी क्षमताओं को शून्य करें, securebits लॉक करें
7. seccomp-BPF — सिसकॉल को केवल व्हाइटलिस्ट तक सीमित करें
8. signal parent — पैरेंट को बताएं कि सैंडबॉक्स तैयार है
9. execve — प्रक्रिया को लक्ष्य बाइनरी से बदलें

sequenceDiagram
    participant P as Parent
    participant C as Child
    P->>C: clone (NEWNS|NEWPID|NEWNET|NEWIPC|NEWUTS)
    Note over C: setrlimit(CPU, AS, NOFILE, NPROC)
    Note over C: close(all fds > 2)
    Note over C: PR_SET_DUMPABLE=0
    Note over C: pivot_root → chdir("/") → umount -l
    Note over C: PR_SET_NO_NEW_PRIVS
    Note over C: capset(all zero) + securebits
    Note over C: seccomp(SECCOMP_MODE_FILTER, whitelist)
    C->>P: write(pipe, ready=1)
    Note over C: execve(target)
    P->>P: waitpid
    P->>P: write audit JSON

परतें

1. Truthimatics सार्वजनिक संस्करण

साक्ष्य-आधारित निर्णय इंजन। निष्पादित बाइनरी के बारे में भारित अवलोकन एकत्र करता है और अंतिम निर्णय (DETERMINISTIC, REJECT, या UNCERTAIN) निर्धारित करता है। प्रत्येक अवलोकन का एक भार होता है; कुल के 50% से अधिक भार वाला कोई भी एकल अवलोकन निर्णय तय करता है।

2. नेमस्पेस

clone() के माध्यम से पाँच नेमस्पेस बनाए जाते हैं:

प्रारंभिक नेमस्पेस में CAP_SYS_ADMIN की आवश्यकता होती है।

3. pivot_root

माउंट नेमस्पेस रूट को --root निर्देशिका से बदल देता है:

1. रूट निर्देशिका को उसी पर बाइंड-माउंट करें (MS_BIND|MS_REC)
2. pivot_root(new_root, put_old) — माउंट ट्री को स्वैप करें
3. chdir("/") — नए रूट में जाएँ
4. umount2("/.pivot_old", MNT_DETACH) — पुराने रूट को अलग करें
5. rmdir("/.pivot_old") — साफ करें

यह chroot(2) से कड़ाई से अधिक मजबूत है — सैंडबॉक्स की गई प्रक्रिया के लिए होस्ट रूट में वापस भागने का कोई रास्ता नहीं है, यहाँ तक कि सैंडबॉक्स के अंदर से CLONE_NEWNS के साथ भी (जो पहले से seccomp द्वारा अवरुद्ध है)।

4. क्षमताएं

सभी क्षमताएं निम्न के माध्यम से हटा दी जाती हैं:

capset(hdr, data)  // data = {0, 0, 0}
prctl(SECBIT_KEEP_CAPS_LOCKED | SECBIT_NO_SETUID_FIXUP | ...)

प्रक्रिया capset से पहले setuid/setgid हटा देती है ताकि uid परिवर्तन तब प्रभावी हो जब CAP_SETUID अभी भी धारित हो। capset के बाद, सभी क्षमताएं समाप्त हो जाती हैं और securebits लॉक हो जाते हैं — पुनः सक्षम करना संभव नहीं है।

5. NO_NEW_PRIVS

prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);

प्रक्रिया या उसके चाइल्ड को setuid बाइनरी, फ़ाइल क्षमताओं या LSM ट्रांज़िशन के माध्यम से नए विशेषाधिकार प्राप्त करने से रोकता है। अपरिवर्तनीय।

6. seccomp-BPF (whitelist-v1)

15 सिसकॉलों की अनुमति-सूची — सूची में न होने वाली कोई भी चीज़ SECCOMP_RET_KILL पाती है:

BPF फ़िल्टर गतिशील रूप से उत्पन्न होता है: प्रत्येक व्हाइटलिस्ट प्रविष्टि के लिए एक जंप चेन उत्सर्जित होती है जो या तो अनुमति देती है (यदि सिसकॉल मेल खाता है) या KILL तक गिर जाती है। आर्किटेक्चर की जाँच पहले की जाती है (AUDIT_ARCH_X86_64)।

फ़िल्टर को एक स्वतंत्र स्टैंडअलोन टेस्ट (tests/seccomp_filter_test.c, 8/8 पास) द्वारा स्वतंत्र रूप से सत्यापित किया जाता है, जो रूट की आवश्यकता के बिना वास्तविक prctl(PR_SET_SECCOMP) के विरुद्ध टेस्ट केस को fork+execve करता है।

7. ऑडिट

हर निष्पादन एक JSON ऑडिट रिकॉर्ड उत्पन्न करता है:

{
  "schema": "z-jail.audit/v1",
  "build_id": "Z-Jail/v1+dev",
  "timestamp": 1749000000,
  "duration_ns": 8500000,
  "executable": "/bin/ls",
  "verdict": "DETERMINISTIC",
  "exit_code": 0,
  "sandbox": {
    "seccomp_filter": "whitelist-v1",
    "seccomp_whitelist_size": 15,
    "seccomp_arg_rules_size": 2,
    "namespaces": ["mount","pid","net","ipc","uts"],
    "pivot_root": "/var/run/z-jail/roots/default",
    "no_new_privs": true,
    "capabilities_dropped": true
  },
  "content_fingerprint": "0e5751c026e543b2e8ab2eb06099daa1..."
}

build/audits/<binary-name>.audit.json में लिखा जाता है। content_fingerprint लक्ष्य बाइनरी का BLAKE2b-256 हैश है, जिसकी गणना चाइल्ड के समाप्त होने के बाद पैरेंट द्वारा की जाती है।

उपयोग

z_jail --root=<dir> [--seccomp-enforce] [--self-hash=<hex>]
       [--quiet] [--verbose] -- <program> [args...]

उदाहरण

# Run a static binary with all protections
sudo z_jail --root=./roots --seccomp-enforce -- bin/hello_static

# Run with binary integrity verification
sudo z_jail --root=./roots --seccomp-enforce \
  --self-hash=$(sha256sum z_jail | cut -c1-64) -- bin/program

# Quiet mode (no audit JSON)
sudo z_jail --root=./roots --quiet -- bin/program

निकास कोड

निर्माण और इंस्टॉल

आवश्यकताएँ

• Linux कर्नेल ≥ 5.4 (नेमस्पेस, seccomp-BPF, pivot_root)
• GCC ≥ 11 (11.4, 13.2, 15.2 पर परीक्षण किया गया)
• कोई बाहरी लाइब्रेरी नहीं — केवल मानक C टूलचेन

कमांड

make              # build z_jail (~130 KiB PIE binary)
make install      # install to /usr/local/bin + man page
make clean        # remove build artifacts
make dist         # create release tarball
make check        # smoke test (--version + --help)

बाइनरी को -fstack-protector-strong, -D_FORTIFY_SOURCE=2, पूर्ण RELRO और -z now के साथ Position Independent Executable के रूप में बनाया गया है।

संकलन-समय विकल्प

make CC=clang CFLAGS="-O3 -march=native"   # custom compiler/flags

परीक्षण

त्वरित परीक्षण (बिना रूट)

# seccomp filter logic (8 tests)
tests/build/seccomp_filter_test

# BLAKE2b known-answer test
tests/build/blake2b_known

इन्हें रूट की आवश्यकता नहीं होती और ये 100 ms से कम समय में चलते हैं।

पूर्ण टेस्ट सूट

make -C tests setup          # build payloads + test roots
sudo bash tests/run_tests.sh # 17 scenarios

नेमस्पेस निर्माण के लिए रूट की आवश्यकता होती है। टेस्ट सूट निम्नलिखित को कवर करता है:

प्रदर्शन

WSL2 (कर्नेल 6.18.x-microsoft-standard-WSL2, Kali Linux) पर मापा गया, प्रति टूल 50 नमूने, समान कार्यभार (एक फ्रीस्टैंडिंग स्टैटिक बाइनरी जिसका मुख्य भाग exit_group(0) है), getrusage हार्नेस के साथ समयबद्ध। पद्धति के लिए docs/BENCHMARKS.md देखें।

आमने-सामने (एक ही होस्ट, एक ही पद्धति)

परीक्षण की गई शर्तों के तहत Z-Jail के पास तीनों प्रोसेस-स्तरीय सैंडबॉक्सों में सबसे छोटा रेजिडेंट सेट है और विलंबता bwrap और nsjail के बीच है। Bubblewrap सबसे तेज़ है लेकिन डिफ़ॉल्ट रूप से कोई seccomp फ़िल्टरिंग नहीं करता, इसलिए वह कम सेटअप कार्य करता है; Z-Jail हर रन पर seccomp व्हाइटलिस्ट स्थापित करता है, क्षमताएं हटाता है और pivot_root करता है। gVisor (runsc) इस WSL2 कर्नेल पर segfault करता है और मापा नहीं जा सका; Firecracker microVM के माध्यम से अलगाव करता है (VM कोल्ड-बूट, एक अलग मीट्रिक) और fork-to-exec तालिका से बाहर रखा गया है। ये एकल-होस्ट संख्याएँ हैं — इन्हें सापेक्ष मानें।

नोट: पुराने दर्ज किए गए आंकड़े (~8 ms, ~4 MiB, ~130 KiB) वर्तमान make बिल्ड (~73 KiB, ~5.9 ms) से मेल नहीं खाते और गलत प्रतीत होते हैं; ऊपर दिए गए आंकड़े इसी कोडबेस पर पुनः मापे गए थे। Truthimatics अभी भी कोड का हिस्सा है और उसे हटाया नहीं गया था (पुरानी axiom_jail रिपोर्टों में केवल एक अलग बाइनरी नाम और हार्नेस का उपयोग किया गया था)। बेंचमार्किंग के दौरान पाया गया एक माउंट-प्रोपेगेशन बग src/sandbox.c में ठीक किया गया था (बाइंड माउंट से पहले MS_REC|MS_PRIVATE); रिकर्सिव रीमाउंट मापी गई विलंबता का एक हिस्सा योगदान देता है।

खतरा मॉडल

दायरे में

• अविश्वसनीय पेलोड द्वारा मनमाना नेटिव कोड निष्पादन
• chroot, mount, ptrace, socket, process_vm_writev के माध्यम से पलायन
• फोर्क बम, CPU थकावट (RLIMIT_CPU), मेमोरी थकावट (RLIMIT_AS)
• execve के दौरान फ़ाइल डिस्क्रिप्टर लीक
• setuid / डायनामिक लिंकर / LD_PRELOAD एस्केलेशन
• seccomp फ़िल्टर हटाना या क्षमता पुनः सक्षम करना

दायरे से बाहर

• अनुमत सिसकॉल सतह के बाहर कर्नेल ज़ीरो-डे
• हार्डवेयर साइड चैनल (Spectre, Meltdown)
• साझा /proc, /sys माउंट के माध्यम से सह-स्थित VM पलायन
• नेटवर्क एग्रेस जो CLONE_NEWNET + अवरुद्ध socket प्रदान करता है उससे परे
• सहोदर सैंडबॉक्सों की संसाधन भुखमरी (cgroup समर्थन की आवश्यकता है)

मान्यताएँ

• होस्ट कर्नेल अपरिवर्तित Linux ≥ 5.4 है
• clone(CLONE_NEWNS|CLONE_NEWPID|...) सफल होता है (CAP_SYS_ADMIN की आवश्यकता है)
• लक्ष्य बाइनरी स्टैटिक रूप से लिंक है (या डायनामिक लाइब्रेरी --root में उपलब्ध हैं)
• प्रोडक्शन डिप्लॉयमेंट में --self-hash=<hex> कॉन्फ़िगर किया गया है

दस्तावेज़ीकरण

रोडमैप

v1 (वर्तमान)

• 7-परत गहराई-सुरक्षा (defence-in-depth) सैंडबॉक्स
• BLAKE2b-256 सामग्री फ़िंगरप्रिंटिंग
• ऑडिट JSON आउटपुट
• 17 टेस्ट परिदृश्य
• मैन पेज, कम्प्लीशन (bash, zsh, fish)

v2 (नियोजित)

• बाहरी seccomp नीति फ़ाइल (JSON या BPF स्रोत)
• प्रति सैंडबॉक्स इंस्टेंस कस्टम नेमस्पेस फ़्लैग
• CLI के माध्यम से कॉन्फ़िगर करने योग्य सिसकॉल व्हाइटलिस्ट
• CI एकीकरण के लिए प्रदर्शन प्रोफाइलिंग हुक
• रिलीज़ हस्ताक्षर (minisign/signify)

स्थिति

लाइसेंस

MIT — पूरा पाठ LICENSE में देखें।

Z-Jail को WSL2 (Kali Linux, GCC 15.2.0) पर बनाया गया था, जो Linux 5.4+ को लक्षित करता है। Division-36 द्वारा अनुरक्षित। समस्याओं की रिपोर्ट issue tracker पर करें।