अक्सर पूछे जाने वाले प्रश्न

क्या थ्रेड इस्तेमाल की जा सकती हैं?

हां, Sandbox2 में थ्रेड काम करती हैं.

सभी थ्रेड को सैंडबॉक्स किया जाना चाहिए

Linux के काम करने के तरीके की वजह से, secCOM-bpf नीति सिर्फ़ मौजूदा थ्रेड पर लागू की जाती है: इसका मतलब है कि नीति दूसरे मौजूदा थ्रेड पर लागू नहीं होती, लेकिन आने वाले थ्रेड इस नीति को इनहेरिट करेंगे:

• अगर Sandbox2 को पहले मोड में इस्तेमाल किया जा रहा है, जिसमें execve() से पहले सैंडबॉक्सिंग चालू है, तो सभी थ्रेड पर नीति लागू होगी. इसमें कोई समस्या नहीं है. यह सैंडबॉक्सिंग का पसंदीदा मोड है.
• अगर दूसरे मोड का इस्तेमाल किया जा रहा है, जहां एक्ज़ीक्यूटर के पास set_enable_sandbox_before_exec(false) है और Sandboxee, एक्सक्यूटर को SandboxMeHere() के साथ सैंडबॉक्स करने का निर्देश देता है, तो पक्का करें कि फ़िल्टर सभी थ्रेड पर लागू हो. ऐसा न करने पर, सैंडबॉक्स के एस्केप होने का खतरा भी रहता है. नुकसान पहुंचाने वाले कोड, सैंडबॉक्स किए गए थ्रेड से सैंडबॉक्स न किए गए थ्रेड में माइग्रेट हो सकते हैं.

ध्यान दें: Linux कर्नेल ने वर्शन 3.17 में TSYNC फ़्लैग लॉन्च किया था. इससे सभी थ्रेड पर नीति लागू की जा सकती है. इस फ़्लैग से पहले, सिर्फ़ थ्रेड-दर-थ्रेड के आधार पर नीति को लागू किया जा सकता था. अगर Sandbox2 को पता चलता है कि यह TSYNC के बिना कर्नेल पर चल रहा है और आपने SandboxMeHere() को मल्टी-थ्रेड प्रोग्राम से कॉल किया है, तो Sandbox2 रद्द हो जाएगा, क्योंकि इससे सैंडबॉक्स की सुरक्षा पर असर पड़ेगा.

मुझे अपना सैंडबॉक्सी कैसे कंपाइल करना चाहिए?

अगर आप सावधान नहीं रहते हैं, तो कई चीज़ों पर निर्भरता और खराब असर (अतिरिक्त सिस्टम कॉल, फ़ाइल ऐक्सेस या नेटवर्क कनेक्शन) को इनहेरिट करना आसान होता है. इससे सैंडबॉक्स करना मुश्किल हो जाता है (सभी खराब असर को ट्रैक करना) और कम सुरक्षित (क्योंकि सिस्ट कॉल और फ़ाइल की नीतियां ज़्यादा चौड़ी होती हैं). कुछ कंपाइलेशन विकल्पों से ऐसी समस्याओं को कम करने में मदद मिल सकती है:

• बहुत सारे सिस्टम कॉल (open/openat, mmap वगैरह) का इस्तेमाल करने वाली डाइनैमिक लिंकिंग से बचने के लिए, सैंडबॉक्स बाइनरी को स्टैटिक रूप से कंपाइल करें.

• Bazel, डिफ़ॉल्ट रूप से pie को जोड़ता है, लेकिन यह इसके साथ काम नहीं करता. इसलिए, cc_binary नियमों में दिए गए इन विकल्पों का इस्तेमाल करके, फ़ीचर फ़्लैग का इस्तेमाल करें:

  linkstatic = 1,
  features = [
      "fully_static_link",  # link libc statically
      "-pie",
  ],
  

हालांकि: स्टैटिक का इस्तेमाल करने से, एएसएलआर हीप एंट्रॉपी (30 बिट से 8 बिट) को कम करने में समस्या आ सकती है. इससे गड़बड़ी का फ़ायदा लेना आसान हो जाता है. अपने सैंडबॉक्स लागू करने और नीति के आधार पर सावधानी से तय करें कि क्या पसंद किया जाएगा:

• स्टैटिक नहीं होता: अच्छा हीप एएसएलआर, शुरुआती कोड चलाने में मुश्किल हो सकता है. हालांकि, सैंडबॉक्स नीति की कम कीमत पर, आसानी से इसे आसानी से हटाया जा सकता है.
• स्टैटिक: खराब हीप एएसएलआर, शुरुआती कोड को एक्ज़ीक्यूट करने पर आसानी से काम करने वाला, लेकिन एक ज़्यादा असरदार सैंडबॉक्स नीति, जिसे हटाना मुश्किल हो सकता है.

यह सही विकल्प नहीं है, क्योंकि कंपाइलर, स्टैटिक PIE (पोज़िशन इंडिपेंडेंट एक्ज़ीक्यूटेबल) के साथ काम नहीं करता. PIE को बाइनरी फ़ाइल को डाइनैमिक ऑब्जेक्ट बनाकर लागू किया जाता है. साथ ही, डाइनैमिक लोडर इसे चलाने से पहले, किसी रैंडम लोकेशन पर मैप करता है. इसके बाद, पारंपरिक तौर पर हीप को बाइनरी के बेस पते के बाद किसी रैंडम ऑफ़सेट पर रखा जाता है (और उसे brk syscall के साथ बढ़ाया जाता है), इसलिए, स्टैटिक बाइनरी के लिए हीप एएसएलआर एंट्रॉपी का मतलब सिर्फ़ यह ऑफ़सेट है, क्योंकि कोई पीआईई नहीं है.

कंपाइल करने के इन विकल्पों के उदाहरण देखने के लिए, BUILD.bazel का स्टैटिक उदाहरण देखें: static_bin.cc को स्टैटिक रूप से कंपाइल किया गया है. इसकी मदद से, हम बहुत ही सटीक तरीके से सिस्टम की कॉल की नीति बना सकते हैं. यह तीसरे पक्ष की बाइनरी को सैंडबॉक्स करने के लिए भी अच्छी तरह काम करता है.

क्या 32-बिट x86 बाइनरी को सैंडबॉक्स किया जा सकता है?

सैंडबॉक्स2 सिर्फ़ उसी आर्किटेक्चर को सैंडबॉक्स कर सकता है जिससे उसे कंपाइल किया गया था.

इसके अलावा, Sandbox2 से 32-बिट x86 का समर्थन हटा दिया गया है. अगर किसी 32-बिट x86 बाइनरी को सैंडबॉक्स करने के लिए, 64-बिट x86 एक्सक्यूटर का इस्तेमाल किया जाता है या 32-बिट x86 बाइनरी को सैंडबॉक्स करने के लिए 64-बिट x86 बाइनरी का इस्तेमाल किया जाता है, तो दोनों सैंडबॉक्स उल्लंघन को जनरेट करेंगे. इसे आर्किटेक्चर लेबल [X86-32] से पहचाना जा सकता है.

इस व्यवहार की वजह यह है कि अलग-अलग आर्किटेक्चर के बीच सिस्टकॉल नंबर अलग-अलग होते हैं. साथ ही, सैंडबॉक्स की आर्किटेक्चर में सिस्टकॉल नीति लिखी जाती है. इसलिए, सैंडबॉक्सी के लिए किसी अलग आर्किटेक्चर को अनुमति देना खतरनाक हो सकता है. इस सबकी वजह से ऐसा लग सकता है कि कोई नुकसान नहीं पहुंचाने वाला सिस्टकॉल मिलेगा. इसका मतलब यह है कि एक और नुकसान पहुंचाने वाला सिसकॉल, सैंडबॉक्स को एस्केप करने के लिए खोल सकता है.

क्या एक्ज़ीक्यूटर प्रोसेस, सैंडबॉक्स की संख्या की कोई सीमा तय कर सकती है?

हर Sandboxee इंस्टेंस (फ़ोर्कसर्वर से शुरू होने वाली नई प्रोसेस) के लिए, एक नया थ्रेड बनाया जाता है - जहां यह सीमा लागू होती है.

क्या एक्ज़ीक्यूटर एक से ज़्यादा सैंडबॉक्स बनाने का अनुरोध कर सकता है?

नहीं. इसमें 1:1 का संबंध होता है – एक्ज़ीक्यूटर इंस्टेंस, Sandboxee का PID स्टोर करता है, Sandbox इंस्टेंस को Comms इंस्टेंस मैनेज करता है वगैरह.

मुझे forkserver.cc के अंदर “फ़ंक्शन लागू नहीं किया गया” क्यों दिखता है?

Sandbox2 केवल उचित रूप से नए कर्नेल पर चलने का समर्थन करता है. हमारा मौजूदा कट-ऑफ़, 3.19 कर्नेल है. हालांकि, आने वाले समय में यह बदल सकता है. इसकी वजह यह है कि हम kernel की नई सुविधाएं इस्तेमाल कर रहे हैं. इनमें उपयोगकर्ता नेमस्पेस और TSYNC फ़्लैग के साथ secCOM शामिल हैं.

अगर प्रोडक्शन चल रहा है, तो इसमें कोई समस्या नहीं होनी चाहिए, क्योंकि करीब-करीब पूरा फ़्लीट, ज़रूरत के मुताबिक नया कर्नेल चला रहा है. अगर आपको इसमें कोई समस्या है, तो कृपया हमसे संपर्क करें.

अगर आप Debian या Ubuntu पर चल रहे हैं, तो अपने kernel को अपडेट करना उतना ही आसान है जितना कि:

sudo apt-get install linux-image-<RECENT_VERSION>