सुरक्षा लागू करना

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

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

इन सर्वोत्तम प्रथाओं को अपनाने की सुविधा के लिए, जहां संभव हो एंड्रॉइड सुरक्षा टीम एंड्रॉइड संगतता परीक्षण सूट (सीटीएस) और एंड्रॉइड लिंट में परीक्षण शामिल करती है। हम डिवाइस कार्यान्वयनकर्ताओं को ऐसे परीक्षणों में योगदान करने के लिए प्रोत्साहित करते हैं जो अन्य एंड्रॉइड उपयोगकर्ताओं की मदद कर सकते हैं ( root/cts/tests/tests/security/src/android/security/cts पर सुरक्षा-संबंधित परीक्षण देखें)।

विकास की प्रक्रिया

अपनी विकास प्रक्रियाओं और परिवेश में निम्नलिखित सर्वोत्तम प्रथाओं का उपयोग करें।

स्रोत कोड की समीक्षा करना

स्रोत कोड समीक्षा इस दस्तावेज़ में पहचाने गए मुद्दों सहित सुरक्षा मुद्दों की एक विस्तृत श्रृंखला ��ा पता लगा सकती है। एंड्रॉइड मैन्युअल और स्वचालित स्रोत कोड समीक्षा दोनों को दृढ़ता से प्रोत्साहित करता है। सर्वोत्तम प्रथाएं:

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

स्वचालित परीक्षण का उपयोग करना

स्वचालित परीक्षण नीचे चर्चा किए गए कई मुद्दों सहित सुरक्षा मुद्दों की एक विस्तृत श्रृंखला का पता लगा सकता है। सर्वोत्तम प्रथाएं:

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

हस्ताक्षर प्रणाली छवियाँ

डिवाइस की अखंडता निर्धारित करने के लिए सिस्टम छवि का हस्ताक्षर महत्वपूर्ण है। सर्वोत्तम प्रथाएं:

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

आवेदनों पर हस्ताक्षर (एपीके)

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

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

अनुप्रयोगों का प्रकाशन

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

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

घटनाओं पर प्रतिक्रिया

बाहरी पक्षों के पास डिवाइस-विशिष्ट सुरक्षा मुद्दों के बारे में डिवाइस निर्माताओं से संपर्क करने की क्षमता होनी चाहिए। हम सुरक्षा घटनाओं के प्रबंधन के लिए एक सार्वजनिक रूप से सुलभ ईमेल पता बनाने की अनुशंसा करते हैं। सर्वोत्तम प्रथाएं:

• एक Security@your-company.com या समान पता बनाएं और उसका प्रचार करें।
• यदि आपको कई डिवाइस निर्माताओं से एंड्रॉइड ओएस या एंड्रॉइड डिवाइस को प्रभावित करने वाली सुरक्षा समस्या के बारे में पता चलता है, तो आपको सुरक्षा बग रिपोर्ट दर्ज करके एंड्रॉइड सुरक्षा टीम से संपर्क करना चाहिए।

उत्पाद कार्यान्वयन

किसी उत्पाद को लागू करते समय निम्नलिखित सर्वोत्तम प्रथाओं का उपयोग करें।

जड़ प्रक्रियाओं को अलग करना

रूट प्रक्रियाएं विशेषाधिकार वृद्धि हमलों का सबसे लगातार लक्ष्य हैं, इसलिए रूट प्रक्रियाओं की संख्या कम करने से विशेषाधिकार वृद्धि का जोखिम कम हो जाता है। सीटीएस में एक सूचनात्मक परीक्षण शामिल है जो रूट प्रक्रियाओं को सूचीबद्ध करता है। सर्वोत्तम प्रथाएं:

• डिवाइस को न्यूनतम आव��्यक क����� क��� ��ूट ���� ��ू�� ��ें चलाना चाहिए। जहां संभव हो, रूट प्रक्रिया के बजाय नियमित एंड्रॉइड प्रक्रिया का उपयोग करें। ICS गैलेक्सी नेक्सस में केवल छह रूट प्रक्रियाएं हैं: vold, inetd, zygote, tf_daemon, ueventd, और init। यदि किसी प्रक्रिया को किसी डिवाइस पर रूट के रूप में चलाना है, तो प्रक्रिया को AOSP सुविधा अनुरोध में दस्तावेज़ित करें ताकि इसकी सार्वजनिक रूप से समीक्षा की जा सके।
• जहां संभव हो, रूट कोड को अविश्वसनीय डेटा से अलग किया जाना चाहिए और आईपीसी के माध्यम से एक्सेस किया जाना चाहिए। उदाहरण के लिए, रूट कार्यक्षमता को बाइंडर के माध्यम से पहुंच योग्य एक छोटी सेवा तक कम करें और नेटवर्क ट्रैफ़िक को संभालने के लिए कम या कोई विशेषाधिकार वाले एप्लिकेशन पर हस्ताक्षर अनुमति के साथ सेवा को उजागर करें।
• रूट प्रक्रियाओं को नेटवर्क सॉकेट पर नहीं सुनना चाहिए।
• रूट प्रक्रियाओं को अनुप्रयोगों के लिए सामान्य-उद्देश्यीय रनटाइम प्रदान नहीं करना चाहिए (उदाहरण के लिए, जावा वीएम)।

सिस्टम ऐप्स को अलग करना

सामान्य तौर पर, पहले से इंस्टॉल किए गए ऐप्स को साझा सिस्टम यूआईडी के साथ नहीं चलना चाहिए। हालाँकि, यदि किसी ऐप के लिए सिस्टम या किसी अन्य विशेषाधिकार प्राप्त सेवा की साझा यूआईडी का उपयोग करना आवश्यक है, तो ऐप को किसी भी सेवा, प्रसारण रिसीवर, या सामग्री प्रदाताओं को निर्यात नहीं करना चाहिए जिन्हें उपयोगकर्ताओं द्वारा इंस्टॉल किए गए तृतीय-पक्ष ऐप्स द्वारा एक्सेस किया जा सकता है। सर्वोत्तम प्रथाएं:

• डिवाइस को सिस्टम के रूप में न्यूनतम आवश्यक कोड चलाना चाहिए। जहां संभव हो, सिस्टम यूआईडी का पुन: उपयोग करने के बजाय अपने स्वयं के यूआईडी के साथ एंड्रॉइड प्रक्रिया का उपयोग करें।
• जहां संभव हो, ��िस्टम कोड को अविश्वसनीय डेटा से अलग किया जाना चाहिए और आईपीसी को केवल अन्य विश्वसनीय प्रक्रियाओं के लिए उजागर किया जाना चाहिए।
• सिस्टम प्रक्रियाओं को नेटवर्क सॉकेट पर नहीं सुनना चाहिए।

पृथक्करण प्रक्रियाएं

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

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

SUID फ़ाइलें सुरक्षित करना

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

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

सीटीएस सत्यापनकर्ता में एक सूचनात्मक परीक्षण सूची SUID फ़ाइलें शामिल हैं; सीटीएस परीक्षणों के अनुसार कुछ सेटुइड फ़ाइलों की अनुमति नहीं है।

श्रवण सॉकेट को सुरक्षित करना

सीटीएस परीक्षण तब विफल हो जाते हैं जब कोई डिवाइस किसी पोर्ट, किसी इंटरफ़ेस पर सुन रहा होता है। विफलता की स्थिति में, एंड्रॉइड सत्यापित करता है कि निम्नलिखित सर्वोत्तम प्रथाएं उपयोग में हैं:

• डिवाइस पर कोई सुनने वाला पोर्ट नहीं होना चाहिए.
• श्रवण बंदरगाहों को ओटीए के बिना अक्षम किया जाना चाहिए। यह या तो सर्वर या उपयोगकर्ता-डिवाइस कॉन्फ़िगरेशन परिवर्तन हो सकता है।
• रूट प्रक्रियाओं को किसी भी पोर्ट पर नहीं सुनना चाहिए।
• सिस्टम यूआईडी के स्वामित्व वाली प्रक्रियाओं को किसी भी पोर्ट पर नहीं सुनना चाहिए।
• सॉकेट का उपयोग करने वाले स्थानीय आईपीसी के लिए, एप्लिकेशन को एक समूह तक सीमित पहुंच के साथ UNIX डोमेन सॉकेट का उपयोग करना चाहिए। आईपीसी के लिए एक फ़ाइल डिस्क्रिप्टर बनाएं और इसे एक विशिष्ट UNIX समूह के लिए +RW बनाएं। कोई भी क्लाइंट एप्लिकेशन उस UNIX समूह के भीतर होना चाहिए।
• एकाधिक प्रोसेसर वाले कुछ डिवाइस (उदाहरण के लिए एप्लिकेशन प्रोसेसर से अलग एक रेडियो/मॉडेम) प्रोसेसर के बीच संचार करने के लिए नेटवर्क सॉकेट का उपयोग करते हैं। ऐसे उदाहरणों में, अंतर-प्रोसेसर संचार के लिए उपयोग किए जाने वाले नेटवर्क सॉकेट को डिवाइस पर अनधिकृत अनुप्रयोगों द्वारा पहुंच को रोकने के लिए एक पृथक नेटवर्क इंटरफ़ेस का उपयोग करना चाहिए (अर्थात, डिवाइस पर अन्य अनुप्रयोगों द्वारा पहुंच को रोकने के लिए iptables का उपयोग करें)।
• श्रवण पोर्ट को संभालने वाले डेमॉन को विकृत डेटा के विरुद्ध मजबूत होना चाहिए। Google किसी अनधिकृत क्लाइंट और, जहां संभव हो, अधिकृत क्लाइंट का उपयोग करके पोर्ट के विरुद्ध फ़ज़-परीक्षण कर सकता है। किसी भी क्रैश को उचित गंभीरता के साथ बग के रूप में दर्ज किया जाएगा।

लॉगिंग डेटा

डेटा लॉग करने से उस डेटा के एक्सपोज़र का जोखिम बढ़ जाता है और सिस्टम प्रदर्शन कम हो जाता है। एंड्रॉइड डिवाइस पर डिफ़ॉल्ट रूप से इंस्टॉल किए गए एप्लिकेशन द्वारा संवेदनशील उपयोगकर्ता डेटा लॉग करने के परिणामस्वरूप कई सार्वजनिक सुरक्षा घटनाएं हुई हैं। सर्वोत्तम प्रथाएं:

• एप्लिकेशन या सिस्टम सेवाओं को तृतीय-पक्ष एप्लिकेशन से प्रदान किए गए डेटा को लॉग नहीं करना चाहिए जिसमें संवेदनशील जानकारी ��ामिल हो सकती है।
• सामान्य ऑपरेशन के हिस्से के रूप में एप्लिकेशन को किसी भी व्यक्तिगत पहचान योग्य जानकारी (पीआईआई) को लॉग नहीं करना चाहिए।

सीटीएस में ऐसे परीक्षण शामिल हैं जो सिस्टम लॉग में संभावित संवेदनशील जानकारी की उपस्थिति की जांच करते हैं।

निर्देशिका पहुंच सीमित करना

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

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

कॉन्फ़िगरेशन फ़ाइलों को सुरक्षित करना

कई ड्राइवर और सेवाएँ /system/etc और /data जैसी निर्देशिकाओं में संग्रहीत कॉन्फ़िगरेशन और डेटा फ़ाइलों पर निर्भर करते हैं। यदि इन फ़ाइलों को एक विशेषाधिकार प्राप्त प्रक्रिया द्वारा संसाधित किया जाता है और विश्व-लेखन योग्य हैं, तो किसी ऐप के लिए विश्व-लेखन योग्य फ़ाइल में दुर्भावनापूर्ण सामग्री तैयार करके प्रक्रिया में भेद्यता का फायदा उठाना संभव है। सर्वोत्तम प्रथाएं:

• विशेषाधिकार प्राप्त प्रक्रियाओं द्वारा उपयोग की जाने वाली कॉन्फ़िगरेशन फ़ाइलें विश्व पठनीय नहीं होनी चाहिए।
• विशेषाधिकार प्राप्त प्रक्रियाओं द्वारा उपयोग की जाने वाली कॉन्फ़िगरेशन फ़ाइलें विश्व लेखन योग्य नहीं होनी चाहिए।

देशी कोड पुस्तकालयों का भंडारण

विशेषाधिकार प्राप्त डिवाइस निर्माता प्रक्रियाओं द्वारा उपयोग किया जाने वाला कोई भी कोड /vendor या /system में होना चाहिए; ये फ़ाइल सिस्टम बूट पर केवल-पढ़ने के लिए माउंट किए गए हैं। सर्वोत्तम अभ्यास के रूप में, सिस्टम द्वारा उपयोग की जाने वाली लाइब्रेरी या डिवाइस पर इंस्टॉल किए गए अन्य अत्यधिक-वि��ेषाधिकार प्राप्त ऐप्स भी इन फ़ाइल सिस्टम में होने चाहिए। यह एक सुरक्षा भेद्यता को रोक सकता है जो एक हमलावर को उस कोड को नियंत्रित करने की अनुमति दे सकता है जिसे एक विशेषाधिकार प्राप्त प्रक्रिया निष्पादित करती है।

डिवाइस ड्राइवर पहुंच को सीमित करना

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

एडीबी को अक्षम करना

एंड्रॉइड डिबग ब्��िज (एडीबी) एक मूल्यवान विकास और डिबगिंग टूल है, लेकिन इसे नियंत्रित, सुरक्षित वातावरण में उपयोग के लिए डिज़ाइन किया गया है और इसे सामान्य उपयोग के लिए सक्षम नहीं किया जाना चाहिए। सर्वोत्तम प्रथाएं:

• एडीबी को डिफ़ॉल्ट रूप से अक्षम किया जाना चाहिए।
• एडीबी को कनेक्शन स्वीकार करने से पहले उपयोगकर्ता को इसे चालू करने की आवश्यकता होगी।

बूटलोडर्स को अनलॉक करना

कई एंड्रॉइड डिवाइस अनलॉकिंग का समर्थन करते हैं, जिससे डिवाइस मालिक सिस्टम विभाजन को संशोधित करने और/या एक कस्टम ऑपरेटिंग सिस्टम स्थापित करने में सक्षम होता है। सामान्य उपयोग के मामलों में तृतीय-पक्ष ROM स्थापित करना और डिवाइस पर सिस्टम-स्तरीय विकास करना शामिल है। उदाहरण के लिए, Google Nexus डिवाइस का मालिक अनलॉकिंग प्रक्रिया शुरू करने के लिए fastboot oem unlock चला सकता है, जो उपयोगकर्ता को निम्नलिखित संदेश प्रस्तुत करता है:

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

• जब उपयोगकर्ता द्वारा अनलॉकिंग कमांड की पुष्टि की जाती है, तो डिवाइस को तत्काल डेटा वाइप शुरू करना होगा। सुरक्षित विलोपन पूरा होने तक unlocked फ़्लैग को सेट नहीं किया जाना चाहिए।
• यदि सुरक्षित विलोपन पूरा नहीं किया जा सकता है, तो डिवाइस को लॉक स्थिति में रहना चाहिए।
• यदि अंतर्निहित ब्लॉक डिवाइस द्वारा समर्थित है, ioctl(BLKSECDISCARD) या समकक्ष का उपयोग किया जाना चाहिए। ईएमएमसी उपकरणों के लिए, इसका मतलब सिक्योर इरेज़ या सिक्योर ट्रिम कमांड का उपयोग करना है। ईएमएमसी 4.5 और बाद के संस्करण के लिए, इसका अर्थ है सामान्य इरेज़ या ट्रिम का उपयोग करना और उसके बाद सैनिटाइज़ ऑपरेशन करना।
• यदि BLKSECDISCARD अंतर्निहित ब्लॉक डिवाइस द्वारा समर्थित नहीं है, तो इसके बजाय ioctl(BLKDISCARD) उपयोग किया जाना चाहिए। ईएमएमसी उपकरणों पर, यह एक सामान्य ट्रिम ऑपरेशन है।
• यदि BLKDISCARD समर्थित नहीं है, तो सभी शून्यों के साथ ब्��ॉक डिवाइस को ओवरराइट करना स्वीकार्य है।
• अंतिम उपयोगकर्ता के पास यह विकल्प होना चाहिए कि विभाजन को फ्लैश करने से पहले उपयोगकर्ता डेटा को मिटा दिया जाए। उदाहरण के लिए, नेक्सस डिवाइस पर, यह fastboot oem lock कमांड के माध्यम से किया जाता है।
• एक उपकरण इफ्यूज़ या इसी तरह के तंत्र के माध्यम से रिकॉर्ड कर सकता है, चाहे कोई उपकरण अनलॉक किया गया हो और/या पुनः लॉक किया गया हो।

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

एक डिवाइस जिसे अनलॉक किया गया है उसे बाद में fastboot oem lock कमांड का उपयोग करके पुनः लॉक किया जा सकता है। बूटलोडर को लॉक करने से नए कस्टम ओएस के साथ उपयोगकर्ता डेटा की वही सुरक्षा मिलती है जो मूल डिवाइस निर्माता ओएस के साथ उपलब्ध थी (उदाहरण के लिए यदि डिवाइस को दोबारा अनलॉक किया जाता है तो उपयोगकर्ता डेटा मिटा दिया जाएगा)।