विंडोज स्व-प्रतिबंध सुरक्षा विचार

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

और यह अच्छा होगा यदि कार्यक्रम को स्वयं पता हो कि उसे किन क्रियाओं की आवश्यकता नहीं है और, बस मामले में, उन्हें बंद कर दिया।



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

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

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

विचार उत्पादकता

इसके लिए धन्यवाद, आप इसे प्राप्त कर सकते हैं:

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

एक और अधिक यथार्थवादी बिंदु से बोलते हुए, एक:

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

विचारों के कार्यान्वयन और उपयोग की विशेषताएं

विचार को लागू करने के लिए, विंडोज कर्नेल में यह आवश्यक है:

• दो सिस्टम संरचनाओं में संपादन करें।
• एक सिस्टम कॉल जोड़ें।
• 50-100 लाइनों पर कोड लिखें।

Kernel32.dll में एक फ़ंक्शन जोड़ें जो सुरक्षा को नियंत्रित करता है। जो भी विशेष रूप से बड़ी नहीं होगी।

ये क्रियाएं किसी भी प्रोग्रामर (और एक दिन में) की शक्ति के भीतर होती हैं। लेकिन सबसे बड़ी मुश्किल यह है कि Microsoft को ही ऐसा करना चाहिए। यही कारण है कि इस तरह के एक रक्षा तंत्र अभी के लिए सपने में है।

सैद्धांतिक पीछे हटना

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

विंडोज में कॉलिंग सिस्टम फ़ंक्शन के मूल सिद्धांत को निम्नलिखित चित्र के रूप में दर्शाया जा सकता है:



Sysenter / syscall / int 0x2E या कॉल dword ptr fs: [0xC0] (विंडोज़ के संस्करण के आधार पर) को कॉल करने के बाद, नियंत्रण कर्नेल में जाएगा, जहां KiSystemService सिस्टम सेवाओं के पते (SDT) की तालिका के माध्यम से दिखता है और सेवा संख्या (eax रजिस्टर में संचरित) द्वारा ) वांछित फ़ंक्शन का पता ढूंढता है और फिर उस पर नियंत्रण स्थानांतरित करता है। इस प्रकार, वांछित फ़ंक्शन कहा जाता है।

सिस्टम दो तालिकाओं का उपयोग करता है - एक सीधे सिस्टम के संचालन के लिए जिम्मेदार है और कर्नेल द्वारा संसाधित किया जाता है, और दूसरा जीयूआई के संचालन के लिए जिम्मेदार है और इसे win32.sys ड्राइवर द्वारा संसाधित किया जाता है। हम पहली तालिका में रुचि रखते हैं।

इस वास्तुकला के लिए धन्यवाद, किसी भी सिस्टम फ़ंक्शन के कॉल पर एक्सेस प्रतिबंध लगाना संभव है। ऐसा करने के लिए, बस KiSystemService फ़ंक्शन में एक साधारण चेक डालें।

हमने पहले ही सत्यापन का स्थान ढूंढ लिया है, अब दार्शनिक के पत्थर को एक्सेस मैट्रिक्स को संग्रहीत करने के लिए एक जगह ढूंढना आवश्यक है।

विंडोज ऑपरेटिंग सिस्टम पर, कर्नेल स्ट्रीम का वर्णन करने के लिए KTHREAD संरचना का उपयोग करता है, जो प्रत्येक स्ट्रीम का अपना होता है। यह वह जगह है जहां एक्सेस मैट्रिक्स को स्टोर करना संभव होगा। लेकिन अब यह एक मैट्रिक्स नहीं होगा, लेकिन एक रैखिक सूची (चूंकि प्रत्येक धागा केवल अपने बारे में जानकारी संग्रहीत करेगा)।

सब कुछ ठीक होगा, लेकिन एक नेटवर्क भी है, जिसके साथ विशेष ड्राइवरों के माध्यम से काम किया जाता है। लेकिन यहाँ समस्या को कुछ IRP अनुरोधों को डिवाइसों \\ Device \ Tcp, \\ Device \ Udp, \\ Device \ Raw में संसाधित करने में हल किया गया है, जो कुछ धाराओं से नेटवर्क तक पहुँचने की क्षमता की पारदर्शी जाँच भी करेगा।

हम कैसे सुरक्षा को लागू करेंगे

सुरक्षा के कार्यान्वयन को निम्नानुसार देखा जाता है:

• प्रत्येक धारा के विवरण संरचना में बिट्स से मिलकर निषेध की एक तालिका है। विंडोज 7 में, एसडीटी में 360 फ़ंक्शन हैं, इसलिए छत के ऊपर 512 बिट्स (64 बाइट्स) की एक सरणी पर्याप्त है।
• डिफ़ॉल्ट रूप से, सभी बिट्स रीसेट हो जाते हैं (यानी कोई प्रतिबंध नहीं हैं)
• एक 64-बिट कुंजी फ़ील्ड भी है, जिस पर थोड़ा बाद में चर्चा की जाएगी।
• फ़ंक्शन के कॉलबैक पते को संग्रहीत करने के लिए 32/64 बिट फ़ील्ड भी है
• कुल हमारे पास 76/80 बाइट्स के लिए डेटा है
• कर्नेल में एक और सिस्टम कॉल जोड़ा गया है, जो निम्नलिखित नियमों के अनुसार संरचना को भरता है:
  
  • बिट्स हमेशा सेट किया जा सकता है।
  • आप केवल एक विशेष सुरक्षा कुंजी निर्दिष्ट करके बिट्स को रीसेट कर सकते हैं।
  • एक विशेष कुंजी केवल एक बार प्राप्त की जा सकती है।
  • कॉलबैक फ़ंक्शन कुंजी का उपयोग करके केवल एक बार या असीमित संख्या में सेट किया जा सकता है।
  
  
• सुरक्षा प्रबंधन को व्यवस्थित करने वाले सिस्टम कॉल में kernel32.dll और ntdll.dll में एक इंटरफ़ेस फ़ंक्शन जोड़ा गया है।

संरक्षण प्रगति:

• नेटवर्क ड्राइवर के KiSystemService या IRP अनुरोध ड्राइवर में, हमें PTHREAD संरचना के लिए एक संकेतक मिलता है
• सूचकांक की सीमाओं की जांच करें (एसडीटी में एक नंबर के मामले में)
• जांचें कि बिट सेट है या नहीं। यदि सेट किया गया है, तो STATUS_ACCESS_DENIED लौटें
• यदि एक बिट सेट है और एक कॉलबैक फ़ंक्शन निर्दिष्ट है, तो इसे कॉल करें। इस प्रकार, इस प्रक्रिया को सूचित करते हुए कि कुछ धागे निषिद्ध कार्यों को करने की कोशिश करते हैं।

मैं सुरक्षा स्थापित करने के कार्य पर विशेष ध्यान देना चाहूंगा। उसके प्रोटोटाइप को इस रूप में देखा जाता है:
DWORD QuerySystemSecurity (HANDLE hThread, DWORD Flag, QWORD * Key, VOID / डेटा);

• hThread - उस थ्रेड का हैंडल जिसके लिए सुरक्षा सेट है। या वर्तमान थ्रेड के मामले में 0xFFFFFFFF।
• झंडा - पैरामीटर पारित या अनुरोध:
  
  • कुंजी प्राप्त करें।
  • फ़ंक्शन पर प्रतिबंध सेट करें।
  • कार्यों की सूची पर प्रतिबंध सेट करें।
  • कार्यों के एक समूह पर प्रतिबंध सेट करें। - उदाहरण के लिए, फ़ाइलों या प्रक्रियाओं के साथ काम करना।
  • कॉलबैक फ़ंक्शन सेट करें।
  • फ़ंक्शन पर प्रतिबंध हटा दें।
  • सुरक्षा तालिका को सम्मिलित करें या नहीं।
  • कुंजी निर्दिष्ट है, भले ही सुरक्षा को अस्वीकार करें।
  • कुंजी की अस्वीकार रसीद।
• कुंजी - कुंजी या NULL का पता।
• डेटा - डेटा फ्लैग के आधार पर।

इसके अलावा QuerySystemSecurity में निषिद्ध फ़ंक्शन की संख्या और एसडीओ से इसकी संख्या के लिए पत्राचार की एक तालिका होनी चाहिए। बाद वाला संस्करण संस्करण से भिन्न होता है।

निष्कर्ष

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

बेशक, इस तरह की सुरक्षा न केवल Microsoft द्वारा, बल्कि तीसरे पक्ष के डेवलपर्स द्वारा भी लागू की जा सकती है, लेकिन यह पहले से ही एक बैसाखी होगी और कुशलता से काम नहीं करेगी (इस तथ्य के कारण कि आपको PTHREAD में डेटा स्टोर करने से इनकार करना होगा) और इस तरह का वैश्विक स्तर नहीं होगा।

लेकिन हमेशा की तरह, ये सुरक्षा के अस्तित्व के आपके अपने सपने हैं, जो माइक्रोसॉफ्ट शायद ही महसूस करेगा।