🤹🏼 👋🏽 👩🏾‍🎤 एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। अनुप्रयोग फ्रेमवर्क स्तर पर सुरक्षा। बाइंडर आई.पी.सी. 🦅 🎇 ↪️

प्रविष्टि

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

लेखों की सूची

नीचे इस श्रृंखला में मेरे लेखों के लिंक दिए गए हैं:

मुझे IPC बाइंडर की आवश्यकता क्यों है?

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

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

एंड्रॉइड में, प्रक्रियाओं के बीच संकेतों और डेटा का आदान-प्रदान इंटर-प्रोसेस कम्युनिकेशन बाइंडर फ्रेमवर्क का उपयोग करके आयोजित किया जाता है। मानक सिस्टम V IPC फ्रेमवर्क इस ऑपरेटिंग सिस्टम द्वारा समर्थित नहीं है, विशेष रूप से, बायोनिक लिबास लापता हेडर फाइलें <sys / ipc.h>, <sys / sem.h>, <sys / shm.h>, <ys / msg.h >। कुछ विशिष्ट मामलों में (उदाहरण के लिए, ज़ीगोट डेमन के साथ बातचीत करने के लिए), यूनिक्स डोमेन सॉकेट्स का उपयोग किया जाता है । Intents सहित प्रक्रियाओं के बीच बातचीत के अन्य सभी तरीकों को Binder IPC का उपयोग करके लागू किया जाता है। यह ढांचा आपको दूरस्थ वस्तुओं के तुल्यकालिक और अतुल्यकालिक तरीके से कॉल करने की अनुमति देता है जैसे कि वे स्थानीय थे, प्रक्रियाओं के बीच फ़ाइल डिस्क्रिप्टर का आदान-प्रदान, मृत्यु से लिंक (एक निश्चित प्रक्रिया का एक बाइंडर बाधित होने पर स्वचालित अधिसूचना), आदि।

IPC काम कैसे करता है?

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

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

... /dev/ashmem 0666 root root /dev/binder 0666 root root ...

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

सर्वर साइड पर, प्रत्येक क्लाइंट अनुरोध के लिए एक अलग बाइंडर स्ट्रीम बनाई जाती है (ऊपर दी गई आकृति देखें)। इन थ्रेड्स को आमतौर पर Binder Thread #n के रूप में संदर्भित किया जाता है। वैसे, यदि मेमोरी मुझे सही सेवा देती है, तो अधिकतम बाइंडर की संख्या 255 है, और एक एकल लेनदेन में बिंडर के माध्यम से प्रेषित किए जा सकने वाले डेटा का अधिकतम आकार 1 एमबी है। अन्य प्रक्रियाओं से डेटा संचारित या प्राप्त करने वाले अनुप्रयोगों को विकसित करते समय इसे ध्यान में रखा जाना चाहिए।

सेवा प्रबंधक

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

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

सुरक्षा

बाइंडर फ्रेमवर्क सिस्टम में सुरक्षा के लिए स्वयं जिम्मेदार नहीं है, लेकिन यह इसे सुनिश्चित करने के लिए तंत्र प्रदान करता है। सबसे पहले, प्रत्येक लेनदेन में बाइंडर ड्राइवर उस प्रक्रिया के पीआईडी और यूआईडी लिखता है जो लेनदेन शुरू करता है। अनुरोध को निष्पादित करने या न करने का निर्णय लेने के लिए यह सेवा इस जानकारी का उपयोग कर सकती है। आप यह जानकारी android.os.Binder.getCallingUid () , android.os.Binder.getCallingPid () का उपयोग करके प्राप्त कर सकते हैं। दूसरे, चूंकि बाइंडर टोकन सिस्टम के भीतर अद्वितीय है और इसके मूल्य को प्राथमिकता नहीं पता है, इसलिए इसे स्वयं सुरक्षा टोकन के रूप में उपयोग किया जा सकता है (उदाहरण के लिए, यह लेख )।

निष्कर्ष

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

संदर्भ

अलेक्जेंडर गारजेंटा द्वारा "डीप डाइव इनटू बाइंडर फ्रेमवर्क"
करीम यागमोर द्वारा "एंबेडेड एंड्रॉइड"
“Android बाइंडर। एंड्रॉइड इंटरप्रॉसेस कम्युनिकेशन » थोरस्टेन श्रेबर द्वारा

एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। अनुप्रयोग फ्रेमवर्क स्तर पर सुरक्षा। बाइंडर आई.पी.सी.