मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल
कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषयों में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।
व्याख्यान 1: "परिचय: खतरे के मॉडल"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 2: "हैकर हमलों का नियंत्रण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 4: "पृथक्करण का पृथक्करण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?"
भाग 1 /
भाग 2व्याख्यान 6: "अवसर"
भाग 1 /
भाग 2 /
भाग 3 श्रोता: यदि यह
UID इस फ़ाइल को केवल पढ़ने के लिए पहुँच प्रदान करता है, और आपके पास एक फ़ाइल विवरणक भी है, तो यदि आप
UID खो देते हैं, तो क्या आप अभी भी इस फ़ाइल को पढ़ने की अनुमति प्राप्त कर सकते हैं?
प्रोफेसर: हाँ, क्योंकि यह कैटलॉग में दिखाई देगा। क्योंकि जैसे ही आप फ़ाइल में सुविधा जोड़ते हैं, वह यह है। यह आपके लिए विशेष विशेषाधिकार और इतने पर खुला है। लेकिन समस्या यह है कि उनके पास यह हाइब्रिड डिज़ाइन है।
यही है, वे कहते हैं - आप वास्तव में निर्देशिकाओं में सुविधाओं को जोड़ सकते हैं और आप एक नई फ़ाइल खोल सकते हैं, जैसा कि आप समानांतर में काम करते हैं। यह हो सकता है कि आप किसी निर्देशिका जैसे
/ आदि में सुविधा जोड़ दें, लेकिन आपके पास
/ etc निर्देशिका में सभी फ़ाइलों तक पहुँच अनिवार्य नहीं है। लेकिन जैसे ही आप फीचर मोड में प्रवेश करते हैं, आप इन फ़ाइलों को खोलने का प्रयास कर सकते हैं, यह जानते हुए कि आपके पास
/ etc निर्देशिका तक पहुंच है। आखिरकार, यह पहले से ही खुला है, इसलिए आप मुझे इस निर्देशिका में स्थित
"पासवर्ड" नामक फ़ाइल क्यों नहीं देते
हैं ?
और फिर कर्नेल को यह तय करने की आवश्यकता है कि क्या आपको इस निर्देशिका में फ़ाइल को पढ़ने या लिखने की विधि में खोलने की अनुमति है, या आपके पास क्या है। इसलिए मुझे लगता है कि यह एकमात्र ऐसी जगह है जहां आपको अभी भी इस बाहरी विशेषाधिकार की आवश्यकता है, क्योंकि उन्होंने एक संगत डिजाइन बनाने की कोशिश की, जहां उन्होंने निर्देशिकाओं के संचालन का वर्णन करने के लिए प्राकृतिक शब्दार्थ का भी उपयोग नहीं किया। यह एकमात्र जगह की तरह दिखता है जहां
यूनिक्स फाइल सिस्टम स्थापित करने के सिद्धांत बने हुए हैं।
श्रोता: क्या ऐसी कोई और जगहें हैं?
प्रोफेसर: अच्छा सवाल। मुझे लगता है कि जो हो रहा है, उसका पता लगाने के लिए मुझे उनका पिछला स्रोत कोड प्राप्त करना होगा, लेकिन अधिकांश अन्य स्थितियों में वास्तव में
यूआईडी सत्यापन की आवश्यकता नहीं होती है। क्योंकि, उदाहरण के लिए, इसका उपयोग नेटवर्क के लिए नहीं किया जाता है। ये संभवतः सामान्य फ़ाइल सिस्टम ऑपरेशन हैं - यदि आपके पास साझा मेमोरी सेगमेंट है, तो आप इसे और इसे खोलते हैं।
श्रोता: क्या आप फिर से बता सकते हैं कि वास्तव में उपयोगकर्ता आईडी क्या है, अगर आपके पास
क्षमता है?
प्रोफेसर: यह महत्वपूर्ण है जब आपके पास कैटलॉग करने का अवसर हो। सवाल यह है कि यह अवसर आपके सामने क्या है? एक व्याख्या पर विचार करें, उदाहरण के लिए, एक साफ प्रणाली की क्षमताओं की स्थिति,
शिमला मिर्च नहीं। यदि ऐसी प्रणाली में आपके पास निर्देशिका के लिए अवसर है, तो आपके पास इस निर्देशिका में सभी फ़ाइलों तक बिना शर्त पहुंच है।
यूनिक्स पर, यह आमतौर पर मामला नहीं है। आप निर्देशिका को
/ आदि के रूप में खोल सकते हैं, लेकिन इसमें कई सिस्टम फाइलें हैं जिनमें गोपनीय जानकारी संग्रहीत की जा सकती है, उदाहरण के लिए, सर्वर की निजी कुंजी। और इस निर्देशिका के माध्यम से आप खोल सकते हैं और स्क्रॉल कर सकते हैं, इसका मतलब यह नहीं है कि आप इस निर्देशिका में फाइलें नहीं खोल सकते। यही है, निर्देशिका तक पहुंच होने के बाद, आपके पास फ़ाइलों तक पहुंच है।
शिमला मिर्च में , यदि आप
/ etc निर्देशिका को खोलते हैं और फिर फीचर मोड दर्ज करते हैं, तो निम्न होता है। आप कहते हैं: “मुझे नहीं पता कि यह निर्देशिका क्या है। मैं इसमें केवल एक फाइल डिस्क्रिप्टर जोड़ता हूं। " "की" नामक एक फाइल है। आप इस फ़ाइल को
"कुंजी" क्यों नहीं खोलते हैं? सिर्फ इसलिए कि उस समय, आप शायद इस सुविधा-आधारित प्रक्रिया को इस फ़ाइल को खोलने के लिए नहीं चाहते हैं, क्योंकि आपको इसकी आवश्यकता नहीं है। यद्यपि यह आपको फ़ाइल के लिए
यूनिक्स अनुमतियों को बायपास करने की अनुमति देता है।
इसलिए, मुझे लगता है कि इस लेख के लेखकों ने सावधानीपूर्वक एक ऐसी प्रणाली के विकास के लिए संपर्क किया जो मौजूदा सुरक्षा तंत्रों का उल्लंघन नहीं करेगा।
श्रोता: यानी, आप कहते हैं कि कुछ मामलों में आप इन दो सुरक्षा कारकों के संयोजन का उपयोग कर सकते हैं? यही है, हालाँकि उपयोगकर्ता फ़ाइल को निर्देशिका में बदल सकता है, लेकिन वह किस फ़ाइल तक पहुँच प्राप्त करता है यह उसकी उपयोगकर्ता आईडी पर निर्भर करता है?
प्रोफेसर: हाँ, बिल्कुल। व्यवहार में,
शिमला मिर्च में , आपको मोड मोड में जाने से पहले, आपको यह अनुमान लगाना होगा कि आपको बाद में किन फ़ाइलों की आवश्यकता हो सकती है। आपको साझा लाइब्रेरी, पाठ फ़ाइलें, टेम्प्लेट, नेटवर्क कनेक्शन, आदि की आवश्यकता हो सकती है। इसलिए, आप पहले से यह सब खोलते हैं। और यह जानना हमेशा आवश्यक नहीं है कि आपको किस फ़ाइल की आवश्यकता है तो इन लोगों ने इसे इसलिए बनाया ताकि आप डायरेक्टरी के फाइल डिस्क्रिप्टर को खोल सकें और बाद में आपकी जरूरत की फाइलों को देख सकें। हालाँकि, यह हो सकता है कि इन फ़ाइलों में वही अनुमतियाँ न हों जो आपके पास हैं। यह इस कारण से ठीक है कि दो सुरक्षा कारकों के संयोजन का उपयोग किया जाता है - क्षमताओं और उपयोगकर्ता की जांच। तो यह कर्नेल तंत्र का हिस्सा है।
उन्हें
लिबाससिकम जैसे पुस्तकालय की आवश्यकता क्यों है? मुझे लगता है कि दो मुख्य बातें हैं जो वे इस पुस्तकालय में समर्थन करते हैं।
उनमें से एक यह है कि वे
lch_start नामक फ़ंक्शन को कार्यान्वित
करते हैं , जिसे आपको
cap_enter फ़ंक्शन के बजाय उपयोग करना चाहिए। एक अन्य फ़ंक्शन जो
लिबासैपिकम प्रदान करता है, वह है एफडी सूचियों की अवधारणा, जिसका उपयोग संख्याओं द्वारा फ़ाइल
विवरणकों को पारित करने के लिए किया जाता है। इस
fd सूचियों का उद्देश्य स्पष्ट करना आसान है। यह मूल रूप से एक सामान्यीकरण है कि कैसे
यूनिक्स प्रक्रियाओं के बीच फाइल डिस्क्रिप्टर का प्रबंधन और गुजरता है। पारंपरिक
यूनिक्स और
लिनक्स पर , जिसे आप आज उपयोग करते हैं, प्रक्रिया शुरू होने पर कुछ फ़ाइल विवरणकर्ता इसे पास कर देते हैं। आप बस इस तालिका से पूर्णांक मानों के साथ कुछ फ़ाइल डिस्क्रिप्टर खोलते हैं और आपके द्वारा आवश्यक बाल प्रक्रिया शुरू करते हैं। या आप एक विशिष्ट बाइनरी चलाते हैं, और यह इन सभी खुले स्लॉट्स को
fd टेबल में इनहेरिट करता है। हालाँकि, नाम के रूप में संख्याओं का उपयोग करने की तुलना में इन चीजों को नाम देने का कोई अन्य अच्छा तरीका नहीं है।
एक उदाहरण पर विचार करें जिसमें स्लॉट 0 का उपयोग इनपुट के लिए किया जाएगा, आउटपुट के लिए स्लॉट 1, प्रिंटिंग त्रुटि संदेशों के लिए स्लॉट 2 का उपयोग किया जाएगा। यह
यूनिक्स पर कैसे काम करता है। और यह ठीक काम करता है यदि आप इन तीन फ़ाइलों या तीन डेटा धाराओं को प्रक्रिया में स्थानांतरित करते हैं।
लेकिन
शिमला मिर्च में, ऐसा होता है कि आप अपने रास्ते में बहुत अधिक फ़ाइल विवरणकों के माध्यम से "गुजरते हैं"। इसलिए, जब आप कुछ फ़ाइलों के लिए एक फाइल डिस्क्रिप्टर पास करते हैं, तो आप नेटवर्क कनेक्शन के लिए एक फाइल डिस्क्रिप्टर, एक साझा लाइब्रेरी के लिए एक डिस्क्रिप्टर, जो आपके पास है, आदि से गुजरते हैं। इन सभी नंबरों को प्रबंधित करना काफी थकाऊ है। इसलिए, वास्तव में,
libcapsicum इन अस्पष्ट फ़ाइलर्स के बजाय उपयोग किए जाने वाले पदानुक्रमित नाम का उपयोग करके प्रक्रियाओं के बीच इन पिछले फ़ाइल
विवरणकों के नाम से सार करने की क्षमता प्रदान करता है।
यह उन सरल चीजों में से एक है जो वे अपने पुस्तकालय में प्रदान करते हैं। इसलिए मैं प्रक्रिया के लिए फाइल डिस्क्रिप्टर पास कर सकता हूं और इसे एक नाम दे सकता हूं, इससे कोई फर्क नहीं पड़ता कि यह किस नंबर पर इंगित किया गया है। यह विधि ज्यादा सरल है।
उनके पास अभी भी एक और, अधिक जटिल सैंडबॉक्स लॉन्च तंत्र है। यह
lch है , सैंडबॉक्स होस्ट
एपीआई जो केवल
क्षमता विशेषताओं मोड में प्रवेश करने के बजाय उपयोग किया जाता है। उन्हें अवसर मोड में एक साधारण प्रविष्टि से अधिक कुछ की आवश्यकता क्यों थी? सैंडबॉक्स बनाते समय आमतौर पर आपको क्या परेशान करता है?
श्रोता: शायद,
सिस्टम की एक "स्वच्छ" शुरुआत सुनिश्चित करने के लिए, सभी विरासत में मिली चीज़ों को मिटा देता है।
प्रोफेसर: हाँ। मुझे लगता है कि वे उस हर चीज को ध्यान में रखने की कोशिश कर रहे हैं, जिसके लिए सैंडबॉक्स की पहुंच है। बात यह है कि, यदि आप कर्नेल तंत्र स्तर पर, तकनीकी रूप से, केवल
cap_enter कहते हैं, तो यह काम करेगा। है न? यह आपको किसी भी नए अवसरों की खोज करने से रोकता है।
लेकिन समस्या यह है कि कई मौजूदा चीजें हो सकती हैं, जिनकी प्रक्रिया पहले से ही एक्सेस है।
इसलिए, मुझे लगता है कि सबसे सरल उदाहरण खुले फ़ाइल विवरणकों की उपस्थिति है जो आप के बारे में भूल गए थे, और वे बस इस प्रक्रिया से विरासत में मिलेंगे।
उदाहरण के लिए, उन्होंने
tcpdump पर विचार किया। सबसे पहले, उन्होंने आने वाले सभी नेटवर्क कनेक्शनों को पार्स करने से पहले ही बस
cap_enter द्वारा
tcpdump को बदल दिया। एक तरह से, यह अच्छी तरह से काम करता है क्योंकि आपको अधिक
क्षमता की सुविधाएँ नहीं मिल सकती हैं। लेकिन फिर, ओपन फाइल डिस्क्रिप्टर को देखते हुए, उन्होंने महसूस किया कि आपके पास उपयोगकर्ता टर्मिनल तक पूरी पहुंच है, क्योंकि आपके पास इसके लिए एक ओपन फाइल डिस्क्रिप्टर है। ताकि आप उन सभी कीस्ट्रोक को रोक सकें जो उपयोगकर्ता बनाता है, और जैसे। तो यह शायद
tcpdump के लिए एक अच्छी योजना नहीं है। क्योंकि आप नहीं चाहते कि कोई आपकी कीबोर्ड गतिविधि को बाधित करे।
इसलिए,
tcpdump के मामले में
, उन्होंने मैन्युअल रूप से फ़ाइल डिस्क्रिप्टर को बदल दिया और उन प्रकार के ऑपरेशनों के कुछ बिट्स जोड़ दिए जिन्हें आप कर सकते हैं। यदि आपको याद है,
कैप्सिकम में, सुविधा में ये अतिरिक्त बिट्स भी हैं जो ऑपरेशन के वर्ग को इंगित करते हैं जो किसी दिए गए फ़ाइल विवरणक के लिए किया जा सकता है। इस प्रकार, वे मूल रूप से मानते हैं कि फ़ाइल विवरणक 0. है। यह ट्टी उपयोगकर्ता
टर्मिनल की ओर इशारा
करता है । प्रारंभ में, यह कर्नेल में
ट्टी संरचना के लिए सिर्फ एक सीधा सूचक था। इस डिस्क्रिप्टर के लिए किए जाने वाले ऑपरेशन के प्रकार को सीमित करने के लिए, उन्होंने बीच में क्षमताओं के कुछ मध्यवर्ती बीटा संरचना को पेश किया। इस प्रकार, फ़ाइल डिस्क्रिप्टर इस क्षमता संरचना को इंगित करता है, और यह पहले से ही वास्तविक फ़ाइल को इंगित करता है जिसे आप एक्सेस करने का प्रयास कर रहे हैं। और इस क्षमता संरचना में फ़ाइल डिस्क्रिप्टर ऑब्जेक्ट के लिए कुछ प्रतिबंधात्मक बिट्स या अनुमतियाँ हैं, जिन्हें लागू किया जा सकता है।
इस प्रकार,
tcpdump में मानक डेटा प्रविष्टि के साथ
, आप इसके साथ कुछ भी नहीं कर सकते। आप बस देख सकते हैं कि यह मौजूद है, और यह है। आउटपुट फ़ाइल डिस्क्रिप्टर के लिए, उन्होंने एक अवसर प्रदान किया जब आप इसे कुछ लिख सकते हैं, लेकिन रिकॉर्ड को बदल नहीं सकते हैं, अर्थात आप किए गए परिवर्तनों को रद्द नहीं कर सकते।
तो आप
सैंडबॉक्स लॉन्च करने
के बारे में और क्या चिंता कर सकते हैं? मैं फाइल डिस्क्रिप्टर की स्थिति के बारे में सोचता हूं। कुछ और बात करता है? मुझे लगता है कि
यूनिक्स पर ये फाइल डिस्क्रिप्टर और मेमोरी हैं।
एक और बात यह है कि ये लोग चिंतित हैं कि आपके पते के स्थान में पहले से आवंटित गोपनीय डेटा हो सकता है। और जिस प्रक्रिया को आप सैंडबॉक्स में अलग करने जा रहे हैं वह सभी उपलब्ध मेमोरी को पढ़ सकता है। इसलिए यदि किसी प्रकार का पासवर्ड है जिसे आपने पहले चेक किया था, जब उपयोगकर्ता लॉग इन करता है, और आपने अभी तक मेमोरी को क्लियर नहीं किया है, तो यह प्रक्रिया इसे पढ़ने और कुछ "दिलचस्प" करने में सक्षम होगी।
उन्होंने इस समस्या को इस तरह हल किया:
lch_start में आपको एक "ताज़ा" प्रोग्राम चलाना होगा। आप प्रोग्राम लेते हैं और उसमें सभी तर्कों को पैक करते हैं, सभी फ़ाइल विवरण जो आप इसे प्रदान करना चाहते हैं। फिर आप एक नई प्रक्रिया शुरू करते हैं या पूरे वर्चुअल मेमोरी स्पेस के रीइन्स्टिटलाइजेशन ऑपरेशन को शुरू करते हैं। और फिर इसमें कोई संदेह नहीं है कि गोपनीय डेटा के सेट को प्रभावित करने के लिए इस प्रक्रिया को कोई अतिरिक्त विशेषाधिकार प्राप्त नहीं होगा। यह वही है जो आपने
lch_start फ़ंक्शन को दिया था, बाइनरी नाम, तर्क और कार्यक्रम क्षमताओं के संदर्भ में।
श्रोता: क्या होता है यदि आपके द्वारा शुरू की जाने वाली प्रक्रिया में द्विआधारी
सेतुड = ० होता है ?
प्रोफेसर: मुझे लगता है कि ये लोग कुछ अजीब इंटरैक्शन से बचने के लिए फीचर मोड में
सेट्यूइड "बायनेरिज़" का उपयोग नहीं करते हैं जो दिखाई दे सकते हैं। वे इस नियम को लागू करते हैं: आपके पास एक
सेट्यूड प्रोग्राम हो सकता है जो
सेट्यूड बाइनरी से इसके विशेषाधिकार प्राप्त करता है, और फिर इसे
cap_enter या
lch_start कह सकते हैं। लेकिन एक बार जब आप फीचर मोड में आ जाते हैं, तो आप अतिरिक्त प्राथमिकताएँ बहाल नहीं कर सकते।
सिद्धांत रूप में, यह काम कर सकता है, लेकिन यह बहुत अजीब होगा। क्योंकि, यदि आपको याद है, तो केवल वही चीज जहां
यूआईडी मायने रखता है जब आप फीचर मोड में होते हैं तो एक डायरेक्टरी के अंदर फाइल खोल रहे होते हैं। इसलिए, यह स्पष्ट नहीं है कि क्या यह वास्तव में अतिरिक्त विशेषाधिकार प्राप्त करने के लिए एक उत्कृष्ट योजना है या यदि इसमें खामियां हैं।
श्रोता: पहले, हमने इस बारे में बात की थी कि लाइब्रेरी वास्तव में दो सुरक्षा कारकों के बीच एक सख्त अलगाव का समर्थन क्यों नहीं करती है। लेकिन हमें
lch_start का उपयोग नहीं करना है?
प्रोफेसर: यह सही है। मान लीजिए कि आपके पास
tcpdump , या
gzip जैसी कोई चीज है - यह एक और चीज है जिसके साथ वे काम करते हैं। आप मान लेते हैं कि एप्लिकेशन से शायद समझौता नहीं किया गया है, और एप्लिकेशन का कुछ मूल कार्य है, और आप इस बात की परवाह करते हैं कि यह सैंडबॉक्स में कैसे व्यवहार करता है।
Tcpdump के मामले में
, यह नेटवर्क से आने वाले पैकेटों का पार्सिंग है,
gzip के मामले में यह फाइलों को अनपैक कर रहा है। और एक निश्चित बिंदु तक, आप यह मानते हैं कि प्रक्रिया सब कुछ सही कर रही है, और कोई भेद्यता नहीं होगी। इसलिए, आप
lch_start को चलाने के लिए उस पर विश्वास करते हैं और मानते हैं कि वह छवि को सही ढंग से बनाएगा, सभी सुविधाओं को सही ढंग से कॉन्फ़िगर करेगा, और फिर क्षमताओं मोड के बाहर किसी भी आगे के सिस्टम कॉल से खुद को सीमित करेगा।
और फिर आप खतरनाक चीजों को लॉन्च करते हैं। लेकिन तब तक स्थापना सही थी, और आपके पास इस सैंडबॉक्स से बाहर निकलने का कोई रास्ता नहीं है। इसलिए, मुझे लगता है कि आपको यह देखने की जरूरत है कि आप सैंडबॉक्स एप्लिकेशन के लिए वास्तव में फीचर मोड का उपयोग कैसे कर सकते हैं।
इसलिए हमने
tcpdump के बारे में थोड़ी बात की। आप इस प्रक्रिया को कैसे अलग करते हैं? एक और दिलचस्प उदाहरण
gzip प्रोग्राम है, जो फ़ाइलों को संपीड़ित और विघटित करता है। तो वे सैंडबॉक्स के बारे में चिंतित क्यों हैं? मुझे लगता है कि वे चिंतित हैं कि विघटन कोड संभावित रूप से छोटी गाड़ी हो सकती है, या स्मृति प्रबंधन में त्रुटि हो सकती है, विघटन के दौरान बफर प्रबंधन, और इसी तरह।
एक और दिलचस्प सवाल यह है कि
gzip के लिए परिवर्तन
tcpdump की तुलना में अधिक जटिल क्यों लगते हैं? मुझे लगता है कि इसका कारण यह है कि कैसे आवेदन आंतरिक रूप से संरचित है, है ना? इसलिए, यदि आपके पास एक ऐसा एप्लिकेशन है जो केवल एक फ़ाइल को संपीड़ित करता है या एक फ़ाइल को अनपैक करता है, तो इसे सामान्य रूप से केवल इसे फीचर मोड में बदले बिना लॉन्च करना सामान्य है। आप बस इसे किसी चीज़ को अनपैक करने के लिए एक नया मानक देते हैं, और मानक आउटपुट पर अनपैक्ड डेटा प्रदान करता है, और यह ठीक काम करेगा।
समस्या, जैसा कि लगभग हमेशा इस तरह के सैंडबॉक्स तरीकों से होता है, यह है कि आवेदन में वास्तव में बहुत अधिक जटिल प्रक्रिया तर्क है। उदाहरण के लिए,
gzip एक साथ कई फ़ाइलों को
संपीड़ित कर सकता है, और इसी तरह। और इस मामले में, आपके पास आवेदन के प्रमुख पर किसी प्रकार की अग्रणी प्रक्रिया है, जिसके पास वास्तव में कई फाइलें खोलने, उन्हें पैक करने और इतने पर अतिरिक्त अधिकार हैं। और मुख्य तर्क को अक्सर एक और सहायक प्रक्रिया होने की आवश्यकता होती है।
गज़िप के मामले में
, एप्लिकेशन को संरचित नहीं किया गया था ताकि संपीड़न और विघटन अलग प्रक्रियाओं के रूप में काम करे। इसलिए, उन्हें
गज़िप कर्नेल के कार्यान्वयन और एप्लिकेशन की स्वयं की कुछ संरचना को बदलना पड़ा ताकि डेटा को केवल विघटन फ़ंक्शन में स्थानांतरित करने के अलावा, उन्हें एक
आरपीसी कॉल के माध्यम से भेजा गया या वास्तव में किसी प्रकार की लगभग फ़ाइल फ़्लिप्टर को लिखा गया। यह तृतीय-पक्ष की समस्याओं को वस्तुतः विशेषाधिकारों के साथ होने और अनपैक करने से रोकने के लिए था। केवल एक ही समय में
gzip कर सकता था कि इसे कहा जाने वाली प्रक्रिया में अनपैक्ड या संपीड़ित डेटा वापस करना था।
एक और होमवर्क बात यह है कि आप वास्तव में
OKWS में
शिमला मिर्च का उपयोग कैसे करते हैं? आप इस बारे में क्या सोचते हैं? क्या यह मददगार होगा? क्या
OKWS लोग
FreeBSD में अपग्रेड करके खुश होंगे क्योंकि इसे इस्तेमाल करना इतना आसान है? आप
FreeBSD पर
शिमला मिर्च का उपयोग कैसे करेंगे?
श्रोता: कुछ सख्त प्रतिबंधों से छुटकारा मिल सकता है।
प्रोफेसर: हाँ, यह है, हम पूरी तरह से फ़ाइल डिस्क्रिप्टर और क्षमताओं की एक निर्देशिका की उपस्थिति के साथ उन्हें बदल सकते हैं। आपको एक भ्रामक
चेरोट सेट करने की आवश्यकता नहीं होगी। बहुत सारी छोटी चीज़ों के साथ
चेरोट का उपयोग करने के बजाय, आप केवल अनुमतियाँ ध्यान से सेट कर सकते हैं। आप बस उन सटीक फ़ाइलों को खोल सकते हैं जिनकी आपको आवश्यकता है। तो यह एक बड़े प्लस की तरह लगता है।
अगला,
ओकेडब्ल्यूएस में , आपके पास
ओके लॉन्च सेवा है, जिसे सभी मूल प्रक्रियाओं को शुरू करना चाहिए। जैसे ही वे मर जाते हैं, सिग्नल "डेड" प्रक्रिया को फिर से शुरू करने के लिए
ओल्ड में लौटता है। और इस बात को
जड़ से चलाना होगा, क्योंकि इसे सैंडबॉक्स में प्रक्रियाओं को अलग करना था। लेकिन
OKWS में
बहुत सी चीजें हैं
जिन्हें शिमला मिर्च के साथ बेहतर बनाया जा सकता है।
उदाहरण के लिए, आप बहुत कम विशेषाधिकारों के
साथ ओकेल्ड प्रदान कर सकते हैं। क्योंकि, उदाहरण के लिए, पोर्ट 80 प्राप्त करने के लिए, आपको रूट विशेषाधिकारों की आवश्यकता है। लेकिन उसके बाद, आप सुरक्षित रूप से सैंडबॉक्स में सब कुछ डाल सकते हैं, क्योंकि रूट अधिकारों की अब आवश्यकता नहीं है। तो यह बहुत अच्छा है। शायद आप प्रक्रिया को किसी और के अनुरोधों का जवाब देने का अधिकार भी सौंप सकते हैं, उदाहरण के लिए, एक सिस्टम मॉनिटरिंग प्रक्रिया जो कि इस प्रक्रिया को एक बच्चे की प्रक्रिया के लिए वर्णनकर्ता या प्रक्रिया विवरणक है और जब भी ऐसी प्रक्रिया क्रैश होती है, तो यह एक नया शुरू होता है। इसलिए, मुझे लगता है कि रूट विशेषाधिकार के बिना सैंडबॉक्स बनाने की क्षमता बहुत उपयोगी है।
श्रोता: आप प्रत्येक प्रक्रिया को एक फाइल डिस्क्रिप्टर दे सकते हैं जो आपको लॉग में केवल प्रविष्टियाँ जोड़ने की अनुमति देता है।
प्रोफेसर: हाँ, और यह बहुत अच्छा है। जैसा कि हमने पिछली बार कहा था, लॉग फाइल के साथ
ओकलॉग "गड़बड़" कर सकते हैं। और जो जानता है कि कर्नेल उसे क्या करने की अनुमति देगा जब उसके पास लॉग फ़ाइल का फ़ाइल विवरणक होगा। हालाँकि, हम फ़ाइल डिस्क्रिप्टर की क्षमताओं को अधिक सटीक रूप से निर्धारित कर सकते हैं कि इसे एक लॉग फ़ाइल देकर संकेत दिया जाए कि यह केवल लिख सकता है, लेकिन कुछ भी नहीं खोज सकता है। इस प्रकार, यदि आपको इस फाइल के लिए केवल "लेखक" ही है तो हमें केवल एपेंड-ओनली फंक्शन मिलता है। यह बहुत सुविधाजनक है। आप फ़ाइल को लिखने के लिए प्रक्रिया की अनुमति दे सकते हैं, लेकिन इसे नहीं पढ़ सकते हैं, जो केवल
यूनिक्स अनुमतियों का उपयोग करना बहुत मुश्किल है।
Capsicum ?
: , , , . , , , .
: , .
Capsicum , , . .
: , , okld . , .
: , . . , ,
Capability , . , , , , , .
,
OKWS . . , , , . .
, , «». , . , , , , . .
: «» , , ?
: ,
FreeBSD . , - , .
FreeBSD Casper , ,
Capability . , «».
- , , , - , ,
Casper .
, «» . . , , ,
Casper - .
, , - . ,
Unix FD . , . , , .
,
FreeBSD ,
DNS .
DNS -, «». ,
tcpdump . tcpdump , IP-. , ,
DNS -.
, , DNS- DNS-, .
Casper , DNS-.
, , , Capsicum? ? ? , , .
Capsicum , ?
tcpdump
GZIP , , . ?
: , , , . ,
Capability .
: , .
Capsicum , , . , , . , , , ,
Capsicum , .
, «». ,
TCP — helper , , , , . , , , .
: , .
: , . . , .
lth_start , . , , , - .
, , Capsicum . , , , . Unix - , .
, . , . , , . , .
, Chrome . , , , Unix, -,
Unix .
, ?
: .
: . . , . , , , , .
Unix , . , . , . . , .
.
Linux ,
setcall , , . ,
Capsicum , ,
Capsicum , .
Linux setcall , . , ,
Linux .
, — , , , , . , - , «//», .
Capsicum जहां आप एक विशिष्ट फ़ाइल के लिए प्रक्रिया शुरू कर सकते हैं, और पूरे होम निर्देशिका के लिए नहीं।पाठ्यक्रम का पूरा संस्करण यहां उपलब्ध है ।हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें,
एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।
छह महीने की अवधि के लिए एक नया डेल R630 के लिए भुगतान करते समय मुफ्त में 3 महीने - 2 एक्स इंटेल डेका-कोर एक्सोन E5-2630 v4 / 128GB DDR4 / 4x1TB HDD या 2x240GB SSD / 1Gbps 10 टीबी - $ 99.33 प्रति माह से , केवल अगस्त के अंत तक, ऑर्डर करें। यहाँ हो सकता है ।डेल R730xd 2 बार सस्ता? केवल हमारे पास
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 टीवी 249 डॉलर में नीदरलैंड और यूएसए से है! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें
। एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?