SELinux नीति लिखना

एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) उन अनुप्रयोगों और सेवाओं के लिए एक ठोस आधार नीति प्रदान करता है जो सभी एंड्रॉइड डिवाइसों में आम हैं। एओएसपी के योगदानकर्ता इस नीति को नियमित रूप से परिशोधित करते हैं। मुख्य नीति से अंतिम ऑन-डिवाइस नीति का लगभग 90-95% होने की उम्मीद है, जिसमें डिवाइस-विशिष्ट अनुकूलन शेष 5-10% हैं। यह लेख इन डिवाइस-विशिष्ट अनुकूलन पर केंद्रित है, डिवाइस-विशिष्ट नीति कैसे लिखें, और रास्ते में बचने के लिए कुछ नुकसान।

डिवाइस लाना

डिवाइस-विशिष्ट नीति लिखते समय, इन चरणों का पालन करें।

अनुमेय मोड में चलाएँ

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

• अनुमेय मोड यह सुनिश्चित करता है कि पॉलिसी लाने से अन्य शुरुआती डिवाइस लाने में देरी नहीं होती है।
• एक लागू इनकार अन्य इनकारों को मुखौटा कर सकता है। उदाहरण के लिए, फ़ाइल एक्सेस में आमतौर पर एक निर्देशिका खोज, फ़ाइल खोलना, फिर फ़ाइल पढ़ना शामिल है। प्रवर्तन मोड में, केवल निर्देशिका खोज इनकार होगा। अनुमेय मोड सुनिश्चित करता है कि सभी इनकार देखे जा सकते हैं।

डिवाइस को अनुमेय मोड में डालने का सबसे सरल तरीका कर्नेल कमांड लाइन का उपयोग करना है। इसे डिवाइस की BoardConfig.mk फ़ाइल में जोड़ा जा सकता है: platform/device/<vendor>/<target>/BoardConfig.mk । कमांड लाइन को संशोधित करने के बाद, make clean करें, फिर बूट इमेज make bootimage , और नई बूट इमेज को फ्लैश करें।

उसके बाद, अनुमेय मोड की पुष्टि करें:

adb shell getenforce

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

जल्दी लागू करें

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

मौजूदा नीति हटाएं या हटाएं

नए डिवाइस पर शुरू से ही डिवाइस-विशिष्ट नीति बनाने के कई अच्छे कारण हैं, जिनमें शामिल हैं:

• सुरक्षा लेखा परीक्षा
• अत्यधिक अनुमेय नीति
• नीति आकार में कमी
• मृत नीति

मुख्य सेवाओं के पते से इनकार

मुख्य सेवाओं द्वारा उत्पन्न डेनियल को आमतौर पर फ़ाइल लेबलिंग द्वारा संबोधित किया जाता है। उदाहरण के लिए:

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

/dev/kgsl-3d0 को ठीक से लेबल करके पूरी तरह से संबोधित किया जाता है। इस उदाहरण में, tcontext device । यह एक डिफ़ॉल्ट संदर्भ का प्रतिनिधित्व करता है जहां /dev में सब कुछ " डिवाइस " लेबल प्राप्त करता है जब तक कि कोई अधिक विशिष्ट लेबल असाइन नहीं किया जाता है। यहां केवल ऑडिट2 अनुमति के आउटपुट को स्वीकार करने से एक गलत और अत्यधिक अनुमेय नियम बन जाएगा।

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

अन्य उपकरण-विशिष्ट फ़ाइलें जिन्हें मूल नीति में पूर्वनिर्धारित प्रकारों के साथ लेबल किया जाना चाहिए:

• ब्लॉक डिवाइस
• ऑडियो डिवाइस
• वीडियो उपकरण
• सेंसर
• एनएफसी
• जीपीएस_डिवाइस
• /sys . में फ़ाइलें
• /proc . में फ़ाइलें

सामान्य तौर पर, डिफ़ॉल्ट लेबल को अनुमति देना गलत है। इन अनुमतियों में से कई को कभी भी अनुमति न देने वाले नियमों द्वारा अस्वीकृत कर दिया जाता है, लेकिन स्पष्ट रूप से अस्वीकृत न होने पर भी, एक विशिष्ट लेबल प्रदान करना सबसे अच्छा अभ्यास है।

नई सेवाओं को लेबल करें और इनकार को संबोधित करें

इनिट-लॉन्च की गई सेवाओं को अपने स्वयं के SELinux डोमेन में चलाने की आवश्यकता होती है। निम्न उदाहरण सेवा "foo" को अपने SELinux डोमेन में डालता है और इसे अनुमति देता है।

सेवा हमारे डिवाइस के init. device .rc फ़ाइल के रूप में:

service foo /system/bin/foo
    class core

1. एक नया डोमेन "फू" बनाएं
   

   निम्नलिखित सामग्री के साथ फ़ाइल device/ manufacturer / device-name /sepolicy/foo.te :

   # foo service
   type foo, domain;
   type foo_exec, exec_type, file_type;
   
   init_daemon_domain(foo)
   

   यह फू SELinux डोमेन के लिए प्रारंभिक टेम्पलेट है, जिसमें आप उस निष्पादन योग्य द्वारा निष्पादित विशिष्ट संचालन के आधार पर नियम जोड़ सकते हैं।

2. लेबल /system/bin/foo
   

   device/ manufacturer / device-name /sepolicy/file_contexts में निम्नलिखित जोड़ें:

   /system/bin/foo   u:object_r:foo_exec:s0
   

   यह सुनिश्चित करता है कि निष्पादन योग्य ठीक से लेबल किया गया है इसलिए SELinux उचित डोमेन में सेवा चलाता है।

3. बूट और सिस्टम इमेज बनाएं और फ्लैश करें।
4. डोमेन के लिए SELinux नियमों को परिशोधित करें।
   

   आवश्यक अनुमतियों को निर्धारित करने के लिए इनकार का उपयोग करें। ऑडिट 2अनुमति उपकरण अच्छे दिशानिर्देश प्रदान करता है, लेकिन इसका उपयोग केवल नीति लेखन को सूचित करने के लिए करें। केवल आउटपुट कॉपी न करें।

वापस लागू करने के मोड पर स्विच करें

अनुमेय मोड में समस्या निवारण करना ठीक है, लेकिन जितनी जल्दी हो सके लागू करने के मोड पर वापस जाएं और वहां बने रहने का प्रयास करें।

साधारण गलती

डिवाइस-विशिष्ट नीतियां लिखते समय होने वाली सामान्य गलतियों के लिए यहां कुछ समाधान दिए गए हैं।

निषेध का अति प्रयोग

निम्नलिखित उदाहरण नियम सामने के दरवाजे को बंद करने लेकिन खिड़कियों को खुला छोड़ने जैसा है:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

इरादा स्पष्ट है: तीसरे पक्ष के ऐप्स को छोड़कर सभी के पास डीबग डिवाइस तक पहुंच हो सकती है।

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

उत्पादन में डिबगिंग सुविधाएँ

डिबग फ़ीचर प्रोडक्शन बिल्ड पर मौजूद नहीं होने चाहिए और न ही उनकी नीति होनी चाहिए।

सबसे आसान विकल्प केवल डिबग सुविधा को अनुमति देना है जब SELinux को eng/userdebug बिल्ड पर अक्षम किया जाता है, जैसे adb root और adb shell setenforce 0 ।

एक अन्य सुरक्षित विकल्प एक userdebug_or_eng कथन में डिबग अनुमतियों को संलग्न करना है।

नीति आकार विस्फोट

जंगली में SEAndroid नीतियों की विशेषता डिवाइस नीति अनुकूलन के विकास में एक संबंधित प्रवृत्ति का वर्णन करती है। डिवाइस-विशिष्ट नीति को डिवाइस पर चलने वाली समग्र नीति का 5-10% हिस्सा होना चाहिए। 20%+ रेंज में अनुकूलन में लगभग निश्चित रूप से विशेषाधिकार प्राप्त डोमेन और मृत नीति शामिल हैं।

अनावश्यक रूप से बड़ी नीति:

• मेमोरी पर डबल हिट लेता है क्योंकि पॉलिसी रैमडिस्क में बैठती है और इसे कर्नेल मेमोरी में भी लोड किया जाता है।
• एक बड़े बूट इमेज की आवश्यकता के कारण डिस्क स्थान बर्बाद करता है।
• रनटाइम नीति लुकअप समय को प्रभावित करता है।

निम्न उदाहरण दो डिवाइस दिखाता है जहां निर्माता-विशिष्ट नीति में डिवाइस पर नीति का 50% और 40% शामिल था। जैसा कि नीचे दिखाया गया है, नीति के पुनर्लेखन से कार्यक्षमता में बिना किसी हानि के पर्याप्त सुरक्षा सुधार प्राप्त हुए हैं। (एओएसपी डिवाइस शामू और फ्लाउंडर तुलना के लिए शामिल हैं।)

चित्र 1 . सुरक्षा ऑडिट के बाद डिवाइस-विशिष्ट नीति आकार की तुलना।

दोनों ही मामलों में, नीति को आकार और अनुमतियों की संख्या दोनों में नाटकीय रूप से कम किया गया था। नीति के आकार में कमी लगभग पूरी तरह से अनावश्यक अनुमतियों को हटाने के कारण है, जिनमें से कई audit2allow अनुमति द्वारा उत्पन्न संभावित नियम थे जिन्हें नीति में अंधाधुंध जोड़ा गया था। दोनों डिवाइस के लिए डेड डोमेन भी एक समस्या थी।

dac_override क्षमता प्रदान करना

एक dac_override इनकार का अर्थ है कि आपत्तिजनक प्रक्रिया गलत यूनिक्स उपयोगकर्ता/समूह/विश्व अनुमतियों वाली फ़ाइल तक पहुँचने का प्रयास कर रही है। dac_override अनुमति देना लगभग कभी भी उचित समाधान नहीं है। इसके बजाय फ़ाइल या प्रक्रिया पर यूनिक्स अनुमतियों को बदलें । कुछ डोमेन जैसे कि init , vold , और installd को वास्तव में अन्य प्रक्रियाओं की फ़ाइलों तक पहुँचने के लिए यूनिक्स फ़ाइल अनुमतियों को ओवरराइड करने की क्षमता की आवश्यकता होती है। अधिक गहराई से स्पष्टीकरण के लिए डैन वॉल्श का ब्लॉग देखें।