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

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

हां, Sandbox2 में थ्रेड की सुविधा उपलब्ध है.

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

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

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

मुझे अपना Sandboxee कैसे कंपाइल करना चाहिए?

स्टैटिक तौर पर लिंक किए गए एक्ज़ीक्यूटेबल की तुलना में, Sandboxee को डाइनैमिक तौर पर लिंक किए गए एक्ज़ीक्यूटेबल में कंपाइल करने पर, syscalls की संख्या में काफ़ी बढ़ोतरी होगी. जैसे, open/openat, mmap, वगैरह. इन्हें allowlist में शामिल करना होगा. रनटाइम पर शेयर की गई लाइब्रेरी लोड करने के लिए, डाइनैमिक लिंकर इनवोकेशन की वजह से, इन सभी अतिरिक्त syscalls की ज़रूरत होती है.

हालांकि, स्टैटिक तौर पर लिंक किए गए Sandboxee को देखें: allowlist में शामिल करने के लिए, कम syscalls की ज़रूरत होती है. हालांकि, सुरक्षा से जुड़ी समस्याएं भी होती हैं. ASLR हीप एन्ट्रॉपी कम हो जाती है (30 बिट से 8 बिट तक). इससे सुरक्षा में सेंध लगाना आसान हो जाता है.

यह एक दुविधा है, जिसे इस तरह से कम किया जा सकता है:

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

पहले, स्टैटिक तौर पर लिंक किए गए बाइनरी, पोज़िशन इंडिपेंडेंट कोड (pie) की सुविधा के साथ काम नहीं करते थे. इसके अलावा, Bazel ने डिफ़ॉल्ट तौर पर pie जोड़ा है. syscall फ़िल्टर को सटीक तरीके से तय करने के लिए, आपको Bazel की डिफ़ॉल्ट वैल्यू को ओवरराइट करना होगा.

कंपाइलर में समय के साथ सुधार हुआ है और अब वे static-pie विकल्प के साथ काम करते हैं. इस विकल्प की मदद से, कंपाइलर को पोज़िशन-इंडिपेंडेंट कोड जनरेट करने का निर्देश दिया जाता है. हालांकि, pie की तुलना में, इसमें स्टैटिक तौर पर लिंक की गई सभी लाइब्रेरी भी शामिल होती हैं. सुरक्षा के लिहाज़ से, static-pie अब भी ASLR एन्ट्रॉपी को कम करता है (30 बिट से 14 बिट तक). हालांकि, यह पिछली स्थिति से बेहतर है, जिसमें pie नहीं था.

Bazel डिफ़ॉल्ट तौर पर pie जोड़ता है और स्टैटिक, इसके साथ काम नहीं करता. इसलिए, cc_binary नियम में -static-pie लिंकर फ़्लैग पास करने और डिफ़ॉल्ट को ओवरराइट करने के लिए, लिंकर के विकल्पों वाले फ़्लैग का इस्तेमाल करें:

  linkstatic = 1,
  linkopts=["-static-pie"],

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

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

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

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

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

क्या सैंडबॉक्स की संख्या के लिए कोई सीमा तय की गई है? एक्ज़ीक्यूटर प्रोसेस, कितने सैंडबॉक्स के लिए अनुरोध कर सकती है?

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

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

नहीं. 1:1 का संबंध होता है. एक एक्ज़ीक्यूटर इंस्टेंस, Sandboxee का पीआईडी सेव करता है. साथ ही, सैंडबॉक्स इंस्टेंस के लिए Comms इंस्टेंस को मैनेज करता है वगैरह.

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

Sandbox2, सिर्फ़ नए कर्नल पर काम करता है. फ़िलहाल, हमारी कट-ऑफ़ वैल्यू 3.19 कर्नल है. हालांकि, आने वाले समय में यह बदल सकती है. ऐसा इसलिए है, क्योंकि हम अपेक्षाकृत नए कर्नल फ़ीचर का इस्तेमाल कर रहे हैं. इनमें, TSYNC फ़्लैग के साथ उपयोगकर्ता नेमस्पेस और seccomp शामिल हैं.

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

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

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