Init प्रक्रिया में लगभग अप्रतिबंधित अनुमतियाँ हैं और बूट प्रक्रिया के दौरान सिस्टम को आरंभ करने के लिए सिस्टम और विक्रेता विभाजन दोनों से इनपुट स्क्रिप्ट का उपयोग करता है। यह पहुंच ट्रेबल सिस्टम/विक्रेता विभाजन में एक बड़ा छेद का कारण बनती है, क्योंकि विक्रेता स्क्रिप्ट इनिट को फ़ाइलों, संपत्तियों आदि तक पहुंचने का निर्देश दे सकती है जो स्थिर सिस्टम-विक्रेता एप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) का हिस्सा नहीं बनती हैं।
विक्रेता-विशिष्ट अनुमतियों के साथ /vendor में पाए गए आदेशों को चलाने के लिए विक्रेता init को एक अलग सुरक्षा-संवर्धित लिनक्स (SELinux) डोमेन vendor_init का उपयोग करके इस छेद को बंद करने के लिए डिज़ाइन किया गया है।
तंत्र
विक्रेता init SELinux संदर्भ u:r:vendor_init:s0 के साथ बूट प्रक्रिया के प्रारंभ में init की एक उपप्रक्रिया को फोर्क करता है। इस SELinux संदर्भ में डिफ़ॉल्ट init संदर्भ की तुलना में काफी कम अनुमतियाँ हैं और इसकी पहुंच फ़ाइलों, संपत्तियों आदि तक ही सीमित है जो या तो विक्रेता-विशिष्ट हैं या स्थिर सिस्टम-विक्रेता ABI का हिस्सा हैं।
Init यह देखने के लिए लोड होने वाली प्रत्येक स्क्रिप्ट की जाँच करता है कि क्या इसका पथ /vendor से शुरू होता है और यदि ऐसा है, तो इसे एक संकेत के साथ टैग करता है कि इसके आदेशों को विक्रेता init संदर्भ में चलाया जाना चाहिए। प्रत्येक init बिल्टिन को एक बूलियन के साथ एनोटेट किया जाता है जो निर्दिष्ट करता है कि विक्रेता init उपप्रोसेस में कमांड चलाया जाना चाहिए या नहीं:
- फ़ाइल सिस्टम तक पहुंचने वाले अधिकांश कमांड को विक्रेता init उपप्रोसेस में चलाने के लिए एनोटेट किया जाता है और इसलिए वे विक्रेता init SEPolicy के अधीन होते हैं।
- अधिकांश कमांड जो आंतरिक इनिट स्थिति को प्रभावित करते हैं (उदाहरण के लिए, सेवाओं को शुरू करना और रोकना) सामान्य इनिट प्रक्रिया के भीतर चलाए जाते हैं। इन आदेशों को अवगत कराया जाता है कि एक विक्रेता स्क्रिप्ट उन्हें अपने स्वयं के गैर-SELinux अनुमतियों को संभालने के लिए बुला रही है।
इनिट के मुख्य प्रोसेसिंग लूप में एक जांच होती है कि यदि एक कमांड को विक्रेता उपप्रोसेस में चलाने के लिए एनोटेट किया जाता है और एक विक्रेता स्क्रिप्ट से उत्पन्न होता है, तो वह कमांड अंतर-प्रक्रिया संचार (आईपीसी) के माध्यम से विक्रेता इनिट उपप्रोसेस को भेजा जाता है, जो कमांड चलाता है और परिणाम वापस init पर भेजता है।
विक्रेता Init का उपयोग करना
विक्रेता init डिफ़ॉल्ट रूप से सक्षम है और इसके प्रतिबंध /vendor विभाजन में मौजूद सभी init स्क्रिप्ट पर लागू होते हैं। विक्रेता init उन विक्रेताओं के लिए पारदर्शी होना चाहिए जिनकी स्क्रिप्ट पहले से ही केवल सिस्टम फ़ाइलों, संपत्तियों आदि तक नहीं पहुंच रही है।
हालाँकि, यदि किसी दिए गए विक्रेता स्क्रिप्ट में आदेश विक्रेता init प्रतिबंधों का उल्लंघन करते हैं, तो आदेश विफल हो जाएंगे। विफल आदेशों में init से कर्नेल लॉग में एक पंक्ति होती है (dmesg के साथ दिखाई देती है) जो विफलता का संकेत देती है। SELinux ऑडिट किसी भी विफल कमांड के साथ होता है जो SELinux नीति के कारण विफल हो जाता है। SELinux ऑडिट सहित विफलता का उदाहरण:
type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission deniedयदि कोई आदेश विफल हो जाता है, तो दो विकल्प हैं:
- यदि कमांड किसी इच्छित प्रतिबंध के कारण विफल हो रहा है (जैसे कि यदि कमांड सिस्टम फ़ाइल या प्रॉपर्टी तक पहुंच रहा है), तो कमांड को केवल स्थिर इंटरफेस के माध्यम से ट्रेबल-अनुकूल तरीके से फिर से कार्यान्वित किया जाना चाहिए। नेवरअल्लो नियम उन सिस्टम फ़ाइलों तक पहुँचने के लिए अनुमतियाँ जोड़ने से रोकते हैं जो स्थिर सिस्टम-विक्रेता एबीआई का हिस्सा नहीं हैं।
- यदि SELinux लेबल नया है और उसे पहले से ही सिस्टम
vendor_init.teमें अनुमतियाँ नहीं दी गई हैं और न ही everallow नियमों के माध्यम से अनुमतियाँ बाहर रखी गई हैं, तो नए लेबल को डिवाइस-विशिष्टvendor_init.teमें अनुमतियाँ दी जा सकती हैं।
एंड्रॉइड 9 से पहले लॉन्च होने वाले उपकरणों के लिए, डिवाइस-विशिष्ट vendor_init.te फ़ाइल में data_between_core_and_vendor_violators typeattribute जोड़कर नेवरअलॉज़ नियमों को दरकिनार किया जा सकता है।
कोड स्थान
विक्रेता init IPC के लिए अधिकांश तर्क system/core/init/subcontext.cpp में है।
कमांड की तालिका system/core/init/buildins.cpp में BuiltinFunctionMap क्लास में है और इसमें एनोटेशन शामिल हैं जो इंगित करते हैं कि कमांड को वेंडर इनिट सबप्रोसेस में चलना चाहिए या नहीं।
विक्रेता init के लिए SEPolicy को सिस्टम/sepolicy में निजी ( system/sepolicy/private/vendor_init.te ) और सार्वजनिक ( system/sepolicy/public/vendor_init.te ) निर्देशिकाओं में विभाजित किया गया है।