Bubblewrap

कई कंटेनर रनटाइम उपकरण, जैसे systemd-nspawn, docker, आदि, सिस्टम एडमिनिस्ट्रेटर और ऑर्केस्ट्रेशन उपकरणों (जैसे Kubernetes) के लिए कंटेनर चलाने का बुनियादी ढाँचा प्रदान करने पर केंद्रित हैं।

ये उपकरण सामान्य उपयोगकर्ताओं को देने के लिए उपयुक्त नहीं हैं, क्योंकि ऐसी पहुँच को होस्ट पर पूर्ण विशेषाधिकार प्राप्त root शेल में बदलना बहुत आसान है।

उपयोगकर्ता नेमस्पेस

Linux कर्नेल में उपयोगकर्ता नेमस्पेस नामक एक सुविधा है जो सामान्य उपयोगकर्ताओं को कंटेनर सुविधाओं का उपयोग करने की अनुमति देती है। Bubblewrap सैंडबॉक्स बनाने के लिए इनका उपयोग करता है, जिससे कोई भी उपयोगकर्ता इस उपकरण का उपयोग कर सकता है।

ऐतिहासिक रूप से, bubblewrap उन सिस्टमों के लिए setuid मोड का भी समर्थन करता था जहाँ सामान्य उपयोगकर्ता नेमस्पेस समर्थित नहीं थे। हालाँकि, इसे हटा दिया गया है।

मूल bubblewrap कोड उपयोगकर्ता नेमस्पेस से पहले अस्तित्व में था - यह xdg-app helper से कोड विरासत में लेता है, जो बदले में दूरस्थ रूप से linux-user-chroot से व्युत्पन्न है।

सिस्टम सुरक्षा

इस उपकरण के अनुरक्षकों का मानना है कि यह, उस वितरण पर स्थापित विशिष्ट सॉफ़्टवेयर के साथ संयोजन में उपयोग किए जाने पर भी, विशेषाधिकार वृद्धि की अनुमति नहीं देता है। हालाँकि, यह लॉग इन उपयोगकर्ता की सेवा अस्वीकार (denial of service) हमले करने की क्षमता बढ़ा सकता है।

विशेष रूप से, bubblewrap setuid बाइनरी को बंद करने के लिए PR_SET_NO_NEW_PRIVS का उपयोग करता है, जो chroot जैसी चीज़ों से बाहर निकलने का पारंपरिक तरीका है।

सैंडबॉक्स सुरक्षा

bubblewrap सैंडबॉक्स वातावरण बनाने के लिए एक उपकरण है। bubblewrap किसी विशिष्ट सुरक्षा नीति वाला पूर्ण, तैयार-निर्मित सैंडबॉक्स नहीं है।

bubblewrap के कुछ उपयोग-मामले सैंडबॉक्स और वास्तविक सिस्टम के बीच सुरक्षा सीमा चाहते हैं; अन्य उपयोग-मामले सैंडबॉक्स के अंदर प्रक्रियाओं के लिए फाइलसिस्टम का लेआउट बदलने की क्षमता चाहते हैं, लेकिन उनका लक्ष्य सुरक्षा सीमा होना नहीं है। परिणामस्वरूप, सैंडबॉक्स की गई प्रक्रियाओं और होस्ट सिस्टम के बीच सुरक्षा का स्तर पूरी तरह से bubblewrap को दिए गए तर्कों द्वारा निर्धारित होता है।

जो भी प्रोग्राम bubblewrap के लिए कमांड-लाइन तर्क बनाता है (अक्सर Flatpak, libgnome-desktop, sandwine या एक तदर्थ स्क्रिप्ट जैसा कोई बड़ा फ्रेमवर्क) वह अपना स्वयं का सुरक्षा मॉडल परिभाषित करने और उस सुरक्षा मॉडल को लागू करने के लिए उपयुक्त bubblewrap कमांड-लाइन तर्क चुनने के लिए जिम्मेदार होता है।

सैंडबॉक्स सुरक्षा के कुछ पहलू जिन पर विशेष ध्यान देने की आवश्यकता है, उनका वर्णन नीचे सीमाएँ अनुभाग में किया गया है।

उपयोगकर्ता

इस प्रोग्राम को उन सभी कंटेनर उपकरणों द्वारा साझा किया जा सकता है जो गैर-root संचालन करते हैं, जैसे:

• Flatpak
• rpm-ostree unprivileged
• bwrap-oci

हम यह भी चाहेंगे कि यह Kubernetes/OpenShift क्लस्टरों में उपलब्ध हो। सामान्य उपयोगकर्ताओं के लिए कंटेनर सुविधाओं का उपयोग करने की क्षमता होने से इंटरैक्टिव डिबगिंग परिदृश्यों और इसी तरह के कार्यों को करना काफी आसान हो जाएगा।

स्थापना

bubblewrap अधिकांश Linux वितरणों के पैकेज रिपॉजिटरी में उपलब्ध है और वहाँ से इंस्टॉल किया जा सकता है।

यदि आपको bubblewrap को स्रोत से बनाने की आवश्यकता है, तो आप इसे meson के साथ कर सकते हैं:

meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir

उपयोग

bubblewrap एक नया, पूरी तरह से खाली mount नेमस्पेस बनाकर काम करता है, जहाँ root एक tmpfs पर होता है जो होस्ट से अदृश्य होता है, और अंतिम प्रक्रिया के बाहर निकलने पर स्वचालित रूप से साफ़ हो जाता है। फिर आप namespace में चलाने के लिए root फाइलसिस्टम, प्रक्रिया वातावरण और कमांड बनाने हेतु कमांडलाइन विकल्पों का उपयोग कर सकते हैं।

स्रोत कोड में एक बड़ी demo स्क्रिप्ट है, लेकिन यहाँ एक संक्षिप्त संस्करण दिया गया है जो होस्ट के /usr का पुनः उपयोग करके एक नया शेल चलाता है।

bwrap \
    --ro-bind /usr /usr \
    --symlink usr/lib64 /lib64 \
    --proc /proc \
    --dev /dev \
    --unshare-pid \
    --new-session \
    bash

यह एक अधूरा उदाहरण है, लेकिन चित्रण के उद्देश्यों के लिए उपयोगी है। अधिकतर, होस्ट के फाइलसिस्टम ट्री का उपयोग करके कंटेनर बनाने के बजाय, आप किसी chroot को लक्षित करना चाहते हैं। वहाँ, tmpfs में सिमलिंक lib64 -> usr/lib64 बनाने के बजाय, आपने इसे पहले ही लक्षित rootfs में बना लिया होगा।

सैंडबॉक्सिंग

bubblewrap का लक्ष्य किसी एप्लिकेशन को सैंडबॉक्स में चलाना है, जहाँ उसकी ऑपरेटिंग सिस्टम के कुछ हिस्सों या होम डायरेक्टरी जैसे उपयोगकर्ता डेटा तक सीमित पहुँच हो।

bubblewrap हमेशा एक नया mount नेमस्पेस बनाता है, और उपयोगकर्ता ठीक-ठीक निर्दिष्ट कर सकता है कि फाइलसिस्टम के कौन से हिस्से सैंडबॉक्स में दिखाई देने चाहिए। आपके द्वारा निर्दिष्ट ऐसी कोई भी डायरेक्टरी डिफ़ॉल्ट रूप से nodev माउंट होती है, और उन्हें readonly बनाया जा सकता है।

इसके अतिरिक्त आप इन कर्नेल सुविधाओं का उपयोग कर सकते हैं:

उपयोगकर्ता नेमस्पेस (CLONE_NEWUSER): यह सैंडबॉक्स से वर्तमान uid और gid को छोड़कर सब कुछ छिपा देता है। आप यह भी बदल सकते हैं कि सैंडबॉक्स में uid/gid का मान क्या होना चाहिए।

IPC नेमस्पेस (CLONE_NEWIPC): सैंडबॉक्स को सभी विभिन्न प्रकार के IPC की अपनी प्रति मिलेगी, जैसे SysV साझा मेमोरी और सेमाफोर।

PID नेमस्पेस (CLONE_NEWPID): सैंडबॉक्स सैंडबॉक्स के बाहर की किसी भी प्रक्रिया को नहीं देखेगा। इसके अतिरिक्त, bubblewrap आपके कंटेनर के अंदर एक साधारण pid1 चलाएगा ताकि सैंडबॉक्स में चाइल्ड प्रक्रियाओं को reap करने की आवश्यकताओं को संभाला जा सके। यह उस समस्या से बचाता है जिसे अब Docker pid 1 problem के रूप में जाना जाता है।

नेटवर्क नेमस्पेस (CLONE_NEWNET): सैंडबॉक्स नेटवर्क नहीं देखेगा। इसके बजाय उसका अपना नेटवर्क नेमस्पेस होगा जिसमें केवल एक loopback डिवाइस होगा।

UTS नेमस्पेस (CLONE_NEWUTS): सैंडबॉक्स का अपना होस्टनाम होगा।

Seccomp फ़िल्टर: आप seccomp फ़िल्टर पास कर सकते हैं जो सीमित करते हैं कि सैंडबॉक्स में कौन से syscall किए जा सकते हैं। अधिक जानकारी के लिए, Seccomp देखें।

सीमाएँ

जैसा कि ऊपर सैंडबॉक्स सुरक्षा अनुभाग में उल्लेख किया गया है, सैंडबॉक्स की गई प्रक्रियाओं और होस्ट सिस्टम के बीच सुरक्षा का स्तर पूरी तरह से bubblewrap को दिए गए तर्कों द्वारा निर्धारित होता है। कुछ पहलू जिन पर विशेष ध्यान देने की आवश्यकता है, यहाँ नोट किए गए हैं।

• यदि आप seccomp फ़िल्टर का उपयोग करके TIOCSTI कमांड को फ़िल्टर नहीं कर रहे हैं, तो सैंडबॉक्स के बाहर कमांड निष्पादन से सुरक्षा के लिए argument --new-session आवश्यक है (देखें CVE-2017-5226)।

• सैंडबॉक्स में माउंट की गई हर चीज़ का उपयोग संभावित रूप से विशेषाधिकार बढ़ाने के लिए किया जा सकता है। उदाहरण के लिए, यदि आप सैंडबॉक्स में D-Bus सॉकेट बाइंड करते हैं, तो इसका उपयोग systemd के माध्यम से कमांड निष्पादित करने के लिए किया जा सकता है। आप D-Bus संचार को फ़िल्टर करने के लिए xdg-dbus-proxy का उपयोग कर सकते हैं।

• कुछ एप्लिकेशन अपने स्वयं के सैंडबॉक्सिंग तंत्र तैनात करते हैं, और ये bubblewrap की सैंडबॉक्सिंग द्वारा लगाई गई बाधाओं से सीमित हो सकते हैं। उदाहरण के लिए, कुछ वेब ब्राउज़र जो अपनी चाइल्ड प्रक्रियाओं को seccomp के माध्यम से कॉन्फ़िगर करते हैं ताकि उनके पास फाइलसिस्टम तक पहुँच न हो। यदि आप syscalls को सीमित करते हैं और seccomp syscall की अनुमति नहीं देते हैं, तो ब्राउज़र इन प्रतिबंधों को लागू नहीं कर सकता। इसी तरह, यदि ये नियम किसी ऐसी फ़ाइल में संकलित किए गए थे जो सैंडबॉक्स में उपलब्ध नहीं है, तो ब्राउज़र इन नियमों को इस फ़ाइल से लोड नहीं कर सकता और इन प्रतिबंधों को लागू नहीं कर सकता।

संबंधित प्रोजेक्ट तुलना: Firejail

Firejail bubblewrap के अलग किए जाने से पहले के Flatpak के समान है, क्योंकि यह एक setuid उपकरण को बहुत सारी डेस्कटॉप-विशिष्ट सैंडबॉक्सिंग सुविधाओं के साथ जोड़ता है। उदाहरण के लिए, Firejail Pulseaudio के बारे में जानता है, जबकि bubblewrap नहीं जानता।

bubblewrap लेखकों का मानना है कि एक छोटे setuid प्रोग्राम का ऑडिट करना बहुत आसान है, और Pulseaudio फ़िल्टरिंग जैसी सुविधाओं को एक सामान्य प्रक्रिया के रूप में रखना चाहिए, जैसा कि अब Flatpak में होता है।

साथ ही, @cgwalters सोचते हैं कि फ़ाइल पथों को whitelist करना एक बुरा विचार है, क्योंकि उपयोगकर्ताओं के पास पथों में हेरफेर करने के असंख्य तरीके होते हैं, और सिस्टम एडमिनिस्ट्रेटर सिस्टम को कॉन्फ़िगर करने के असंख्य तरीके होते हैं। bubblewrap दृष्टिकोण केवल कुछ विशिष्ट Linux क्षमताओं जैसे CAP_SYS_ADMIN को बनाए रखना है, लेकिन फाइलसिस्टम तक हमेशा invoking uid के रूप में पहुँचना है। यह TOCTTOU हमलों और इसी तरह के हमलों को पूरी तरह से समाप्त कर देता है।

संबंधित प्रोजेक्ट तुलना: Sandstorm.io

Sandstorm.io को अपना सैंडबॉक्स स्थापित करने के लिए सामान्य उपयोगकर्ता नेमस्पेस की आवश्यकता होती है, हालाँकि इसे setuid मोड में संचालित करने के लिए भी आसानी से अनुकूलित किया जा सकता है। @cgwalters का मानना है कि उनका कोड काफी अच्छा है, लेकिन bubblewrap पर एकीकृत होना अभी भी समझ में आ सकता है। हालाँकि, @kentonv (Sandstorm के) को लगता है कि यद्यपि यह सिद्धांत रूप में समझ में आता है, लेकिन अभी के लिए स्विच करने की लागत व्यावहारिक लाभों से अधिक है। यह निर्णय भविष्य में फिर से मूल्यांकित किया जा सकता है, लेकिन आज इसे सक्रिय रूप से आगे नहीं बढ़ाया जा रहा है।

संबंधित प्रोजेक्ट तुलना: runc/binctr

runC वर्तमान में rootless containers का समर्थन करने पर काम कर रहा है, जिसमें runC की स्थापना (setuid के बजाय सामान्य उपयोगकर्ता नेमस्पेस का उपयोग करके), कंटेनरों के निर्माण और प्रबंधन के दौरान setuid या किसी अन्य विशेषाधिकार की आवश्यकता नहीं होती है। हालाँकि, runC का उपयोग करने का मानक तरीका systemd nspawn के समान है, क्योंकि यह root द्वारा आहूत किए जाने के लिए अभिप्रेत टूलिंग है।

bubblewrap लेखकों का मानना है कि runc और systemd-nspawn को setuid बनाने के लिए डिज़ाइन नहीं किया गया है, और वे ऐसे मोड का समर्थन करने से दूर हैं। हालाँकि, rootless containers के साथ, runC उन कुछ उपयोग-मामलों को पूरा करने में सक्षम होगा जिन्हें bubblewrap समर्थन करता है (एक मानकीकृत और पूर्ण OCI रनटाइम होने का अतिरिक्त लाभ भी)।

binctr केवल runC का एक रैपर है, इसलिए इसे इसके सभी डिज़ाइन ट्रेडऑफ़ विरासत में मिलते हैं।

नाम की बात क्या है?!

bubblewrap नाम यह बताने के लिए चुना गया था कि यह उपकरण एप्लिकेशन के पैरेंट के रूप में चलता है (इसलिए किसी अर्थ में इसे लपेटता है) और इसके चारों ओर एक सुरक्षात्मक परत (सैंडबॉक्स) बनाता है।

(Bubblewrap बिल्ली: dancing_stupidity द्वारा)