Linux सैंडबॉक्स और Fil-C

 (fil-c.org)
1 पॉइंट द्वारा GN⁺ 2025-12-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मेमोरी सुरक्षा और sandboxing एक-दूसरे से स्वतंत्र security concepts हैं, और मज़बूत defense system के लिए दोनों का साथ होना ज़रूरी है
  • Fil-C, C/C++ का memory-safe implementation है, जो Linux system call स्तर तक सुरक्षा सुनिश्चित करता है और OpenSSH जैसे system components में भी इस्तेमाल किया जा सकता है
  • OpenSSH के seccomp-BPF आधारित sandbox को Fil-C पर port करने की प्रक्रिया में, thread creation limits और seccomp filter adjustments मुख्य चुनौतियाँ थीं
  • Fil-C runtime के background thread management के लिए zlock_runtime_threads() API जोड़ी गई, जो sandbox के भीतर thread behavior को नियंत्रित करती है
  • Fil-C, prctl calls को सभी runtime threads पर synchronized तरीके से लागू करता है, ताकि no_new_privs और seccomp filters पूरे process पर एकसमान रूप से लागू हों

मेमोरी सुरक्षा और sandboxing का संबंध

  • मेमोरी सुरक्षा और sandboxing अलग-अलग security layers हैं; इनमें से केवल एक होने पर पूर्ण सुरक्षा नहीं मिलती
    • memory-safe लेकिन sandboxed नहीं होने का उदाहरण: ऐसा Java program जो user input के जरिए files overwrite कर सकता हो
    • sandboxed लेकिन memory-safe नहीं होने का उदाहरण: assembly में लिखा ऐसा program जिसकी privileges सीमित हों
  • वास्तविक sandbox में broker process के साथ communication की अनुमति जैसी संरचनात्मक कमज़ोरियाँ मौजूद होती हैं
  • इसलिए मेमोरी सुरक्षा और sandboxing को साथ में लागू करना सबसे अच्छा defense approach है

Fil-C और OpenSSH sandbox का संयोजन

  • Fil-C, C/C++ का memory-safe implementation है, जो Linux system call स्तर पर सुरक्षा बनाए रखता है
    • Fil-C runtime, init, udevd जैसे low-level system components में भी चल सकता है
    • OpenSSH, Fil-C पर सामान्य रूप से चलता है और seccomp-BPF sandbox का उपयोग करता है
  • Linux पर OpenSSH निम्न tools से sandbox बनाता है
    • chroot से filesystem access सीमित करना
    • sshd user/group के रूप में चलाना
    • setrlimit से file opening और process creation सीमित करना
    • seccomp-BPF filter से केवल allowed system calls की अनुमति देना
  • Fil-C, chroot और user switching को मूल रूप से support करता है, लेकिन setrlimit और seccomp-BPF runtime behavior से टकरा सकते हैं, इसलिए अतिरिक्त adjustments की ज़रूरत पड़ती है

Fil-C runtime का thread control

  • Fil-C runtime, garbage collection के लिए background threads का उपयोग करता है और ज़रूरत पड़ने पर उन्हें अपने-आप रोकता और फिर शुरू करता है
  • OpenSSH का setrlimit sandbox नए processes के निर्माण को रोकने के लिए बनाया गया है, इसलिए runtime का thread creation इससे टकरा सकता है
  • इसे हल करने के लिए <stdfil.h> में zlock_runtime_threads() API जोड़ी गई
    • runtime ज़रूरी threads को तुरंत बनाता है, और उसके बाद automatic shutdown को disable कर देता है
    • OpenSSH के ssh_sandbox_child function में इसे setrlimit या seccomp-BPF call से पहले चलाया जाता है

OpenSSH seccomp filter adjustments

  • zlock_runtime_threads() लागू करने के बाद sandbox की अधिकांश functionality पहले जैसी काम करती रही
  • seccomp filter में निम्न बदलाव किए गए
    • violation होने पर SECCOMP_RET_KILL_PROCESS सेट किया गया ताकि Fil-C background threads भी साथ में terminate हों
    • MAP_NORESERVE को allow list में जोड़ा गया, ताकि Fil-C memory allocator का उपयोग हो सके
    • sched_yield call की अनुमति दी गई, क्योंकि यह Fil-C के lock implementation में इस्तेमाल होता है
  • Fil-C के synchronization के लिए futex call पहले से allowed था, इसलिए अतिरिक्त बदलाव की ज़रूरत नहीं पड़ी

Fil-C का prctl implementation तरीका

  • OpenSSH, seccomp filter install करते समय दो तरह के prctl calls का उपयोग करता है
    • PR_SET_NO_NEW_PRIVS से अतिरिक्त privileges हासिल करने पर रोक
    • PR_SET_SECCOMP, SECCOMP_MODE_FILTER से filter को सक्रिय करना
  • समस्या यह है कि prctl सिर्फ calling thread पर लागू होता है, इसलिए Fil-C के दूसरे runtime threads के बिना filter बचे रहने का जोखिम था
  • Fil-C, इसे रोकने के लिए filc_runtime_threads_handshake() API के जरिए सभी runtime threads पर synchronized application करता है
    • यह सुनिश्चित करता है कि हर thread वही prctl call चलाए
    • अगर कई user threads मौजूद हों, तो सुरक्षा मज़बूत करने के लिए Fil-C safety error उत्पन्न की जाती है

निष्कर्ष

  • मेमोरी सुरक्षा और sandboxing का संयोजन सबसे शक्तिशाली security combination है
  • Fil-C, OpenSSH के seccomp-आधारित sandbox को पूरी तरह integrate करते हुए भी protection level घटाए बिना memory safety बनाए रखता है
  • Linux environment में Fil-C का उपयोग करके system-level security और language-level safety दोनों एक साथ हासिल की जा सकती हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-14
Hacker News की राय

  • समझ नहीं आ रहा कि landlock का ज़िक्र क्यों नहीं है

  • C → WASM → C वाला हाइब्रिड कंपाइल अप्रोच मौजूद है
    इससे OS interaction को पूरी तरह नियंत्रित किया जा सकता है, और WASM की तरह memory access को sandbox किया जा सकता है, जबकि तकनीकी रूप से यह अब भी C code ही रहता है
    संबंधित सामग्री RLBox पर देखी जा सकती है

    • WASM sandbox प्रोग्राम की soundness की गारंटी नहीं देता
      यह memory को खराब कर सकता है, लेकिन उसका दायरा sandbox के अंदर तक सीमित रहता है
      SECCOMP जैसे सिस्टम में हर interaction policy को बारीकी से परिभाषित करना पड़ता है, इसलिए यह नौकरशाही जैसा झंझटपूर्ण है
      वहीं Fil-C ऐसा अप्रोच अपनाता है जिसमें language और runtime खुद प्रोग्राम के सही व्यवहार को सुनिश्चित करने की कोशिश करते हैं
      Fil-C binaries सामान्य executables हैं, इसलिए इन्हें SECCOMP जैसे sandbox के साथ भी इस्तेमाल किया जा सकता है
      Linux को prctl interface बनाने में 20 साल लगे थे, इसलिए WASI में ऐसा कुछ देखने के लिए शायद 10 साल इंतज़ार करना पड़े
    • RLBox sandboxing तकनीक है, memory safety तकनीक नहीं
      sandbox के अंदर भी अजीब execution flow बनाया जा सकता है

  • Fil-C का लेखक तकनीकी रूप से दिलचस्प आविष्कार अच्छे से करता है, लेकिन यह चिंता है कि implementation verification पर्याप्त हुआ है या नहीं
    कहा गया कि setuid programs को Fil-C से compile किया जा सकता है, लेकिन ld.so में किए गए बदलाव खतरनाक हो सकते हैं
    setuid apps को environment variables, file descriptors, rlimit, signals आदि के मामले में बहुत defensive तरीके से लिखा जाना चाहिए
    ये हिस्से अभी अधूरे लगते हैं, इसलिए इन्हें असली infrastructure में इस्तेमाल करना risk भरा है
    फिर भी codebase को Fil-C से test करने पर दिलचस्प bugs मिल सकते हैं

    • अभी यह test किया जा रहा है कि वास्तव में Fil-C को तोड़ने का कोई तरीका है या नहीं
    • अगर सच में चिंता है, तो खुद प्रयोग करके नतीजे साझा करने चाहिए
    • लक्ष्य runtime को पारदर्शी बनाना है ताकि auditing संभव हो
      ld.so में बदलाव छोटा सा है, बस libc layout सिखाने भर का
      setuid से जुड़ा getenv bug भी पहले ही secure_getenv से ठीक किया जा चुका है
      उठाए गए मुद्दों में कुछ सच्चाई है और कुछ FUD भी मिला हुआ है
    • Fil-C लेखक का आलोचना पर असहयोगी रवैया निराशाजनक है
      data race की स्थिति में Fil-C में pointer और capability के बीच mismatch हो सकता है
      इससे memory safety violation हो सकता है
      लेखक इसे नकारता है, लेकिन Java से तुलना करना उचित नहीं है
      तकनीक बेहतरीन है, पर लेखक का रवैया भरोसा कम करता है

  • WASM एक sandbox भी है और execution environment भी, और उसके उपयोग के तरीके के अनुसार कुछ हद तक memory safety हासिल की जा सकती है
    C को WASM में compile करने पर bugs बने रहते हैं, लेकिन उनका असर सीमित हो जाता है
    इसलिए WASM को sandboxing तकनीक कहना सही है, लेकिन execution environment के रूप में इसकी संभावनाएं और भी हैं

    • WASM आखिरकार sandboxing तकनीक ही है
      module B का bug module A का data पढ़ सकता है
      यानी WASM बस lightweight process sandbox का एक विकल्प है
    • “यह उपयोग पर निर्भर करता है” यही अपने आप में सबूत है कि WASM पूरी तरह सुरक्षित नहीं है
      क्योंकि C के बारे में भी कहा जा सकता है कि “उपयोग के तरीके पर निर्भर है”
    • WASM, C के memory model को समझता नहीं है, इसलिए Fil-C जैसी protection लागू नहीं कर सकता
      WASM runtime escape को रोकता है, लेकिन अंदर चल रहे प्रोग्राम की memory escape को नहीं रोकता

  • Fil-C और Rust की तुलना मांगी गई

    • दोनों तकनीकें शानदार हैं, लेकिन इनका approach अलग है
      Fil-C मौजूदा C programs को compatibility और security पर फोकस के साथ मजबूत करने के लिए उपयुक्त है
      Rust नई codebase बनाते समय static safety और performance हासिल करने के लिए अच्छा है
      Fil-C में थोड़ा performance loss होता है, लेकिन यह मौजूदा C code जैसे ffmpeg, nginx, sudo आदि के लिए उपयोगी है
      Rust की ताकत multithreading और type system है
    • Fil-C GC जोड़ता है, इसलिए performance कम हो सकती है
      इसका लक्ष्य language design सुधारना नहीं, बल्कि memory safety हासिल करना है
      इसका मुकाबला Rust से ज़्यादा D, Nim, Go जैसी चीज़ों से है
    • Fil-C runtime checks से unsafe memory access पकड़कर प्रोग्राम रोक देता है
      Rust इसे compile time पर रोकता है
      दोनों approaches एक-दूसरे के पूरक हैं, और Rust में भी Fil-C जैसी runtime checks जोड़ी जा सकती हैं

  • MicroVM धीरे-धीरे लोकप्रिय हो रहे हैं
    यह जानने की उत्सुकता है कि Fil-C इन्हें कैसे उपयोग कर सकता है

    • थोड़ी porting की जरूरत होगी, लेकिन microVM की कुछ सुविधाओं को Fil-C के memory-safe userland तक ऊपर लाया जा सकता है

  • उम्मीद है कि इस project पर और ध्यान जाए
    sudo या polkit जैसे core tools अगर memory-safe तरीके से deploy हों तो अच्छा होगा

  • memory-safe languages में भी sandboxing का उपयोग ज़्यादा होना चाहिए
    अफसोस है कि Rust या Go में भी OS-level sandbox का बहुत उपयोग नहीं होता

    • Seccomp की portability और composability कमजोर है
      इसे library level पर configure करना मुश्किल है, और यह kernel version या libc implementation के प्रति संवेदनशील है
      file path जैसे pointer के पीछे आने वाले inputs को filter नहीं किया जा सकता, इसलिए इसकी सीमाएं हैं
      इसलिए आमतौर पर इसे application level पर सीधे configure करना पड़ता है
    • Rust में runtime लगभग नहीं के बराबर है, इसलिए यह sandboxing के लिए उपयुक्त है
      वहीं Go का runtime बड़ा है, इसलिए उसे Fil-C की तरह सुरक्षित बनाना कठिन है

  • सवाल है कि Fil-C, clang के Address Sanitizer (ASan) से अलग कैसे है
    अगर यह सिर्फ runtime panic देता है, तो क्या इसे “memory safe” कहना सही है

    • ASan bugs पकड़ने में अच्छा है, लेकिन पूरी memory safety की गारंटी नहीं देता
      कुछ bugs यह पकड़ ही नहीं पाता
      यह memory के आसपास “red zone” बनाकर काम करता है, इसलिए detection काफी हद तक किस्मत पर निर्भर करती है
    • अगर memory error असर डालने से पहले panic के जरिए रोक दी जाए, तो उसे भी memory safety माना जा सकता है
      memory safety का मतलब “crash नहीं होगा” नहीं, बल्कि “गलत access कोई प्रभाव नहीं डाल पाएगा” है

  • पूछा गया कि sandbox के लिए पूरी VM का इस्तेमाल क्यों न किया जाए

    • VM बेहतरीन sandbox है, लेकिन Chrome या OpenSSH जैसे apps में privilege separation की जरूरत होती है
      एक process बिना privileges के input parse करता है, और दूसरा process ऊंचे privileges के साथ काम करता है
      दोनों processes IPC से communicate करते हैं
      VM इस्तेमाल करने से security बढ़ती है, लेकिन overhead भी बड़ा होता है, और GPU या file access जैसी चीजें जटिल हो जाती हैं
      इसलिए आम तौर पर OS-level sandboxing ज़्यादा साफ-सुथरी मानी जाती है
    • VM ज़्यादातर समस्याएं हल कर देता है, लेकिन desktop graphics acceleration अब भी मुश्किल है
      GPU को dedicated तरीके से assign करना पड़ता है, और Qubes भी सिर्फ X11 forwarding से जुड़ता है, इसलिए acceleration नहीं मिलती