अधिक समान Qs अधिक ध्यान देने योग्य उत्तर के साथ:
नोट: वहां दिए गए कुछ उत्तर विशिष्ट समाधानों की ओर इशारा करते हैं जो अभी तक यहां उल्लेखित नहीं हैं।
असल में, अलग-अलग कार्यान्वयन के साथ काफी कुछ जेलिंग टूल हैं, लेकिन उनमें से कई या तो डिजाइन द्वारा सुरक्षित नहीं हैं (जैसे fakeroot, LD_PRELOAD-बेड), या पूरा नहीं (जैसे fakeroot-ng, -बेडptrace ), या रूट की आवश्यकता होगी ( chrootया, या नकलीचोटplash पर उल्लेख किया गया है ) चेतावनी लेबल )।
ये सिर्फ उदाहरण हैं; मैंने इन 2 विशेषताओं ("भरोसा किया जा सकता है?", "सेट अप करने के लिए रूट की आवश्यकता है") के संकेत के साथ, उन्हें सभी साइड-बाय-साइड सूचीबद्ध करने का सोचा, शायद ऑपरेटिंग-सिस्टम-स्तरीय वर्चुअलाइजेशन कार्यान्वयन पर ।
सामान्य तौर पर, वहाँ के उत्तर संभावनाओं की पूर्ण वर्णित सीमा और उससे भी अधिक को कवर करते हैं:
वर्चुअल मशीन / ओएस
कर्नेल एक्सटेंशन (SELinux की तरह)
- (यहां टिप्पणियों में उल्लेख किया गया है),
chroot
चेरोट-आधारित सहायक (जो कि हालांकि रूट सेट किया जाना चाहिए, क्योंकि chrootरूट की आवश्यकता होती है; या शायद chrootएक अलग नामस्थान में काम कर सकता है - नीचे देखें):
[उनके बारे में थोड़ा और बताने के लिए!]
ज्ञात चुरोट-आधारित अलगाव उपकरण:
- इसके
hsh-runऔर hsh-shellआदेशों के साथ हैशर । ( हैशर को एक सुरक्षित और दोहराने योग्य तरीके से सॉफ़्टवेयर बनाने के लिए डिज़ाइन किया गया था।)
- एक अन्य जवाब में विद्वानों का उल्लेख है
- ...
ptrace
एक और भरोसेमंद अलगाव समाधान ( एक-केseccomp अलावा एक ) के माध्यम से पूरा syscall- अवरोधन होगा ptrace, जैसा कि मैनपेज में बताया गया है fakeroot-ng:
पिछले कार्यान्वयनों के विपरीत, फ़ेकरूट-एनजी एक ऐसी तकनीक का उपयोग करता है जो पता लगाने की प्रक्रिया को छोड़ देता है कि वह फ़ेकरूट-एनजी की "सेवाओं" का उपयोग करेगा या नहीं। किसी प्रोग्राम को स्टेटिकली कंपाइल करना, सीधे कर्नेल को कॉल करना और खुद के एड्रेस स्पेस को मैनिपुलेट करना ये सभी तकनीकें हैं जिनका उपयोग किसी प्रक्रिया पर LD_PRELOAD आधारित नियंत्रण को बायपास करने के लिए किया जा सकता है और फ़ेकरूट-एनजी पर लागू नहीं होता है। यह है, सैद्धांतिक रूप से, इस तरह से fakeroot-ng ढालना संभव के रूप में पता लगाया प्रक्रिया पर कुल नियंत्रण है।
जबकि यह सैद्धांतिक रूप से संभव है, यह नहीं किया गया है। फ़ेकरूट-एनजी कुछ "अच्छी तरह से व्यवहार किया" मान्यताओं के बारे में अनुमान लगाता है कि प्रक्रिया के बारे में पता लगाया जा रहा है, और एक प्रक्रिया जो उन मान्यताओं को तोड़ सकती है, अगर पूरी तरह से बच नहीं सकती है, तो कम से कम कुछ "नकली" वातावरण के लिए इसे fakeroot पर लगाया जाए- एनजी। जैसे, आपको एक सुरक्षा उपकरण के रूप में फ़ेकरूट-एनजी का उपयोग करने के खिलाफ कड़ी चेतावनी दी जाती है। बग रिपोर्ट जो दावा करती है कि एक प्रक्रिया जानबूझकर (जैसा कि अनजाने में विरोध किया गया है) नकली‐ रूट-एनजी के नियंत्रण से बच जाएगी या तो "बग नहीं" या कम प्राथमिकता के रूप में चिह्नित किया जाएगा।
यह संभव है कि इस नीति को भविष्य में पुनर्विचार किया जाए। हालाँकि, कुछ समय के लिए आपको चेतावनी दी गई है।
फिर भी, जैसा कि आप इसे पढ़ सकते हैं, fakeroot-ngखुद को इस उद्देश्य के लिए डिज़ाइन नहीं किया गया है।
(BTW, मुझे आश्चर्य है कि उन्होंने seccompक्रोमियम के बजाय -based दृष्टिकोण का उपयोग करने के लिए क्यों चुना है एक- ptraceआधारित ...)
ऊपर वर्णित उपकरणों में से, मैंने अपने लिए जियोर्डी को नोट किया है, क्योंकि मुझे यह पसंद है कि नियंत्रण कार्यक्रम हास्केल में लिखा गया है।
ज्ञात ptrace- आधारित अलगाव उपकरण:
seccomp
अलगाव को प्राप्त करने का एक ज्ञात तरीका Google क्रोमियम में उपयोग किए जाने वाले seccomp सैंडबॉक्सिंग दृष्टिकोण के माध्यम से है । लेकिन यह दृष्टिकोण यह बताता है कि आप एक सहायक लिखते हैं जो "इंटरसेप्टेड" फ़ाइल एक्सेस और अन्य syscalls के कुछ (अनुमत लोगों) को संसाधित करेगा; और यह भी, निश्चित रूप से, syscalls को "अवरोधन" करने का प्रयास करें और उन्हें सहायक में पुनर्निर्देशित करें (शायद, इसका मतलब यह भी होगा कि नियंत्रित प्रक्रिया के कोड में इंटरसेप्टेड syscalls की जगह के रूप में; इसलिए, यह ध्वनि नहीं करता है; काफी सरल होने के लिए; यदि आप रुचि रखते हैं, तो आप केवल मेरे उत्तर के बजाय विवरणों को पढ़ेंगे)।
अधिक संबंधित जानकारी (विकिपीडिया से):
(अंतिम आइटम दिलचस्प लग रहा है अगर कोई seccompक्रोमियम के बाहर सामान्य- आधारित समाधान की तलाश कर रहा है। "seccomp-nurse" के लेखक से पढ़ने लायक एक ब्लॉग पोस्ट भी है: SECCOMP सैंडबॉक्सिंग समाधान के रूप में ।)
"Seccomp- नर्स" परियोजना से इस दृष्टिकोण का चित्रण :
लिनक्स के भविष्य में एक "लचीला" seccomp संभव है?
2009 में भी लिनक्स कर्नेल को पैच करने के सुझाव दिए गए थे ताकि seccompमोड में अधिक लचीलापन हो - ताकि "कई कलाबाजियां जिनकी हमें वर्तमान में आवश्यकता है, उनसे बचा जा सके"। ("एक्रोबेटिक्स" एक सहायक लिखने की जटिलताओं को संदर्भित करता है जिसे जेल की प्रक्रिया की ओर से कई संभावित निर्दोष syscalls को निष्पादित करना पड़ता है और जेल की प्रक्रिया में संभवतः निर्दोष syscalls को प्रतिस्थापित करना होता है।) LWN लेख ने इस बिंदु पर लिखा है:
एक सुझाव जो सामने आया वह था एक नया "मोड" जोड़ने के लिए seccomp। एपीआई को इस विचार के साथ डिजाइन किया गया था कि विभिन्न अनुप्रयोगों में विभिन्न सुरक्षा आवश्यकताएं हो सकती हैं; इसमें एक "मोड" मान शामिल है जो प्रतिबंधों को निर्दिष्ट करता है जिन्हें जगह में रखा जाना चाहिए। केवल मूल मोड को कभी लागू किया गया है, लेकिन दूसरों को निश्चित रूप से जोड़ा जा सकता है। एक नया मोड बनाना जिसने आरंभ करने की प्रक्रिया को निर्दिष्ट करने की अनुमति दी कि कौन सी सिस्टम कॉल की अनुमति होगी, क्रोम सैंडबॉक्स जैसी स्थितियों के लिए सुविधा को अधिक उपयोगी बना देगा।
एडम लैंगली (Google के भी) ने एक पैच पोस्ट किया है जो कि बस यही करता है। नया "मोड 2" कार्यान्वयन एक बिटमास्क को स्वीकार करता है जो बताता है कि कौन से सिस्टम कॉल सुलभ हैं। यदि उन में से एक prctl () है, तो सैंडबॉक्स कोड अपने स्वयं के सिस्टम कॉल को प्रतिबंधित कर सकता है (लेकिन यह सिस्टम कॉल तक पहुंच को बहाल नहीं कर सकता है जिसे अस्वीकार कर दिया गया है)। सभी ने बताया, यह एक उचित समाधान की तरह दिखता है जो सैंडबॉक्स डेवलपर्स के लिए जीवन को आसान बना सकता है।
उस ने कहा, इस कोड को कभी विलय नहीं किया जा सकता क्योंकि चर्चा अन्य संभावनाओं पर आगे बढ़ी है।
यह "लचीला सेकंडपैक" लिनक्स में वांछित सुविधा प्रदान करने के लिए लिनक्स की संभावनाओं को करीब लाएगा, बिना सहायकों को लिखने की आवश्यकता के बिना जटिल।
(इस उत्तर के रूप में मूल रूप से एक ही सामग्री के साथ एक ब्लॉग पोस्टिंग: http://geofft.mit.edu/blog/sbb/33 ।)
नाम स्थान ( unshare)
नेमस्पेस ( -बेड unshareसॉल्यूशंस ) के माध्यम से अलग करना - यहां उल्लेख नहीं किया गया है - उदाहरण के लिए, माउंटिंग-पॉइंट्स (FUSE के साथ संयुक्त)?
नामस्थानों पर अधिक, अब, जैसा कि उनका कार्यान्वयन पूरा हो चुका है (यह अलगाव तकनीक nme "लिनक्स कंटेनर", या "LXC" के तहत जाना जाता है , है ना? ..):
"नामस्थानों के समग्र लक्ष्यों में से एक कंटेनर के कार्यान्वयन का समर्थन करना है, हल्के वर्चुअलाइजेशन के लिए एक उपकरण (साथ ही अन्य उद्देश्य)" ।
एक नया उपयोगकर्ता नाम स्थान बनाना भी संभव है, ताकि "एक प्रक्रिया में उपयोगकर्ता नामस्थान के बाहर एक सामान्य अनपेक्षित उपयोगकर्ता ID हो सकती है, जबकि एक ही समय में उपयोगकर्ता नाम के अंदर 0 का उपयोगकर्ता ID हो सकता है। इसका मतलब है कि यह प्रक्रिया पूर्ण रूट विशेषाधिकार है। उपयोगकर्ता नामस्थान के अंदर संचालन के लिए, लेकिन नाम स्थान के बाहर संचालन के लिए अनपेक्षित है "।
ऐसा करने के लिए वास्तविक कार्य आदेशों के लिए, निम्न उत्तरों को देखें:
और विशेष उपयोगकर्ता-अंतरिक्ष प्रोग्रामिंग / संकलन
लेकिन ठीक है, ज़ाहिर है, वांछित "जेल" की गारंटी उपयोगकर्ता-अंतरिक्ष में प्रोग्रामिंग से लागू होती है ( ओएस से इस के लिए अतिरिक्त समर्थन के बिना ; शायद यही कारण है कि यह सुविधा ओएसईएस के डिजाइन में पहले स्थान पर शामिल नहीं हुई है। ); अधिक या कम जटिलताओं के साथ।
उल्लेख किया ptrace- या- seccompसैंड सैंडबॉक्सिंग को सैंडबॉक्स-हेल्पर लिखकर गारंटी को लागू करने के कुछ वेरिएंट के रूप में देखा जा सकता है जो आपकी अन्य प्रक्रियाओं को नियंत्रित करेगा, जिसे "ब्लैक बॉक्स" के रूप में माना जाएगा, अनिक्स प्रोग्राम।
एक अन्य दृष्टिकोण प्रोग्रामिंग तकनीकों का उपयोग करना हो सकता है जो उन प्रभावों के बारे में परवाह कर सकते हैं जिन्हें अस्वीकृत होना चाहिए। (यह आपको होना चाहिए जो तब प्रोग्राम लिखते हैं, वे अब ब्लैक बॉक्स नहीं हैं।) एक का उल्लेख करने के लिए, एक शुद्ध प्रोग्रामिंग भाषा का उपयोग करना (जो आपको साइड-इफेक्ट्स के बिना प्रोग्राम करने के लिए मजबूर करेगा) जैसे हास्केल बस सभी प्रभावों को बना देगा प्रोग्राम स्पष्ट है, इसलिए प्रोग्रामर आसानी से सुनिश्चित कर सकता है कि कोई अस्वीकृत प्रभाव नहीं होगा।
मुझे लगता है, कुछ अन्य भाषा, जैसे, जावा में प्रोग्रामिंग के लिए सैंडबॉक्सिंग सुविधाएं उपलब्ध हैं।
इस विषय पर जानकारी जमा करने वाले कुछ पृष्ठों को भी वहां के उत्तरों में इंगित किया गया था: