SELinux को लागू करना

SELinux को डिफ़ॉल्ट-अस्वीकार करने पर सेट अप किया गया है, जिसका मतलब है कि जिसमें कर्नेल में एक हुक होता है, तो नीति के तहत इसकी अनुमति साफ़ तौर पर दी जानी चाहिए. यह का मतलब है कि पॉलिसी फ़ाइल में नियम, टाइप, क्लास, अनुमतियां वगैरह. SELinux के बारे में पूरी जानकारी इस दस्तावेज़ के दायरे में नहीं आता, लेकिन आपको लिखने के तरीके की जानकारी है नए Android डिवाइस लाते समय, अब नीति के नियम ज़रूरी हो गए हैं. कई SELinux के संबंध में पहले से ही बहुत सारी जानकारी उपलब्ध है. सहायता टीम से मदद लें दस्तावेज़ पढ़ें.

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

SELinux को चालू करने के लिए, नया Android कर्नेल पर क्लिक करें और फिर इसमें मिली फ़ाइलों को शामिल करें सिस्टम/से-नीति डायरेक्ट्री. कंपाइल किए जाने पर, उन फ़ाइलों में SELinux कर्नेल सुरक्षा अपस्ट्रीम Android ऑपरेटिंग सिस्टम की नीति और शर्तों को पूरा करती है.

आम तौर पर, आपको system/sepolicy फ़ाइलों में बदलाव नहीं करना चाहिए सकता है. इसके बजाय, डिवाइस के हिसाब से बनी नीति की फ़ाइलें यहां जोड़ें या उनमें बदलाव करें /device/manufacturer/device-name/sepolicy अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है डायरेक्ट्री. Android 8.0 और उसके बाद के वर्शन में, इन फ़ाइलों में किए जाने वाले बदलाव का असर सिर्फ़ आपकी वेंडर डायरेक्ट्री में मौजूद नीति पर पड़ेगा. अलग-अलग प्लैटफ़ॉर्म पर Android 8.0 और इसके बाद के वर्शन में सार्वजनिक सेवा से जुड़ी नीति के बारे में जानने के लिए, Android में SEPolicy को पसंद के मुताबिक बनाना 8.0 के बाद के वर्शन. 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 डायरेक्ट्री. इस कॉन्फ़िगरेशन को हर ऐप्लिकेशन के लॉन्च पर और installd तक zygote प्रोसेस को ट्रैक करने की सुविधा मिलती है.
• mac_permissions.xml, ऐप्लिकेशन को seinfo टैग असाइन करता है उनके हस्ताक्षर और वैकल्पिक रूप से उनके पैकेज नाम पर आधारित होता है. कॉन्टेंट बनाने इसके बाद, seinfo टैग को उन सभी ऐप्लिकेशन को कोई खास लेबल असाइन करने के लिए seapp_contexts फ़ाइल जिनमें वह seinfo टैग. इस कॉन्फ़िगरेशन को स्टार्टअप के दौरान system_server.
• keystore2_key_contexts, कीस्टोर 2.0 नेमस्पेस को लेबल असाइन करता है. ये नेमस्पेस, कीस्टोर2 डीमन से लागू किए जाते हैं. कीस्टोर में हमेशा यूआईडी/एआईडी पर आधारित नेमस्पेस दिए गए हैं. कीस्टोर 2.0, सुरक्षा नीति को अतिरिक्त रूप से लागू करता है परिभाषित नाम-स्थान. इस कैंपेन के फ़ॉर्मैट और तौर-तरीकों के बारे में पूरी जानकारी फ़ाइल यहां उपलब्ध है.

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 के अपडेट होने के बाद, नीति की सेटिंग, कर्नेल नीति की फ़ाइनल फ़ाइल में अपने-आप बन जाती हैं. डिवाइस पर सुरक्षा नीति कैसे बनाई जाती है, इस बारे में ज़्यादा जानने के लिए देखें नीति बनाना.

लागू करना

SELinux के साथ शुरू करने के लिए:

1. कर्नेल में SELinux को सक्षम करें: CONFIG_SECURITY_SELINUX=y अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
2. kernel_cmdline या loadconfig पैरामीटर को बदलें, ताकि:

   BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive

   अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है या

   BOARD_BOOTCONFIG := androidboot.selinux=permissive

   यह सिर्फ़ डिवाइस के लिए नीति बनाने के शुरुआती समय में होता है. आपके बाद शुरुआती बूटस्ट्रैप नीति है, तो इस पैरामीटर को हटा दें, ताकि आपके डिवाइस लागू हो रहा है या सीटीएस लागू नहीं हो पाएगा.
3. अनुमति देकर, सिस्टम को चालू करें. साथ ही, देखें कि चालू करने पर सिस्टम को किन समस्याओं का सामना करना पड़ता है:
   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
   

4. आउटपुट जैसी चेतावनियों के लिए, आउटपुट का आकलन करें init: Warning! Service name needs a SELinux domain defined; please fix! देखें निर्देशों के लिए पुष्टि और टूल शामिल हैं.
5. उन डिवाइसों और अन्य नई फ़ाइलों की पहचान करें जिन्हें लेबल करने की ज़रूरत है.
6. अपने ऑब्जेक्ट के लिए मौजूदा या नए लेबल का इस्तेमाल करें. देखें, चीज़ों को पहले कैसे लेबल किया गया था, यह देखने के लिए *_contexts फ़ाइलें और नया लेबल असाइन करने के लिए, लेबल के मतलब की जानकारी का इस्तेमाल करें. आम तौर पर, यह पहले से मौजूद लेबल होगा, जो नीति के मुताबिक होगा. हालांकि, कभी-कभी एक नए लेबल की ज़रूरत होगी और उस लेबल को ऐक्सेस करने के नियम की ज़रूरत नहीं है. सही संदर्भ फ़ाइलों में अपने लेबल जोड़ें.
7. ऐसे डोमेन या प्रोसेस की पहचान करें जिनके अपने सुरक्षा डोमेन होने चाहिए. आपको हर एक के लिए पूरी तरह से नई नीति लिखनी होगी. सभी उदाहरण के लिए, init से जनरेट की गई सेवाओं में मालिकाना हक है. नीचे दिए गए निर्देशों से उन लोगों का पता लगाने में मदद मिलती है जो चलते रहते हैं (लेकिन सभी सेवाओं के लिए इस तरह के इलाज की ज़रूरत है):
   

   adb shell su -c ps -Z | grep init
   

   adb shell su -c dmesg | grep 'avc: '
   

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