इस पेज का अनुवाद Cloud Translation API से किया गया है.

SELinux को लागू करना

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

मुख्य फ़ाइलें

SELinux को सक्षम करने के लिए, नवीनतम Android कर्नेल को एकीकृत करें और फिर सिस्टम/सेपॉलिसी निर्देशिका में मिली फ़ाइलों को शामिल करें। संकलित होने पर, उन फ़ाइलों में SELinux कर्नेल सुरक्षा नीति शामिल होती है और यह अपस्ट्रीम Android ऑपरेटिंग सिस्टम को कवर करती है।

सामान्य तौर पर, आपको system/sepolicy फाइलों को सीधे संशोधित नहीं करना चाहिए। इसके बजाय, /device/ manufacturer / device-name /sepolicy निर्देशिका में अपनी डिवाइस-विशिष्ट नीति फ़ाइलें जोड़ें या संपादित करें। Android 8.0 और उच्चतर में, आपके द्वारा इन फ़ाइलों में किए गए परिवर्तन केवल आपकी विक्रेता निर्देशिका में नीति को प्रभावित करना चाहिए। एंड्रॉइड 8.0 और उच्चतर में सार्वजनिक सेपॉलिसी को अलग करने के बारे में अधिक जानकारी के लिए, एंड्रॉइड 8.0+ में सेपॉलिसी को कस्टमाइज़ करना देखें। Android संस्करण के बावजूद, आप अभी भी इन फ़ाइलों को संशोधित कर रहे हैं:

नीति फ़ाइलें

*.te के साथ समाप्त होने वाली फ़ाइलें SELinux नीति स्रोत फ़ाइलें हैं, जो डोमेन और उनके लेबल को परिभाषित करती हैं। आपको /device/ manufacturer / device-name /sepolicy में नई नीति फ़ाइलें बनाने की आवश्यकता हो सकती है, लेकिन जहां संभव हो, आपको मौजूदा फ़ाइलों को अपडेट करने का प्रयास करना चाहिए।

प्रसंग फ़ाइलें

प्रसंग फ़ाइलें वे हैं जहाँ आप अपनी वस्तुओं के लिए लेबल निर्दिष्ट करते हैं।

file_contexts फाइलों को लेबल प्रदान करता है और विभिन्न यूजरस्पेस घटकों द्वारा उपयोग किया जाता है। जैसे ही आप नई नीतियां बनाते हैं, फाइलों को नए लेबल असाइन करने के लिए इस फ़ाइल को बनाएं या अपडेट करें। नया file_contexts लागू करने के लिए, फाइल सिस्टम छवि को फिर से बनाएं या फिर से लेबल की जाने वाली फ़ाइल पर restorecon चलाएँ। उन्नयन पर, file_contexts में परिवर्तन स्वचालित रूप से सिस्टम और उपयोगकर्ताडेटा विभाजन पर अपग्रेड के हिस्से के रूप में लागू होते हैं। आपके init में restorecon_recursive कॉल्स को जोड़कर अन्य पार्टिशन में अपग्रेड होने पर भी परिवर्तन स्वचालित रूप से लागू किए जा सकते हैं। board .rc फ़ाइल विभाजन के बाद पढ़ने-लिखने के लिए माउंट किया गया है।
genfs_contexts फाइल सिस्टम को लेबल प्रदान करता है, जैसे कि proc या vfat जो विस्तारित विशेषताओं का समर्थन नहीं करता है। यह कॉन्फ़िगरेशन कर्नेल नीति के भाग के रूप में लोड किया गया है, लेकिन हो सकता है कि परिवर्तन इन-कोर इनोड के लिए प्रभावी न हों, परिवर्तन को पूरी तरह से लागू करने के लिए फ़ाइल सिस्टम को रीबूट या अनमाउंट और री-माउंट करने की आवश्यकता होती है। विशिष्ट लेबल को विशिष्ट माउंट को भी सौंपा जा सकता है, जैसे कि context=mount विकल्प का उपयोग करके vfat ।
properties_contexts एंड्रॉइड सिस्टम property_contexts को लेबल असाइन करता है ताकि यह नियंत्रित किया जा सके कि कौन सी प्रक्रियाएं उन्हें सेट कर सकती हैं। यह कॉन्फ़िगरेशन स्टार्टअप के दौरान init प्रक्रिया द्वारा पढ़ा जाता है।
service_contexts एंड्रॉइड बाइंडर सेवाओं को लेबल असाइन करता है ताकि यह नियंत्रित किया जा सके कि कौन सी प्रक्रियाएं सेवा के लिए एक बाइंडर संदर्भ जोड़ (रजिस्टर) और ढूंढ (लुकअप) कर सकती हैं। यह कॉन्फ़िगरेशन स्टार्टअप के दौरान servicemanager प्रक्रिया द्वारा पढ़ा जाता है।
seapp_contexts ऐप प्रक्रियाओं और /data/data निर्देशिकाओं को लेबल असाइन करता है। इस कॉन्फ़िगरेशन को प्रत्येक ऐप लॉन्च पर zygote प्रक्रिया द्वारा और स्टार्टअप के दौरान installd द्वारा पढ़ा जाता है।
mac_permissions.xml ऐप्स को उनके हस्ताक्षर और वैकल्पिक रूप से उनके पैकेज नाम के आधार पर एक seinfo टैग असाइन करता है। तब seinfo टैग को उस seinfo टैग के साथ सभी ऐप्स को एक विशिष्ट लेबल असाइन करने के लिए seapp_contexts फ़ाइल में एक कुंजी के रूप में उपयोग किया जा सकता है। यह कॉन्फ़िगरेशन स्टार्टअप के दौरान system_server द्वारा पढ़ा जाता है।
keystore2_key_contexts Keystore 2.0 नेमस्पेस को लेबल असाइन करता है। ये नेमस्पेस keystore2 डेमॉन द्वारा लागू किया जाता है। कीस्टोर ने हमेशा यूआईडी/एआईडी आधारित नेमस्पेस प्रदान किया है। कीस्टोर 2.0 अतिरिक्त रूप से सेपॉलिसी परिभाषित नेमस्पेस को लागू करता है। इस फ़ाइल के प्रारूप और परंपराओं का विस्तृत विवरण यहां पाया जा सकता है।

बोर्डकॉन्फिग.एमके मेकफाइल

नीति और संदर्भ फ़ाइलों को संपादित करने या जोड़ने के बाद, sepolicy उपनिर्देशिका और प्रत्येक नई नीति फ़ाइल को संदर्भित करने के लिए अपने /device/ manufacturer / device-name /BoardConfig.mk को अपडेट करें। 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 अद्यतन स्थान पर होते हैं, तो नई नीति सेटिंग्स स्वचालित रूप से अंतिम कर्नेल नीति फ़ाइल में बन जाती हैं। डिवाइस पर सेपॉलिसी कैसे बनाई जाती है, इस बारे में अधिक जानकारी के लिए बिल्डिंग सेपॉलिसी देखें।

कार्यान्वयन

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 ऐसे किसी भी डोमेन की पहचान करने के लिए जिसमें डोमेन प्रकार नहीं है। init में नियम जोड़ने से बचने के लिए उन्हें अपनी विकास प्रक्रिया में जल्दी एक डोमेन दें या अन्यथा भ्रमित करने वाली init एक्सेस को अपनी नीति में शामिल करें।
BOARD_SEPOLICY_* चर का उपयोग करने के लिए BOARD_CONFIG.mk सेट करें। इसे स्थापित करने के विवरण के लिए system/sepolicy में README देखें।
इनिट की जांच करें। device .rc और fstab। device फ़ाइल और सुनिश्चित करें कि mount का प्रत्येक उपयोग ठीक से लेबल किए गए फाइल सिस्टम से मेल खाता है या एक context= mount विकल्प निर्दिष्ट है।
प्रत्येक इनकार के माध्यम से जाएं और प्रत्येक को ठीक से संभालने के लिए SELinux नीति बनाएं। अनुकूलन में उदाहरण देखें।

आपको AOSP में नीतियों के साथ शुरुआत करनी चाहिए और फिर अपने स्वयं के अनुकूलन के लिए उन पर निर्माण करना चाहिए। नीति रणनीति के बारे में अधिक जानकारी के लिए और इनमें से कुछ चरणों को करीब से देखने के लिए, SELinux नीति लिखना देखें।

बक्सों का इस्तेमाल करें

अपने स्वयं के सॉफ़्टवेयर और संबद्ध SELinux नीतियों को तैयार करते समय विचार करने के लिए कारनामों के विशिष्ट उदाहरण यहां दिए गए हैं:

सिम्लिंक - क्योंकि सिम्लिंक फाइलों के रूप में दिखाई देते हैं, उन्हें अक्सर फाइलों के रूप में पढ़ा जाता है, जिससे शोषण हो सकता है। उदाहरण के लिए, कुछ विशेषाधिकार प्राप्त घटक, जैसे कि init , कुछ फ़ाइलों की अनुमतियों को बदल देते हैं, कभी-कभी अत्यधिक खुले होने के लिए।

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

सिस्टम फ़ाइलें - सिस्टम फ़ाइलों के वर्ग पर विचार करें जिन्हें केवल सिस्टम सर्वर द्वारा संशोधित किया जाना चाहिए। फिर भी, चूंकि netd , init , और vold रूट के रूप में चलते हैं, वे उन सिस्टम फ़ाइलों तक पहुंच सकते हैं। इसलिए यदि netd से समझौता किया जाता है, तो यह उन फ़ाइलों और संभावित रूप से सिस्टम सर्वर से समझौता कर सकता है।

SELinux के साथ, आप उन फ़ाइलों को सिस्टम सर्वर डेटा फ़ाइलों के रूप में पहचान सकते हैं। इसलिए, एकमात्र डोमेन जिसके पास पढ़ने/लिखने की पहुंच है, वह सिस्टम सर्वर है। भले ही netd समझौता हो गया हो, यह डोमेन को सिस्टम सर्वर डोमेन में स्विच नहीं कर सका और उन सिस्टम फ़ाइलों तक पहुंच नहीं सका, हालांकि यह रूट के रूप में चलता है।

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

setattr - chmod और chown जैसे कमांड के लिए, आप उन फाइलों के सेट की पहचान कर सकते हैं जहां संबंधित डोमेन setattr का संचालन कर सकता है। इसके बाहर की कोई भी चीज़ इन परिवर्तनों से, यहाँ तक कि मूल रूप से भी, निषिद्ध की जा सकती है। तो एक एप्लिकेशन chmod चला सकता है और उन लेबल वाले app_data_files के खिलाफ chown चला सकता है लेकिन shell_data_files या system_data_files नहीं।