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