SELinux को डिफ़ॉल्ट-अस्वीकार करने पर सेट अप किया गया है, जिसका मतलब है कि जिसमें कर्नेल में एक हुक होता है, तो नीति के तहत इसकी अनुमति साफ़ तौर पर दी जानी चाहिए. इसका मतलब है कि नीति फ़ाइल में, नियमों, टाइप, क्लास, अनुमतियों वगैरह के बारे में काफ़ी जानकारी होती है. SELinux के बारे में पूरी जानकारी इस दस्तावेज़ के दायरे में नहीं आता, लेकिन आपको लिखने के तरीके की जानकारी है नए Android डिवाइस लाते समय, अब नीति के नियम ज़रूरी हो गए हैं. कई SELinux के संबंध में पहले से ही बहुत सारी जानकारी उपलब्ध है. सहायता टीम से मदद लें दस्तावेज़ पढ़ें.
मुख्य फ़ाइलें
SELinux को चालू करने के लिए, नया Android कर्नेल पर क्लिक करें और फिर इसमें मिली फ़ाइलों को शामिल करें सिस्टम/से-नीति डायरेक्ट्री. कंपाइल किए जाने पर, उन फ़ाइलों में SELinux कर्नेल सुरक्षा अपस्ट्रीम Android ऑपरेटिंग सिस्टम की नीति और शर्तों को पूरा करती है.
आम तौर पर, आपको system/sepolicy फ़ाइलों में बदलाव नहीं करना चाहिए
सकता है. इसके बजाय, डिवाइस के हिसाब से बनी नीति की फ़ाइलें यहां जोड़ें या उनमें बदलाव करें
/device/manufacturer/device-name/sepolicy अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
डायरेक्ट्री. Android 8.0 और इसके बाद के वर्शन में, इन फ़ाइलों में किए गए बदलावों का असर सिर्फ़ आपकी वेंडर डायरेक्ट्री में मौजूद नीति पर पड़ेगा. Android 8.0 और उसके बाद के वर्शन में, सार्वजनिक सेपॉलिसी को अलग करने के बारे में ज़्यादा जानकारी के लिए, Android 8.0 और उसके बाद के वर्शन में SEPolicy को पसंद के मुताबिक बनाना लेख पढ़ें. Android के वर्शन के बावजूद, आपको अब भी इन फ़ाइलों में बदलाव करना होगा:
नीति की फ़ाइलें
*.te पर खत्म होने वाली फ़ाइलें, SELinux नीति की सोर्स फ़ाइलें होती हैं. ये फ़ाइलें, SELinux नीति की सोर्स फ़ाइलें होती हैं
डोमेन और उनके लेबल को परिभाषित कर सकते हैं. आपको /device/manufacturer/device-name/sepolicy में नई नीति फ़ाइलें बनानी पड़ सकती हैं. हालांकि, जहां भी हो सके वहां मौजूदा फ़ाइलों को अपडेट करने की कोशिश करें.
कॉन्टेक्स्ट फ़ाइलें
कॉन्टेक्स्ट फ़ाइलें ऐसी जगहें होती हैं जहां अपने ऑब्जेक्ट के लिए लेबल तय किए जाते हैं.
file_contexts, फ़ाइलों को लेबल असाइन करता है और इसका इस्तेमाल, उपयोगकर्ता के अलग-अलग कॉम्पोनेंट करते हैं. नई नीतियां बनाते समय, फ़ाइलों को नए लेबल असाइन करने के लिए, यह फ़ाइल बनाएं या अपडेट करें. नयाfile_contextsलागू करने के लिए, फ़ाइल सिस्टम इमेज को फिर से बनाएं या जिस फ़ाइल को फिर से लेबल करना है उस परrestoreconचलाएं. अपग्रेड करने पर,file_contextsमें किए गए बदलाव यह सुविधा, सिस्टम और उपयोगकर्ता डेटा के पार्टिशन पर अपने-आप लागू हो जाती है. अपग्रेड करें. दूसरे वर्शन पर अपग्रेड करने पर, बदलाव अपने-आप लागू हो जाएंगे अपने आप मेंrestorecon_recursiveकॉल जोड़कर विभाजन विभाजन माउंट करने के बाद init.board.rc फ़ाइल पढ़ें-लिखें.genfs_contexts,procयाvfatजैसे फ़ाइल सिस्टम को लेबल असाइन करता है. ये फ़ाइल सिस्टम, एक्सटेंडेड एट्रिब्यूट के साथ काम नहीं करते. यह कॉन्फ़िगरेशन, कर्नेल नीति के हिस्से के तौर पर लोड किया जाता है. हालांकि, हो सकता है कि इन-कोर इनोड के लिए बदलाव लागू न हों. बदलाव को पूरी तरह से लागू करने के लिए, डिवाइस को रीबूट करना पड़ सकता है या फ़ाइल सिस्टम को अनमाउंट करके फिर से माउंट करना पड़ सकता है. खास माउंट के लिए भी खास लेबल असाइन किए जा सकते हैं. जैसे,context=mountविकल्प का इस्तेमाल करकेvfat.property_contexts, Android सिस्टम प्रॉपर्टी को लेबल असाइन करता है, ताकि यह कंट्रोल किया जा सके कि कौनसी प्रोसेस उन्हें सेट कर सकती हैं. इस कॉन्फ़िगरेशन को स्टार्टअप के दौरान,initप्रोसेस पढ़ती है.service_contexts, Android बाइंडर सेवाओं को इनके लिए लेबल असाइन करता है यह कंट्रोल करें कि कौनसी प्रोसेस, बाइंडर (रजिस्टर) कर सकती हैं और बाइंडर ढूंढ सकती हैं देखें. इस कॉन्फ़िगरेशन को स्टार्टअप के दौरान,servicemanagerप्रोसेस पढ़ती है.seapp_contexts, ऐप्लिकेशन की प्रोसेस और/data/dataडायरेक्ट्री को लेबल असाइन करता है. इस कॉन्फ़िगरेशन को ऐप्लिकेशन के हर लॉन्च परzygoteप्रोसेस और स्टार्टअप के दौरानinstalldप्रोसेस पढ़ती है.mac_permissions.xml, ऐप्लिकेशन के हस्ताक्षर और पैकेज के नाम के आधार पर, ऐप्लिकेशन कोseinfoटैग असाइन करता है. कॉन्टेंट बनाने इसके बाद,seinfoटैग को उन सभी ऐप्लिकेशन को कोई खास लेबल असाइन करने के लिएseapp_contextsफ़ाइल जिनमें वहseinfoटैग. स्टार्टअप के दौरान,system_serverइस कॉन्फ़िगरेशन को पढ़ता है.keystore2_key_contexts, कीस्टोर 2.0 नेमस्पेस को लेबल असाइन करता है. ये नेमस्पेस, कीस्टोर2 डीमन से लागू किए जाते हैं. Keystore में हमेशा UID/AID पर आधारित नेमस्पेस उपलब्ध होते हैं. Keystore 2.0, sepolicy के मुताबिक तय किए गए नेमस्पेस को भी लागू करता है. इस कैंपेन के फ़ॉर्मैट और तौर-तरीकों के बारे में पूरी जानकारी फ़ाइल यहां उपलब्ध है.
BoardConfig.mk मेकफ़ाइल
नीति और संदर्भ फ़ाइलों में बदलाव करने या उन्हें जोड़ने के बाद, अपनी
/device/manufacturer/device-name/BoardConfig.mk अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
createfile को sepolicy सबडायरेक्ट्री और हर नई नीति फ़ाइल का संदर्भ देने के लिए.
BOARD_SEPOLICY वैरिएबल के बारे में ज़्यादा जानकारी के लिए,
system/sepolicy/README फ़ाइल देखें.
BOARD_SEPOLICY_DIRS += \
<root>/device/manufacturer/device-name/sepolicy
BOARD_SEPOLICY_UNION += \
genfs_contexts \
file_contexts \
sepolicy.te
फिर से बनाने के बाद, आपके डिवाइस पर SELinux चालू हो जाता है. अब इनमें से कोई एक काम करें: इस सेटिंग में आपके अतिरिक्त विकल्पों को शामिल करने के लिए, SELinux नीतियों को कस्टमाइज़ करना Android ऑपरेटिंग सिस्टम, जैसा कि इसमें बताया गया है पसंद के मुताबिक बनाएं या अपने मौजूदा सेटअप में शामिल है पुष्टि करना.
नई नीति फ़ाइलें और BoardConfig.mk अपडेट होने के बाद, नीति की नई सेटिंग, कर्नेल की नीति की फ़ाइनल फ़ाइल में अपने-आप बन जाती हैं. डिवाइस पर sepolicy बनाने के तरीके के बारे में ज़्यादा जानने के लिए, sepolicy बनाना लेख पढ़ें.
लागू करना
SELinux का इस्तेमाल शुरू करने के लिए:
- कर्नेल में SELinux को सक्षम करें:
CONFIG_SECURITY_SELINUX=yअभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है - kernel_cmdline या bootconfig पैरामीटर को बदलें, ताकि:
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
याBOARD_BOOTCONFIG := androidboot.selinux=permissive
यह सिर्फ़ डिवाइस के लिए नीति के शुरुआती डेवलपमेंट के लिए है. शुरुआती बूटस्ट्रॉप नीति सेट करने के बाद, इस पैरामीटर को हटा दें, ताकि आपका डिवाइस नीति लागू कर सके या सीटीएस की जांच में पास हो सके. - सिस्टम को अनुमति वाले मोड में बूट करें और देखें कि बूट करने पर कौनसी अनुमतियां अस्वीकार की गईं:
Ubuntu 14.04 या इसके बाद के वर्शन पर:adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
Ubuntu 12.04 पर:adb pull /sys/fs/selinux/policy adb logcat -b all | audit2allow -p policy
init: Warning! Service name needs a SELinux domain defined; please fix!निर्देशों और टूल के लिए, पुष्टि देखें के जैसी चेतावनियों के लिए, आउटपुट का आकलन करें.- उन डिवाइसों और अन्य नई फ़ाइलों की पहचान करें जिन्हें लेबल करने की ज़रूरत है.
- अपने ऑब्जेक्ट के लिए, मौजूदा या नए लेबल का इस्तेमाल करें.
*_contextsफ़ाइलों को देखकर पता लगाएं कि पहले चीज़ों को किस तरह लेबल किया गया था. साथ ही, नया लेबल असाइन करने के लिए, लेबल के मतलब के बारे में जानकारी का इस्तेमाल करें. आम तौर पर, यह एक ऐसा मौजूदा लेबल होता है जो नीति के मुताबिक होता है. हालांकि, कभी-कभी किसी नए लेबल की ज़रूरत पड़ती है. साथ ही, उस लेबल को ऐक्सेस करने के लिए नियमों की ज़रूरत होती है. सही संदर्भ फ़ाइलों में अपने लेबल जोड़ें. - ऐसे डोमेन या प्रोसेस की पहचान करें जिनके अपने सुरक्षा डोमेन होने चाहिए.
आपको हर एक के लिए पूरी तरह से नई नीति लिखनी होगी. सभी
उदाहरण के लिए,
initसे जनरेट की गई सेवाओं में खुद का मालिक है. नीचे दिए गए निर्देशों से उन लोगों का पता लगाने में मदद मिलती है जो चलते रहते हैं (लेकिन सभी सेवाओं के लिए इस तरह के इलाज की ज़रूरत है):
adb shell su -c ps -Z | grep init
adb shell su -c dmesg | grep 'avc: '
init.device.rcकी समीक्षा करके, उन डोमेन की पहचान करें जिनके लिए कोई डोमेन टाइप नहीं है. इन्हें अपने Google खाते में जल्द डोमेन देंinitया अन्य मामलों में,initको ऐक्सेस करने में परेशानी होती है. इसके लिए, खुद की नीति.BOARD_SEPOLICY_*वैरिएबल का इस्तेमाल करने के लिए,BOARD_CONFIG.mkसेट अप करें. देखें रीडमी इसे सेट अप करने की जानकारी के लिए,system/sepolicyमें जाएं.- init.device.rc और fstab.device फ़ाइल की जांच करें और
पक्का करें कि
mountका हर इस्तेमाल, सही तरीके से लेबल किए गए फ़ाइल सिस्टम से जुड़ा हो याcontext= mountविकल्प दिया गया हो. - हर अस्वीकार किए जाने पर देखें और हर अनुरोध को ठीक से मैनेज करने के लिए SELinux नीति बनाएं. पसंद के मुताबिक बनाने में दिए गए उदाहरण देखें.
पहले आपको एओएसपी की नीतियों से शुरुआत करनी चाहिए और फिर उन्हें सेटिंग में जाकर बदलाव कर सकते हैं. नीति की रणनीति के बारे में ज़्यादा जानने और इनमें से कुछ चरणों के बारे में ज़्यादा जानने के लिए, SELinux नीति लिखना लेख पढ़ें.
इस्तेमाल के उदाहरण
यहां ऐसे कारनामे से जुड़े कुछ खास उदाहरण दिए गए हैं जिन पर गौर करने की ज़रूरत है सॉफ़्टवेयर और उससे जुड़ी SELinux नीतियां:
सिंबल लिंक: सिंबल लिंक, फ़ाइलों की तरह दिखते हैं. इसलिए, उन्हें अक्सर फ़ाइलों के तौर पर पढ़ा जाता है. इससे, उनका गलत इस्तेमाल किया जा सकता है. उदाहरण के लिए, init जैसे कुछ खास कॉम्पोनेंट, कुछ फ़ाइलों की अनुमतियां बदलते हैं. ऐसा कभी-कभी बहुत ज़्यादा खुलापन के लिए किया जाता है.
इसके बाद, हमलावर उन फ़ाइलों को अपने कंट्रोल वाले कोड के सिम्लिंक से बदल सकते हैं. इससे, हमलावर अपनी पसंद की फ़ाइलों को बदल सकता है. हालांकि, अगर आपको पता है कि आपका ऐप्लिकेशन कभी भी किसी सिमलिंक पर नहीं जाता, तो SELinux की मदद से उसे ऐसा करने से रोका जा सकता है.
सिस्टम फ़ाइलें: सिस्टम फ़ाइलों की उस क्लास पर विचार करें जिसमें सिर्फ़ सिस्टम सर्वर को बदलाव करना चाहिए. हालांकि, netd,
init, और vold रूट के तौर पर चलते हैं, इसलिए वे उन सिस्टम फ़ाइलों को ऐक्सेस कर सकते हैं. इसलिए, अगर netd हैक हो जाता है, तो उन फ़ाइलों और सिस्टम सर्वर को भी हैक किया जा सकता है.
SELinux के साथ, आप उन फ़ाइलों की पहचान सिस्टम सर्वर डेटा फ़ाइलों के रूप में कर सकते हैं.
इसलिए, सिर्फ़ सिस्टम सर्वर वाले डोमेन के पास, उन्हें पढ़ने/लिखने का ऐक्सेस होता है.
भले ही netd हैक हो गया हो, लेकिन वह डोमेन को सिस्टम सर्वर डोमेन पर स्विच नहीं कर सका और उन सिस्टम फ़ाइलों को ऐक्सेस नहीं कर सका. भले ही, वह रूट के तौर पर चलता हो.
ऐप्लिकेशन का डेटा: एक और उदाहरण, फ़ंक्शन की वह क्लास है जिसे रूट के तौर पर चलाना ज़रूरी है, लेकिन उसे ऐप्लिकेशन का डेटा ऐक्सेस करने की अनुमति नहीं मिलनी चाहिए. यह शानदार है के आधार पर बड़े पैमाने पर दावे किए जा सकते हैं. उदाहरण के लिए, कुछ ऐसे डोमेन ऐप्लिकेशन के डेटा को इंटरनेट ऐक्सेस करने से रोका जा सके.
setattr: chmod और
chown जैसे निर्देशों के लिए, उन फ़ाइलों के सेट की पहचान की जा सकती है जहां उनसे जुड़ा
डोमेन setattr कर सकता है. इसके बाहर की कोई भी चीज़
इन परिवर्तनों से प्रतिबंधित है, यहां तक कि रूट द्वारा भी. इसलिए, कोई ऐप्लिकेशन
उन लेबल के ख़िलाफ़ chmod और chown
app_data_files है, लेकिन shell_data_files नहीं
या system_data_files.