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

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

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

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

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

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

मैं अपने सैंडबॉक्सी को कैसे कंपाइल करूं?

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

हालांकि, स्टैटिक तौर पर लिंक किए गए सैंडबॉक्स की जांच करने पर यह पता चलता है कि सिस्टम कॉल को अनुमति वाली सूची में शामिल करने की ज़रूरत कम होती है. साथ ही, सुरक्षा से जुड़ी कुछ समस्याएं भी होती हैं. जैसे, एएसएलआर हीप एन्ट्रॉपी कम हो जाती है (30 बिट से 8 बिट तक). इससे, हैकिंग करना आसान हो जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नहीं. एक एक्ज़ीक्यूटर इंस्टेंस, सैंडबॉक्स के PID को सेव करता है. साथ ही, सैंडबॉक्स इंस्टेंस के लिए Comms इंस्टेंस को मैनेज करता है.

मुझे forkserver.cc में “Function not implemented” मैसेज क्यों मिलता है?

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

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

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

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