जीएनयू / लिनक्स और इसकी लड़ाई के लिए दुर्भावनापूर्ण सॉफ़्टवेयर

मैंने इस विषय को हब पर पढ़ा: "ट्रोजन.विनलॉक एलजे के माध्यम से फैलने लगा । " सिद्धांत रूप में, मौलिक रूप से नया कुछ भी नहीं है, और निश्चित रूप से, हमेशा की तरह, टिप्पणियों में "और linux / mac / freebsd / plan9 जैसे संदेशों से भरा होता है, लेकिन ऐसा नहीं है, लेकिन विंडोज SSZB उपयोगकर्ता", जिसके साथ छोटे होलिवर शुरू होते हैं। इसलिए, मैं अपने विचारों को साझा करने के लिए एक नया होलीवर शुरू करना चाहता हूं और यह पता लगाना चाहता हूं कि कौन क्या सोचता है, यह पता लगाने के लिए कि जीएनयू / लिनक्स में मैलवेयर कैसे संभव है और इसके बारे में क्या करना है।

समस्याओं

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



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



क्या कोड सिस्टम में रह सकता है? चलो / घर को नोइसेक विकल्प के साथ माउंट किया जाए, लेकिन हमलावर को अभी भी स्क्रिप्ट का उपयोग करने का अवसर है। दुर्भावनापूर्ण कोड को ~ / .config / long / path / hard / to / find / zlovred.py फ़ाइल बनाने और इसकी ऑटोरन को .profile फ़ाइल में जोड़ने से कुछ भी नहीं रोक रहा है। और आप ~ / .config / autostart में मैलवेयर रजिस्टर कर सकते हैं, या शायद कहीं और, मुझे लगता है कि आप स्थान पा सकते हैं।



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

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



हां, लिनक्स इतना सामान्य नहीं है, वितरण का एक चिड़ियाघर है और वायरस लेखक को बारीकियों को ध्यान में रखना होगा, लेकिन यदि आप चाहते हैं, तो आप कर सकते हैं। अब लिनक्स बहुत लोकप्रिय नहीं है, जब लोकप्रियता की बात आती है तो क्या होगा? botnet के मालिक इस तथ्य के कारण अपनी संख्या बढ़ाने से इंकार कर देंगे कि Linux के लिए मैलवेयर बनाना थोड़ा मुश्किल है? मुझे ऐसा नहीं लगता।

क्या करें?

लिनक्स के लिए एंटीवायरस? कोई रास्ता नहीं!



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



एक खिलाड़ी को क्या चाहिए (हो सकता है)? उसे केवल फाइलें पढ़ने की जरूरत है, ~ / .config / खिलाड़ी को लिखना है, यदि वह कर सकता है तो URL खोलें। बाकी सब कुछ की जरूरत नहीं है, या बल्कि nizyaaaaa (Polunin की आवाज में)। फ्लैश और भी छोटा है, सिर्फ एक नेटवर्क और किसी तरह का ~ / .config / adobe / फ्लैश (या यह कहां है?)। शायद कई और निर्देशिकाओं की आवश्यकता होती है, उदाहरण के लिए अस्थायी फ़ाइलों के लिए, लेकिन यह सब स्पष्ट रूप से सीमित है।



तो क्या करें? जबरन एक्सेस कंट्रोल टूल पहले से मौजूद हैं - SELinux और AppArmor। जैसा मुझे लगता है, यह उन्हें संशोधित करने के लिए दुख नहीं होगा। उदाहरण के लिए, AppArmor (मैं SELinux के साथ सतही रूप से परिचित हूं ... शायद वहां सब कुछ पहले से ही ठीक है?), प्रत्येक एप्लिकेशन के लिए जो अधिकारों को ट्रिम करने की आवश्यकता है, आपको एक विशेष कॉन्फ़िगरेशन लिखने और इसे /etc.apparmor.d/ में डालने की आवश्यकता है। यह मुझे लगता है कि यह दृष्टिकोण पर्याप्त लचीला नहीं है (जहां तक ​​मुझे पता है, SELinux भी लचीला नहीं है)। सुपरसुअर अधिकारों के बिना, मक्खी पर ऐसे प्रोफाइल बनाने का पर्याप्त अवसर नहीं है। अर्थात्:

1. एप्लिकेशन से ही एप्लिकेशन सुरक्षा प्रोफ़ाइल बनाने के लिए इंटरफ़ेस
   
   
2. निर्दिष्ट प्रोफ़ाइल के साथ एक एप्लिकेशन लॉन्च करने के लिए इंटरफ़ेस
   
   
3. मक्खी पर अन्य अनुप्रयोगों के प्रोफाइल के संपादन के लिए आवेदन करने के लिए विशेषाधिकारों को निर्दिष्ट करने की क्षमता, यानी पहले से लागू प्रोफाइल में बदलाव
   
   
4. प्रोफ़ाइल टेम्प्लेट, निष्पादन योग्य फ़ाइलों के प्रारूप में परिवर्तन, पैकेज परिवर्तन संभव हैं
   
   
   
   

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

जब आवेदन करने के लिए डेवलपर द्वारा निर्णय लिया जाता है।



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



सब कुछ ठीक होने लगता है, यानी अधिकांश अनुप्रयोगों को इस तरह से सीमित किया जा सकता है। लेकिन कुछ को दिक्कतें हो सकती हैं। उन अनुप्रयोगों का क्या करें जो किसी भी फ़ाइल को पढ़ने / लिखने के लिए संभावित रूप से आवश्यक हैं।

ब्राउज़र को डाउनलोड की गई फ़ाइलों को सहेजने की क्षमता चाहिए। आप इसे एक अलग ~ / डाउनलोड निर्देशिका में सीमित कर सकते हैं, लेकिन यह सुविधा की कीमत पर सुरक्षा होगी। कुछ संपादक, सिद्धांत रूप में, किसी भी फ़ाइल को पढ़ने और लिखने की क्षमता की आवश्यकता होती है। इस मामले में, आइटम नंबर तीन हमारी मदद करेगा। फ़ाइलों को खोलने और सहेजने के लिए डायलॉग को अलग-अलग प्रक्रियाओं में ले जाना चाहिए, और उदाहरण के लिए, / etc / apparmor / trust_programs लिखते हैं कि / usr / bin / gtk-open-डायलॉग और / usr / bin / gtk- सेव-डायलॉग "मक्खी पर बदल सकते हैं" »पहले से चल रहे अन्य अनुप्रयोगों के प्रोफाइल (उदाहरण के लिए, / proc / [pid] / aa_profile) के माध्यम से। स्वाभाविक रूप से, आवेदन प्रोफाइल केवल उसी उपयोगकर्ता को संपादित करना संभव है, जिनसे विशेष कार्यक्रम स्वयं लॉन्च किए जाते हैं (संवाद खोलना और सहेजना)।

ब्राउज़र शुरू होता है, एक प्रोफ़ाइल उस पर लागू होती है, सब कुछ और सब कुछ प्रतिबंधित करती है। जब ब्राउज़र को डाउनलोड की गई फ़ाइल को बचाने की आवश्यकता होती है, तो वह gtk-save-dialog (स्वाभाविक रूप से, kde को अपने स्वयं के पासवर्ड की आवश्यकता होगी) को लॉन्च करेगा। उपयोगकर्ता स्पष्ट रूप से सहेजने के लिए फ़ाइल नाम का चयन करेगा। Gtk-save-डायलॉग ब्राउज़र प्रक्रिया की प्रोफ़ाइल के अनुरूप एक अपवाद बना देगा और फ़ाइल नाम को ब्राउज़र में वापस कर देगा। इस प्रकार, एप्लिकेशन केवल उन फ़ाइलों को पढ़ने और लिखने में सक्षम होगा जो उपयोगकर्ता ने स्पष्ट रूप से अनुमति दी थी। एप्लिकेशन को निर्देशिकाओं को स्वयं पढ़ने के लिए मना किया जा सकता है, ताकि फाइलों की सूची प्राप्त करना संभव न हो (हालांकि फाइलों की सूची प्राप्त करना काफी सुरक्षित है, मुझे लगता है)। आप कार्यालय कार्यक्रमों (और कई अन्य) के साथ भी ऐसा कर सकते हैं। यदि सभी मैक्रोज़ और अन्य असुरक्षित चीज़ों को वर्ड प्रोसेसर में अनुमति दी जाती है, तो कुछ भी खराब करना असंभव होगा, शायद कार्यालय के दस्तावेजों को छोड़कर, और फिर केवल वे जो पहले से ही खुले हैं। उपयोगकर्ता के लिए, सब कुछ वैसा ही रहेगा, जैसे एक ही कार्यक्रम, एक ही संवाद, कुछ नया नहीं, कोई असुविधा नहीं। प्रोग्रामर के लिए, आप बदलाव के बिना भी कर सकते हैं, डायलॉग बॉक्स डिस्प्ले फ़ंक्शन के सभी समान कॉल। यह केवल विजेट पुस्तकालयों (Gtk, Qt, ...) को ठीक करने के लिए आवश्यक होगा



चौथा बिंदु रहा। इसकी आवश्यकता क्यों है? यह असत्यापित स्रोतों से अनुप्रयोगों के सुरक्षित लॉन्च के लिए आवश्यक है। अब जब यह आएगा, GNU / Linux अधिक लोकप्रिय हो जाएगा और इसके लिए बहुत सारे अनुप्रयोग होंगे, और फिर चौथे बिंदु की आवश्यकता होगी। एक नियम के रूप में, विश्वसनीय स्रोतों से जीएनयू / लिनक्स अनुप्रयोगों में रिपॉजिटरी हैं, लेकिन ऐसी परिस्थितियां हैं जब आपको एक असत्यापित स्रोत से एप्लिकेशन इंस्टॉल करने की आवश्यकता होती है। चौथा आइटम निम्नानुसार है: सिस्टम में सुरक्षा प्रोफाइल के लिए टेम्पलेट हैं, वे मानक हैं; निष्पादन योग्य फ़ाइल में प्रोफ़ाइल नाम / आईडी शामिल है। आवेदन शुरू करते समय, प्रोफ़ाइल लागू की जाती है, यदि आवेदन में आईडी / प्रोफ़ाइल नाम नहीं होता है या यदि इसके लिए संभावित खतरनाक अधिकारों की आवश्यकता होती है, तो उपयोगकर्ता को एक चेतावनी प्रदर्शित की जाती है। इस प्रकार, उपयोगकर्ता असत्यापित स्रोतों से बड़ी संख्या में एप्लिकेशन डाउनलोड और चलाने में सक्षम होगा, ज़ाहिर है, सिस्टम एप्लिकेशन यहां नहीं हैं, क्योंकि उन्हें कई संभावित खतरनाक विशेषाधिकारों की आवश्यकता होगी। हर छोटी चीज, जैसे खेल, छोटी उपयोगिताओं, स्क्रीनसेवर, आदि। इसे शांति से लॉन्च करना संभव होगा, और यदि एप्लिकेशन को किसी विशेष अधिकार की आवश्यकता नहीं है, तो उपयोगकर्ता को बिल्कुल भी सूचित नहीं किया जा सकता है (" www.zlovredi.ru से डाउनलोड किया गया है । क्या आप सुनिश्चित हैं कि आप एक निष्पादन योग्य स्रोत से निष्पादन योग्य फ़ाइल चलाना चाहते हैं?"), और? तुरंत दौड़ो। टेम्प्लेट और नाम / आईडी प्रोफाइल क्यों हैं, और निष्पादन योग्य फाइलों में सीधे सुरक्षा प्रोफाइल ही नहीं हैं? क्योंकि तब आपको एक पार्सर की आवश्यकता होगी जो प्रोफ़ाइल की जांच करेगा और उसकी सुरक्षा के बारे में एक निष्कर्ष जारी करेगा, और इस बार स्टार्टअप पर, इसके अलावा, असत्यापित स्रोत से सुरक्षा प्रोफ़ाइल के माध्यम से कर्नेल पर एक हमले को बाहर रखा गया है (आपने कभी कुछ नहीं लिखा ... और कर्नेल में DoS होगा) । यह सब, जहां तक ​​मैं बता सकता हूं, मोबाइल उपकरणों के लिए अनुप्रयोगों के साथ काम करना जैसा दिखता है।

मैंने ऐसा क्यों लिखा?

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



PS मुझे यकीन नहीं है कि मैंने इस विषय को लिखने के लिए एक उपयुक्त ब्लॉग चुना है। यदि वह यहां नहीं है, तो मैं इसे सहन करूंगा।



[अद्यतन १]

एक छोटा सा जोड़ 1:

मैं यहाँ जो वर्णन कर रहा हूँ वह मौजूदा AppArmor का पूरक है। एप्लिकेशन से स्वयं एक प्रोफ़ाइल बनाने के लिए एपीआई, AppArmor प्रोफाइल के लिए एक प्रतिस्थापन नहीं है जो अब पाठ फ़ाइलों में मौजूद है, लेकिन एक अतिरिक्त है।

ऐसा लगता है कि यह कुछ मामलों में उपयोगी हो सकता है:

- एक एप्लिकेशन उपयोग के आधार पर विभिन्न प्रोफाइल के साथ काम करने में सक्षम होगा, अर्थात। अलग-अलग तरीकों से अपने अधिकारों को काटें।

- आप लॉन्च के तुरंत बाद अधिकारों को ट्रिम नहीं कर पाएंगे, लेकिन कुछ समय बाद।

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

यानी यह एक ऐड-ऑन है जो लचीलापन जोड़ता है, प्रतिस्थापन नहीं।



छोटा जोड़ 2:

अधिकार हमेशा ही कम किए जा सकते हैं। केवल पैराग्राफ 3 में ही उसे अनुमति दी जा सकती है जो निषिद्ध था।

केवल एक विशेषाधिकार प्राप्त कार्यक्रम और केवल पहले से चल रही एक और प्रक्रिया अनुमति दे सकती है।

ऊपर विस्तार से वर्णित है, फिर से पढ़ें।



छोटा जोड़ 3:

क्लासिक AppArmor के मामले में, अधिकारों की यह प्रणाली अधिकारों की शास्त्रीय प्रणाली की तुलना में कम प्राथमिकता होगी। यानी यदि उपयोगकर्ता स्वयं के लिए कुछ संभव नहीं है, तो यह सभी अनुप्रयोगों के लिए संभव नहीं है, चाहे उनकी प्रोफाइल कुछ भी हो।



[अद्यतन २]

यह पता चला है कि मैक ओएस एक्स कुछ इसी तरह का विकास कर रहा है।

techjournal.318.com/security/a-brief-introduction-to-mac-os-x-sandbox-technology

developer.apple.com/library/ios/#DOCUMENTATION/Security/Conceptual/Security_Overview/Security_Services/Security_Services.html

लिंक के लिए int80h के लिए धन्यवाद।

वैसे, मेरे द्वारा वर्णित एक विशेष एपीआई के माध्यम से आवेदन से ही अधिकारों को प्रतिबंधित करने का एक अवसर है, और जैसा कि वे टिप्पणियों में कहते हैं "करने की आवश्यकता नहीं है"।



दिलचस्प है, क्या विंडोज में पहले से ही कुछ समान है?