🖕🏼 🏇🏿 🧖🏼 अनिवार्य लिंक के आधार पर सुरक्षा का परिचय (क्षमता-आधारित सुरक्षा) 👺 🧑🏿 🛀

अधिकांश ऑपरेटिंग सिस्टम पर आज, सुरक्षा मॉडल यूनिक्स में निहित है, इस धारणा को विरासत में मिला है कि उपयोगकर्ता उन कार्यक्रमों पर भरोसा कर सकता है जो वह चलाता है। हालाँकि, जैसा कि अभ्यास से पता चलता है, यह कथन मौलिक रूप से गलत है।

मार्क स्टिगलर ने इस स्थिति की तुलना उस समय की जब आप एक चौकीदार को उसे मास्टर और केवल कुंजी देने के लिए रखते हैं, जो न केवल उस कमरे को खोलता है जिसमें साफ करना है, बल्कि सभी दरवाजे भी खोलता है, जिसमें शामिल है और सोने के साथ तिजोरी का दरवाजा। यानी आपके पास केवल दो विकल्प हैं - या तो क्लीनर को चाबी न देने के लिए - और फिर वह अपना काम करने में सक्षम नहीं होगा, या अपनी शालीनता के लिए आशा और उम्मीद नहीं करेगा।

क्षमता-आधारित सुरक्षा मॉडल इस समस्या का समाधान प्रस्तुत करता है।

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

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

बाह्य संसाधनों के लिए अनिवार्य लिंक (Eng। क्षमता, POSIX क्षमताओं के साथ भ्रमित नहीं होना) का उपयोग करके एक प्रोग्राम सैंडबॉक्स से परे जा सकता है।

आज तक, इस विषय पर केवल रूसी-भाषा का साहित्य नहीं है - इतना है कि इस लेख को लिखने के लिए मुझे खुद "क्षमता" शब्द के लिए अनुवाद का आविष्कार करना था। तो, परिचित हो जाओ:

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

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

तुलना के लिए, स्ट्रिंग के रूप में फ़ाइल का पथ ऑब्जेक्ट को पहचानता है, लेकिन उस पर मान्य संचालन निर्धारित नहीं करता है - इसलिए, हर बार किसी दिए गए तरीके से एक फ़ाइल पर एक ऑपरेशन किया जाता है, ओएस को एक एक्सेस चेक करना होगा।

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

अनिवार्य संदर्भों के आधार पर सुरक्षा साहित्य में, शब्द "संसाधन" और "विषय" ( पीडीएफ ) पाया जा सकता है। एक "संसाधन" वह भूमिका है जो संदर्भित लिंक को खेलने के लिए इंगित करता है कि वस्तु। एक "विषय" वह है जिसके पास एक अनिवार्य लिंक है और एक संसाधन पर संचालन कर सकता है। विषय और संसाधन के बीच कई-से-कई संबंध हैं: प्रत्येक विषय में विभिन्न संसाधनों के लिए अनिवार्य लिंक की एक मनमानी संख्या हो सकती है, विषयों की एक मनमानी संख्या एक संसाधन को संदर्भित कर सकती है।

कुछ कार्यान्वयन में, "विषय" और "संसाधन" ऐसी भूमिकाएं हैं जो संदर्भ के आधार पर समान ऑब्जेक्ट खेल सकते हैं। दूसरों में , ये विषम वस्तुएं हैं, लेकिन एक प्रकार का संसाधन किसी अन्य विषय के साथ संचार का एक चैनल है। एक तरह से या किसी अन्य, ऑब्जेक्ट अनिवार्य लिंक का उपयोग करके एक-दूसरे के साथ संवाद कर सकते हैं - लिंक के मालिक ऑब्जेक्ट ओओपी के रूप में संदर्भित ऑब्जेक्ट को संदेश भेज सकते हैं। भविष्य में, प्रस्तुति की सुविधा के लिए, हम मानते हैं कि वस्तुएँ सजातीय हैं - अर्थात्। "विषय" और "संसाधन" स्थितिजन्य भूमिकाओं से अधिक कुछ नहीं हैं।

मॉडल मानता है कि वस्तुओं की आंतरिक स्थिति को समझाया गया है और संदेश भेजने के अलावा नहीं बदला जा सकता है।

अनिवार्य लिंक आंदोलन

ऑब्जेक्ट सीमित संख्या में अनिवार्य लिंक प्राप्त कर सकता है:

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

ये नियम वस्तुओं के ग्राफ के रूप में प्रणाली को विचाराधीन प्रस्तुत करना संभव बनाते हैं और मौजूदा संचार चैनलों, साथ ही नए कनेक्शन के उद्भव के लिए स्थानों और स्थितियों का औपचारिक रूप से विश्लेषण करते हैं।

मॉडल के दृष्टिकोण से, वैश्विक चर (किसी भी रूप में, पारंपरिक फाइल सिस्टम सहित) की समग्रता एक एकल वस्तु है जो सभी के लिए सुलभ है। ऐसी वस्तु का अस्तित्व मॉडल के विपरीत नहीं है, लेकिन सिस्टम की सुरक्षा में एक छेद है। जे-कर्नेल प्रणाली के रचनाकारों के लिए मानक जावा लाइब्रेरी में सिंगलनेट्स और ग्लोबल फाइल सिस्टम एक्सेस का लोड एक गंभीर समस्या बन गई है । .NET प्लेटफॉर्म में वही समस्याएं मौजूद हैं।

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

"फ़ाइल को पढ़ने" का अधिकार देने के बजाय, प्रोग्राम को "फ़ाइल को तब तक पढ़ने का अधिकार दिया जाता है जब तक कि पहुँच निरस्त नहीं हो जाती।" यह प्रॉक्सी ऑब्जेक्ट्स का उपयोग करके कार्यान्वित किया जाता है। नीचे दिया गया कोड इस तंत्र को बहुत ही सरल रूप में दिखाता है:

using System; using System.Collections.Generic; namespace CapRevokeDemo { //  ,      interface IFile { char read(int index); int length { get; } } //  ,    interface IApplication { void openFile(IFile reader); } class FileAlreadyExistsException : Exception { } class FileNotFoundException : Exception { } class AccessRevokedException : Exception { } // ,       class FileManager { public FileManager() { files_ = new Dictionary<string, IFile>(); openedFiles_ = new Dictionary<string,List<FileProxy>>(); } public void addFile(string fileName, IFile reader) { if (files_.ContainsKey(fileName)) { throw new FileAlreadyExistsException(); } files_.Add(fileName, reader); } public void openFileInApplication(string fileName, IApplication app) { IFile reader; if(!files_.TryGetValue(fileName, out reader)) { throw new FileNotFoundException(); } FileProxy proxy = new FileProxy(reader); List<FileProxy> proxies; if(!openedFiles_.TryGetValue(fileName, out proxies)) { proxies = new List<FileProxy>(); openedFiles_.Add(fileName, proxies); } proxies.Add(proxy); app.openFile(proxy); } public void revokeAccessToFile(string fileName) { List<FileProxy> proxies; if(openedFiles_.TryGetValue(fileName, out proxies)) { foreach(FileProxy proxy in proxies) { proxy.revokeAccess(); } openedFiles_.Remove(fileName); } } // -,      . private class FileProxy : IFile { public FileProxy(IFile file) { file_ = file; } public char read(int index) { if(file_ == null) { throw new AccessRevokedException(); } return file_.read(index); } public int length { get { if(file_ == null) { throw new AccessRevokedException(); } return file_.length; } } public void revokeAccess() { file_ = null; } private IFile file_; } private Dictionary<string, IFile> files_; private Dictionary<string, List<FileProxy> > openedFiles_; } //   class Program { class DemoFile : IFile { public DemoFile(string data) { data_ = data; } public char read(int index) { return data_[index]; } public int length { get { return data_.Length; } } private string data_; } class DemoApp : IApplication { public void openFile(IFile file) { file_ = file; index_ = 0; } public void closeFile() { file_ = null; index_ = 0; } public void read() { char c = file_.read(index_++); System.Console.WriteLine("c = {0}", c); } private IFile file_ = null; private int index_ = 0; } public static void Main(string[] args) { try { FileManager manager = new FileManager(); manager.addFile("file", new DemoFile("SECRET")); DemoApp app = new DemoApp(); manager.openFileInApplication("file", app); app.read(); app.read(); app.read(); manager.revokeAccessToFile("file"); app.read(); } catch(Exception e) { System.Console.WriteLine("Exception: {0}", e.Message); } } } }

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

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

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

नकली सुरक्षा

जनादेश लिंक के पास एक महत्वपूर्ण संपत्ति होनी चाहिए - नकली से सुरक्षा। एक अनिवार्य लिंक को "अनुमान" करना असंभव होना चाहिए जो उपरोक्त नियमों के अनुसार प्रदान नहीं किया गया था।

डिस्क्रिप्टर के लिए, यह संपत्ति एक प्रक्रिया के ढांचे के भीतर गलत है: डिस्क्रिप्टर कोड बनाने के सिद्धांत को जानने के बाद, एक स्वीकार्य समय में सही डिस्क्रिप्टर बनाना संभव है। यानी होस्ट प्रक्रिया में लोड किया गया एक प्लगइन उस डेटा तक पहुंच सकता है जो होस्ट-प्लगइन इंटरफेस के माध्यम से उसे प्राप्त नहीं कर सका।

फ़ाइल पथ के लिए यह गुण सिद्धांत में संतुष्ट नहीं है - कोड में "C: \ Windows \ system32 \ driver \ etc \ Host" लिखें - और अब, हमारे पास पहले से ही एक महत्वपूर्ण सिस्टम फ़ाइल का लिंक है।

नकली से अनिवार्य लिंक की रक्षा कैसे करें? यह सुनिश्चित करने के लिए , मुझे चार मुख्य दृष्टिकोणों का पता है:

विवरणकर्ता के रूप में क्रेडेंशियल्स - प्रक्रियाएं ऑब्जेक्ट हैं। अनिवार्य लिंक के साथ सभी काम ओएस के कार्यों के माध्यम से किए जाते हैं। प्रत्येक प्रक्रिया के लिए, ओएस अनिवार्य लिंक की एक सूची संग्रहीत करता है जो वर्तमान में इसके लिए उपलब्ध हैं। एक प्रक्रिया एक अनिवार्य लिंक पर एक ऑपरेशन कर सकती है केवल अगर यह लिंक इसी सूची में हो।
क्रिप्टोग्राफिक उपकरण - यह दृष्टिकोण एक पूर्ण गारंटी नहीं देता है कि लिंक को नकली करना संभव नहीं होगा, बल्कि इसके बजाय आवश्यक न्यूनतम नकली योग्यता प्रदान करता है। कार्यक्रम ओएस कार्यों के लिए एक एन्क्रिप्टेड अनिवार्य लिंक प्रदान करता है, जो उपयोग से पहले इसकी शुद्धता और डिक्रिप्ट की जांच करता है। अनिवार्य लिंक को एन्क्रिप्ट / डिक्रिप्ट करने के उच्च ओवरहेड के कारण, इस पद्धति का उपयोग उसी मशीन के भीतर सुरक्षा को लागू करने के लिए नहीं किया जाता है, लेकिन नेटवर्क सिस्टम पर उपयोग किया जाता है।
पासवर्ड के साथ अनिवार्य लिंक (अंग्रेजी पासवर्ड-क्षमताएं) - पिछले दो तरीकों का हाइब्रिड ( यहां और अधिक विवरण)। एक क्रेडेंशियल लिंक में पहचान की जानकारी और एक पासवर्ड होता है। पासवर्ड सिस्टम द्वारा उत्पन्न बिट्स का एक यादृच्छिक अनुक्रम है। पासवर्ड का अनुमान लगाने की संभावना 2 ^{-k है} , जहां k पासवर्ड की लंबाई है। प्रणाली एक डिक्शनरी को पहचान की जानकारी के साथ एक पासवर्ड को जोड़ती है। क्रेडेंशियल लिंक को सही माना जाता है यदि क्रेडेंशियल लिंक में पासवर्ड डिक्शनरी में पासवर्ड से मेल खाता है।
कमांड / भाषा प्रणाली के स्तर पर सुरक्षा - लक्ष्य मशीन के कमांड सिस्टम में बिट्स के मनमाने अनुक्रम को अनिवार्य लिंक के रूप में व्याख्या करने की अनुमति देने वाली कोई भी कमांड शामिल नहीं है, या ऐसे कमांड केवल विशेषाधिकार प्राप्त और कर्नेल तक ही पहुंच योग्य हैं। इस मामले में, लक्ष्य मशीन या तो एक वास्तविक उपकरण हो सकती है ( प्लेसी सिस्टम 250 , आईबीएम सिस्टम / 38 , आरएसआरई फ्लेक्स कंप्यूटर सिस्टम), या एक वर्चुअल मशीन ( जे-कर्नेल परियोजना जेवीएम के आधार पर लागू की गई है)

क्रमबद्धता

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

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

लीम्बो

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

ऐलिस को दी गई वस्तु पर प्रतिबंध लगाने से, जो इस परिदृश्य में ऐलिस द्वारा उपयोग के लिए इस वस्तु को सुरक्षित बना देगा, इसे वस्तु का कारावास कहा जाता है।

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

निष्कर्ष

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

मेरी राय में, अनिवार्य लिंक पर आधारित सुरक्षा OOP, भाषा-आधारित सुरक्षा और ऑर्थोगोनल दृढ़ता के साथ सबसे सुविधाजनक और सुरुचिपूर्ण ढंग से कार्यान्वित की जाती है। मेरा मानना है कि एक मंच जो इन सभी अवधारणाओं को लागू करता है वह ओएस के विकास में अगला अध्याय लिखेगा। लेकिन अभी के लिए, अनिवार्य लिंक पर आधारित सुरक्षा प्रायोगिक ओएस का भाग्य बनी हुई है। मुझे आशा है कि मैं अनिवार्य लिंक के विचार में पाठक को रुचि देने में कामयाब रहा और इस तरह के एक परियोजना का द्रव्यमान ओएस बन जाने पर उस दिन के करीब लाया गया।

अनिवार्य लिंक के आधार पर सुरक्षा का परिचय (क्षमता-आधारित सुरक्षा)

अनिवार्य लिंक आंदोलन

नकली सुरक्षा

क्रमबद्धता

लीम्बो

निष्कर्ष

संदर्भ:

More articles: