लिनक्स पर संभवतः हानिकारक कार्यक्रम का निष्पादन

Question

मैं एक कार्यक्रम लिख रहा हूं जो छात्रों द्वारा लिखे गए कार्यक्रमों का परीक्षण करेगा। मुझे डर है कि मैं उन पर भरोसा नहीं कर सकता और मुझे यह सुनिश्चित करने की आवश्यकता है कि इसे चलाने वाले कंप्यूटर के लिए यह बुरी तरह समाप्त नहीं होगा।

मैं सिस्टम के संसाधनों तक सीमित पहुंच के साथ कुछ क्रैश टेस्ट उपयोगकर्ता बनाने और उस उपयोगकर्ता के रूप में कार्यक्रम चलाने के बारे में सोच रहा था, लेकिन मैंने अब तक नेट पर जो पाया है, उससे वर्चुअल सिस्टम बनाना सबसे सुरक्षित विकल्प होगा ...

क्या कोई मुझे सही दृष्टिकोण चुनने में मदद कर सकता है? मेरे लिए सुरक्षा एक बड़ी चिंता है। दूसरी ओर, मुझे ऐसा समाधान नहीं चाहिए जो बहुत अधिक समय व्यर्थ कर दे और कुछ सीखने की कोशिश कर रहा हो, जिसकी मुझे वास्तव में आवश्यकता नहीं है।

Comments

बस ब्राउजर में प्रोग्राम को लिनक्स में चलाएं ( bellard.org/jslinux )। यह एक बहुत अच्छा सैंडबॉक्स है। :)

— फिक्सि

वाह, यह वास्तव में दिलचस्प है! हालाँकि मुझे इसका उपयोग करने के लिए कुछ प्रकार के इंटरफ़ेस को लिखना होगा (चूंकि पूरी प्रक्रिया स्वचालित होने वाली है) ... मुझे इसकी जांच करने की आवश्यकता है। अगर यह पता चलता है कि यह जावास्क्रिप्ट लिनक्स गैजेट से अधिक है तो मैं भी इसका उपयोग कर सकता हूं।

— कोर्डा

मैंने वास्तव में अपनी टिप्पणी को एक मजाक के रूप में लिया था, लेकिन अगर आप वास्तव में इसका उपयोग कर सकते हैं, तो यह आश्चर्यजनक होगा। ईमानदारी से, LiveCD उत्तर (रैमडिस्क के साथ) एक महान समाधान है।

— फिक्सि नोव

खैर, अगर मैं इसका उपयोग करने का प्रबंधन करूंगा तो मैं इसका उपयोग वेबपेज पर भी करूंगा, जिस पर मैं परिणाम प्राप्त कर सकता हूं - जो वास्तव में अच्छा और आरामदायक होगा। इसके अलावा गीक फैक्टर मायने रखता है;) भी लाइव डिस्क विकल्प नहीं है - जैसा कि मैंने कहा कि मैं प्रोग्राम बना रहा हूं यह कुछ सर्वर पर चलेगा इसलिए रिबूट कुछ ऐसा नहीं है जिसे मैं बर्दाश्त कर सकता हूं ... मुझे लगता है कि मैं वैसे भी वर्चुअल मशीन के साथ चिपका रहूंगा। ..

— कोर्डा

Answer 1

• वर्चुअल मशीन आपको रिबूट के बिना उच्चतम सुरक्षा दे सकती है, लेकिन सबसे कम प्रदर्शन।

• एक और विकल्प, वर्चुअल मशीन की तुलना में अधिक सुरक्षा के लिए: हार्ड ड्राइव तक पहुंच के बिना "लाइव" सीडी / डीवीडी / पेनड्राइव को बूट करें (अस्थायी रूप से BIOS में एचडीडी को अक्षम करें; यदि आप नहीं कर सकते हैं, तो कम से कम ड्राइव को माउंट न करें / इसे अनमाउंट करें, यदि स्वचालित रूप से माउंट किया जाता है - लेकिन यह बहुत कम सुरक्षित है)

• एक डॉकटर कंटेनर पूर्ण वर्चुअल मशीन के लिए थोड़ा कम सुरक्षित विकल्प है। संभवतः इन दोनों के बीच महत्वपूर्ण अंतर (सुरक्षा के संदर्भ में) यह है कि डॉक में चलने वाले सिस्टम वास्तव में आपके मेजबान सिस्टम के कर्नेल का उपयोग करते हैं।

• ऐसे कार्यक्रम हैं जो अलग-थलग हैं जो एक विशेष, सुरक्षित वातावरण बनाएंगे - इसे आम तौर पर सैंडबॉक्स कहा जाता है - वे आमतौर पर चिरोट-आधारित होते हैं, अतिरिक्त पर्यवेक्षण के साथ - एक ऐसा होता है जो आपको फिट बैठता है।

• एक साधारण चुरोट कम से कम सुरक्षित होगा (esp, कार्यक्रमों को निष्पादित करने के संबंध में), हालांकि शायद थोड़ा तेज हो, लेकिन ... आपको एक अलग पेड़ की जड़ बनाने / उसकी नकल करने और /devआदि के लिए बाइंड माउंट का उपयोग करने की आवश्यकता होगी ( नोट देखें) 1 नीचे!)। तो सामान्य तौर पर, इस दृष्टिकोण की सिफारिश नहीं की जा सकती है, खासकर यदि आप अधिक सुरक्षित, और अक्सर स्थापित करने के लिए आसान उपयोग कर सकते हैं, sandboxपर्यावरण।

नोट 0: एक "विशेष उपयोगकर्ता" के पहलू के लिए,nobodyखाते कीतरह: यह शायद ही कोई सुरक्षादेता है, एक साधारण से भी बहुत कमchroot। एकnobodyउपयोगकर्ता अभी भी उन फ़ाइलों और कार्यक्रमों तक पहुंच सकता है जो पढ़ चुके हैं और अन्य के लिए निर्धारित अनुमतियों को निष्पादित करते हैं । आप इसके साथ परीक्षण कर सकते हैंsu -s /bin/sh -c 'some command' nobody। और यदि आपके पास कोई कॉन्फ़िगरेशन / इतिहास / कैश फ़ाइल किसी के पास (किसी गलती या मामूली सुरक्षा छेद) तक पहुंच योग्य है, तो एक प्रोग्राम जो चल रहाnobodyहै, वह इसे एक्सेस कर सकता है, गोपनीय डेटा के लिए grep (जैसे "पास =" आदि) और में कई तरीके इसे नेट पर या जो भी भेजते हैं।

नोट 1: जैसा कि गिल्स ने नीचे टिप्पणी में कहा है, एक साधारण चिरोट वातावरण विशेषाधिकार वृद्धि के उद्देश्य से होने वाले कारनामों के खिलाफ बहुत कम सुरक्षा देगा। एक एकमात्र chroot भावना सुरक्षा के लिहाज से बना देता है, केवल तभी पर्यावरण कम है, सुरक्षा-की पुष्टि कार्यक्रमों से मिलकर केवल (लेकिन अभी भी संभावित कर्नेल-स्तर कमजोरियों का शोषण करने का जोखिम रहता है), और सब अविश्वसनीय chroot में चल रहे कार्यक्रमों के द्वारा चलाए जा रहे एक उपयोगकर्ता के रूप में जो चेरोट के बाहर किसी भी प्रक्रिया को नहीं चलाता है। चेरोट किसके खिलाफ (यहां उल्लिखित प्रतिबंधों के साथ) को रोकता है, विशेषाधिकार वृद्धि के बिना प्रत्यक्ष प्रणाली पैठ है। हालाँकि, जैसा कि गिल्स ने एक अन्य टिप्पणी में उल्लेख किया है, यहां तक ​​कि सुरक्षा के स्तर को दरकिनार किया जा सकता है, जिससे एक कार्यक्रम को चेरोट से बाहर निकलने की अनुमति मिलती है।

Comments

जवाब के लिए धन्यवाद। जब मैं इस तरह से सामान की बात करता हूं तो मैं एक वास्तविक न्यूब हूं, क्या आप मुझे एक बात समझा सकते हैं: मुझे प्रोग्राम को सिस्टम में फ़ाइलों को पढ़ने से रोकने की आवश्यकता क्यों है (उदाहरण के लिए चेरोट द्वारा)? (यदि प्रोग्राम उन्हें संशोधित नहीं कर सकता है)।

— कोर्डा

एक दुर्घटना उपयोगकर्ता परीक्षण खाते क्या आप वाकई लिए कुछ बुनियादी सुरक्षा देता है। फिर भी ऐसी कई चीजें हैं जिन्हें आप रोक सकते हैं / रोकना चाहते हैं। वे कार्यक्रम या कुछ सामाजिक हैकिंग, भविष्य के दूरदराज के हमले के उद्देश्य के लिए जानकारी इकट्ठा करने में आम कमजोरियों के कारनामों के रूप में हो सकते हैं ... और शायद बहुत कुछ।

— रोज़ज़ेट्रिएवेज़ेज़

हम क्यों हैं: क्या इंटरनेट कनेक्शन का उपयोग करने से उपयोगकर्ता को रोकने का एक तरीका है?

— कोर्डा

मुझे आश्चर्य है कि अगर nobodyइंटरनेट का उपयोग हो।

— कोर्डा

@rozcietrzewiacz किसी भी सुरक्षा प्रदान करने के लिए चेरोट के लिए एक महत्वपूर्ण आवश्यकता एक चेरोटेड प्रोग्राम को एक उपयोगकर्ता के रूप में नहीं चलाना है जो चेरोट के बाहर एक प्रोग्राम भी चला रहा है। अन्यथा चिरोषित प्रक्रिया एक गैर-संकलित प्रक्रिया को विराम दे सकती है और इस तरह से कुछ भी कर सकती है।

— गिल्स एसओ- बुराई को रोकना '

Answer 2

वर्चुअल मशीन का उपयोग करें। कम कुछ भी ज्यादा सुरक्षा प्रदान नहीं करता है।

कुछ साल पहले मैंने सुझाव दिया है कि एक क्रोकेटेड समर्पित उपयोगकर्ता या ऐसा कुछ हो सकता है। लेकिन हार्डवेयर अधिक शक्तिशाली हो गया है, और वर्चुअल मशीन सॉफ्टवेयर का उपयोग करना आसान हो गया है। इसके अलावा, ऑफ-द-शेल्फ हमले अधिक परिष्कृत हो गए हैं। यहाँ पूरे रास्ते नहीं जाने का कोई कारण नहीं है।

मैं VirtualBox को चलाने की सलाह दूंगा। आप वर्चुअल मशीन को एक-दो मिनट में सेट कर सकते हैं, फिर उसके अंदर लिनक्स वितरण स्थापित कर सकते हैं। केवल गैर-डिफ़ॉल्ट सेटअप जो मैं सुझाता हूं वह नेटवर्किंग सेटअप है: "NAT" इंटरफ़ेस (दुनिया के साथ संवाद करने के लिए) और "होस्ट केवल" इंटरफ़ेस दोनों बनाएं (ताकि आप आसानी से और होस्ट से फ़ाइलों की प्रतिलिपि बना सकें, और ssh में वीएम)। जब आप अपने छात्रों के कार्यक्रम चलाते हैं तो NAT इंटरफ़ेस को अक्षम करें; इसे तभी सक्षम करें जब आप सॉफ़्टवेयर पैकेज स्थापित या अपग्रेड कर रहे हों।

वर्चुअल मशीन के अंदर, प्रति छात्र एक उपयोगकर्ता बनाएं।

¹ _{आप NAT इंटरफ़ेस को उपयोगकर्ताओं के श्वेतसूची में सीमित कर सकते हैं, लेकिन यह एक साधारण, टू-द-पॉइंट सेटअप की आवश्यकता से अधिक उन्नत है।}

Answer 3

यहाँ पर बहुत गहन व्याख्या है कि चेरोट का उपयोग करना अभी भी एक बहुत ही व्यवहार्य विकल्प क्यों है, और क्यों पूर्ण ऑपरेटिंग सिस्टम या पूर्ण हार्डवेयर वर्चुअलाइजेशन विशेष रूप से विशिष्ट परिदृश्यों में ओवरकिल है।

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

आम धारणा के विपरीत, हर स्थिति को ऑपरेटिंग सिस्टम के पूर्ण वर्चुअलाइजेशन या हार्डवेयर के पूर्ण सिमुलेशन की आवश्यकता नहीं होती है। यह वास्तव में कोशिश और कवर करने के लिए और अधिक हमले की सतह होने का मतलब है । बदले में, एक कम सुरक्षित प्रणाली का अर्थ है । (कम-जानकार प्रणाली प्रशासकों के लिए जानबूझकर)

नियम काफी सरल हैं: चुरोट के अंदर ऐसा कुछ भी न डालें जो आवश्यक नहीं है। रूट के रूप में डेमॉन न चलाएं। चेरोट के बाहर डेमॉन चलाने वाले किसी भी उपयोगकर्ता के रूप में डेमॉन न चलाएं।

किसी भी असुरक्षित एप्लिकेशन, सेट्यूड बायनेरिज़ को हटा दें, मालिक की सहानुभूति / हार्डलिंक झूलने लगेंगे। नोसिड, नोएसेक और नोडव का उपयोग करके अनावश्यक फ़ोल्डर्स को हटाएं। स्रोत से चल रहे डेमन के नवीनतम स्थिर संस्करण का निर्माण करें। और सबसे बढ़कर, आधार प्रणाली को सुरक्षित करना!

Answer 4

मैं इसे जोड़ने जा रहा हूं, इस सवाल का आधिकारिक रूप से जवाब दिए जाने के बाद: मैग्आईसी: दुर्भावनापूर्ण एजिंग इन सर्किट्स / कोर्स , जो दुर्भाग्य से एसीएम के भुगतान के पीछे बंद है। कागज का अपशॉट यह है कि उपयोग के दौरान आज की आयु में सर्किट में बहुत छोटी चौड़ाई का पता चलता है, और अंततः टूट जाता है। सही निर्देश (ओं) को खोजने और उन्हें बार-बार दोहराने से एक हमलावर तेजी से असफल होने के लिए ICs की उम्र कर सकता है।

वीएम या सैंडबॉक्स या कंटेनर या चेरोट जेल में से कोई भी हार्डवेयर के इस तरह के दुर्भावनापूर्ण विनाश को नहीं रोक सकेगा। कागज के लेखकों को ऐसे निर्देश अनुक्रम, और प्रयोगात्मक रूप से वृद्ध हार्डवेयर विफलता के लिए मिला, लेकिन उन्होंने निर्देशों को दूर नहीं किया, इसलिए यह थोड़ी देर के लिए वास्तविक खतरा नहीं हो सकता है।

Answer 5

बीएसडी व्युत्पन्न यूनिक्स (मैक ओएस एक्स सहित) पर एक सुविधा है sandbox। मेनपेज कहता है

वर्णन सैंडबॉक्स सुविधा अनुप्रयोगों स्वेच्छा से ऑपरेटिंग सिस्टम के संसाधनों तक उनकी पहुंच को प्रतिबंधित करने की अनुमति देता है। इस सुरक्षा तंत्र का इरादा उस घटना में संभावित नुकसान को सीमित करना है जो एक भेद्यता का फायदा उठाती है। यह अन्य ऑपरेटिंग सिस्टम एक्सेस कंट्रोल के लिए प्रतिस्थापन नहीं है।

यह उस chrootसुविधा से अलग है जो उपलब्ध भी है।