मुझे लगता है कि आपके प्रश्न के कई विवरण समान रूप से लागू हो सकते हैं avahi-daemon, जिन्हें मैंने हाल ही में देखा था। (मैं एक और विस्तार याद कर सकते हैं कि हालांकि अलग है)। एवोही-डेमॉन को चेरोट में चलाने के कई फायदे हैं, अगर एवाही-डेमन से समझौता किया जाता है। इसमें शामिल है:
- यह किसी भी उपयोगकर्ता के घर निर्देशिका को नहीं पढ़ सकता है और निजी जानकारी को बाहर निकाल सकता है।
- यह / tmp लिखकर अन्य कार्यक्रमों में बग का दोहन नहीं कर सकता है। इस तरह के कीड़े की कम से कम एक पूरी श्रेणी है। जैसे https://www.google.co.uk/search?q=tmp+race+security+bug
- यह किसी भी यूनिक्स सॉकेट फ़ाइल को नहीं खोल सकता है, जो चेरोट के बाहर है, जिस पर अन्य डेमॉन संदेश सुन और पढ़ सकते हैं।
बिंदु 3 विशेष रूप से अच्छा हो सकता है जब आप डब या समान का उपयोग नहीं कर रहे हैं ... मुझे लगता है कि अवही-डेमन डब का उपयोग करता है, इसलिए यह सुनिश्चित करता है कि सिस्टम डब का उपयोग चुरोट के अंदर से भी किया जाए। यदि आपको सिस्टम डब पर संदेश भेजने की क्षमता की आवश्यकता नहीं है, तो इस बात से इनकार करते हुए कि क्षमता काफी अच्छी सुरक्षा सुविधा हो सकती है।
सिस्टमड यूनिट फ़ाइल के साथ इसे प्रबंधित करना
ध्यान दें कि अगर अवही-डेमॉन को फिर से लिखा गया था, तो यह संभवतः सुरक्षा के लिए सिस्टमड पर भरोसा करने और उदाहरण के लिए उपयोग करने के लिए चुन सकता है ProtectHome। मैंने इन सुरक्षा को अतिरिक्त परत के रूप में जोड़ने के लिए अवही-डेमॉन में बदलाव का प्रस्ताव रखा, साथ ही कुछ अतिरिक्त सुरक्षा प्रदान की जो चेरोट द्वारा गारंटीकृत नहीं हैं। आप मेरे द्वारा प्रस्तावित विकल्पों की पूरी सूची देख सकते हैं:
https://github.com/lathiat/avahi/pull/181/commits/67a7b10049c58d6afeebdc64ffd2023c5a93d49a
ऐसा लगता है कि अधिक प्रतिबंध हैं जो मैं इस्तेमाल कर सकता था अगर अवही-डेमन खुद चेरोट का उपयोग नहीं करते थे, जिनमें से कुछ का उल्लेख प्रतिबद्ध संदेश में किया गया है। मुझे यकीन नहीं है कि यह कितना लागू होता है।
ध्यान दें, मेरे द्वारा उपयोग किए जाने वाले प्रोटेक्शन ने डेमॉन को यूनिक्स सॉकेट फाइल (प्वाइंट 3 ऊपर) खोलने से सीमित नहीं किया होगा।
एक अन्य दृष्टिकोण SELinux का उपयोग करना होगा। हालाँकि आप अपने एप्लिकेशन को लिनक्स वितरण के उस उप-सेट से बांधना चाहेंगे। यहाँ मैंने SELinux के बारे में सकारात्मक रूप से सोचा, इसका कारण यह है कि SELinux उस पहुँच को प्रतिबंधित करता है, जो प्रक्रियाओं को ठीक-ठाक तरीके से dbus में रखती है। उदाहरण के लिए, मुझे लगता है कि आप अक्सर उम्मीद कर सकते हैं कि systemdबस नाम की सूची में नहीं होगा जो आपको संदेश भेजने के लिए सक्षम होना चाहिए :-)।
"मैं सोच रहा था, अगर सिस्टमड सैंडबॉक्सिंग का उपयोग चेरोट / सेतुइड / उमस्क / ... से अधिक सुरक्षित हो ..."
सारांश: दोनों क्यों नहीं? चलो ऊपर थोड़ा सा डिकोड करें।
यदि आप बिंदु 3 के बारे में सोचते हैं, तो चेरोट का उपयोग करना अधिक कारावास प्रदान करता है। प्रोटेक्टहोम = और उसके दोस्त भी चेरोट के रूप में प्रतिबंधक बनने की कोशिश नहीं करते हैं। (उदाहरण के लिए, कोई भी नामित सिस्टमडाल विकल्प ब्लैकलिस्ट नहीं करता है /run, जहां हम यूनिक्स सॉकेट फाइलें डालते हैं)।
चेरोट से पता चलता है कि फाइलसिस्टम एक्सेस को प्रतिबंधित करना एक बहुत शक्तिशाली हो सकता है, लेकिन लिनक्स पर सब कुछ फ़ाइल :-) नहीं है। सिस्टमड विकल्प हैं जो अन्य चीजों को प्रतिबंधित कर सकते हैं, जो फाइलें नहीं हैं। यह उपयोगी है यदि प्रोग्राम से छेड़छाड़ की जाती है, तो आप इसके लिए उपलब्ध कर्नेल सुविधाओं को कम कर सकते हैं, जो इसमें भेद्यता का फायदा उठाने की कोशिश कर सकता है। उदाहरण के लिए अवही-डेमन को ब्लूटूथ सॉकेट की आवश्यकता नहीं है और मुझे लगता है कि आपका वेब सर्वर या तो नहीं है। :-)। इसलिए इसे AF_BLUETOOTH पता परिवार तक पहुँच न दें। RestrictAddressFamilies=विकल्प का उपयोग करते हुए बस श्वेतसूची AF_INET, AF_INET6, और शायद AF_UNIX ।
आपके द्वारा उपयोग किए जाने वाले प्रत्येक विकल्प के लिए डॉक्स पढ़ें। कुछ विकल्प दूसरों के साथ संयोजन में अधिक प्रभावी हैं, और कुछ सभी सीपीयू आर्किटेक्चर पर उपलब्ध नहीं हैं। (इसलिए नहीं कि सीपीयू खराब है, बल्कि इसलिए कि उस सीपीयू के लिए लिनक्स पोर्ट अच्छी तरह से डिज़ाइन नहीं किया गया था। मुझे लगता है)।
(यहां एक सामान्य सिद्धांत है। यह अधिक सुरक्षित है यदि आप उन चीज़ों की सूची लिख सकते हैं जिन्हें आप अनुमति देना चाहते हैं, न कि आप जिसे अस्वीकार करना चाहते हैं। जैसे कि एक कैरोट को परिभाषित करने से आपको उन फ़ाइलों की एक सूची मिलती है जिन्हें आप एक्सेस करने की अनुमति देते हैं, और यह अधिक मजबूत है। यह कहने से कि आप ब्लॉक करना चाहते हैं /home)।
सिद्धांत रूप में, आप setuid () से पहले खुद पर सभी समान प्रतिबंध लागू कर सकते हैं। यह सब सिर्फ कोड है जिसे आप सिस्टमड से कॉपी कर सकते हैं। हालांकि, सिस्टमड यूनिट विकल्पों को लिखने में काफी आसान होना चाहिए, और चूंकि वे एक मानक प्रारूप में हैं, इसलिए उन्हें पढ़ना और समीक्षा करना आसान होना चाहिए।
इसलिए मैं man systemd.execआपके लक्ष्य प्लेटफ़ॉर्म पर सैंडबॉक्सिंग अनुभाग के माध्यम से पढ़ने की अत्यधिक अनुशंसा कर सकता हूं । लेकिन अगर आप सबसे सुरक्षित डिजाइन चाहते हैं, तो मैं आपके कार्यक्रम में भीchroot (और फिर rootविशेषाधिकार छोड़ ) कोशिश करने से नहीं डरूंगा । यहाँ एक व्यापार है। अपने समग्र डिजाइन पर कुछ बाधाओं का उपयोग करना । यदि आपके पास पहले से ही एक डिज़ाइन है जो चेरोट का उपयोग करता है, और ऐसा लगता है कि आपको क्या चाहिए, तो यह बहुत अच्छा लगता है।chroot