SELinux नीति लिखना

Android ओपन सोर्स प्रोजेक्ट (AOSP) ऐसे ऐप्लिकेशन और सेवाएं जो सभी Android डिवाइसों पर आम तौर पर इस्तेमाल होती हैं. एओएसपी में योगदान देने वाले लोग, इस नीति को नियमित तौर पर बेहतर बनाते हैं. मुख्य नीति से उपयोगकर्ता, डिवाइस से जुड़ी नीति का 90 से 95% तक इस्तेमाल कर सकता है. बाकी 5–10% हिस्से को ज़रूरत के हिसाब से बनाया जा सकता है. इस लेख में, मुख्य रूप से डिवाइस-विशिष्ट कस्टमाइज़ेशन, डिवाइस-विशिष्ट नीति लिखने का तरीका, और रास्ते में होने वाली कुछ गलतियों से बचने की ज़रूरत है.

डिवाइस को लाना

डिवाइस के लिए खास नीति लिखते समय, यहां दिया गया तरीका अपनाएं.

अनुमति देने वाले मोड में चलाएं

जब कोई डिवाइस अनुमति मोड, अस्वीकार की गई जानकारी लॉग की जाती है, लेकिन लागू नहीं की जाती. अनुमति देने वाला मोड, दो लोगों के लिए ज़रूरी है वजहें:

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

डिवाइस को अनुमति देने वाले मोड में रखने का सबसे आसान तरीका है, kernel कमांड लाइन में दिखाया जाता है. इसे डिवाइस की 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 में मौजूद सब कुछ “ डिवाइस” लेबल में तब तक शामिल करें, जब तक कि कोई ज़्यादा खास लेबल असाइन न किया गया हो. बस स्वीकार किया जा रहा है से मिला आउटपुट audit2allow तो इसका नतीजा गलत और बहुत ज़्यादा अनुमति देने वाला नियम हो सकता है.

इस तरह की समस्या को हल करने के लिए, फ़ाइल को एक खास लेबल दें. यह मामला है gpu_device. किसी और अनुमति की ज़रूरत नहीं है, क्योंकि मीडिया सर्वर के पास मुख्य नीति में पहले से ही ज़रूरी अनुमतियां हैं, ताकि gpu_device.

डिवाइस के हिसाब से बनी अन्य फ़ाइलें, जिन्हें पहले से तय किए गए टाइप के साथ लेबल किया जाना चाहिए मुख्य नीति:

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

आम तौर पर, डिफ़ॉल्ट लेबल के लिए अनुमतियां देना गलत होता है. इनमें से कई अनुमतियों की अनुमति इनके पास नहीं है कभी भी अनुमति न दें, लेकिन भले ही साफ़ तौर पर इसकी अनुमति न हो, लेकिन सबसे सही तरीका यह है कि आप लेबल.

नई सेवाओं और पते को लेबल करें नामंज़ूरियां

इनिट-लॉन्च की गई सेवाओं को उनके अपने SELinux डोमेन पर चलाना ज़रूरी है. कॉन्टेंट बनाने नीचे दिए गए उदाहरण में, “foo” सेवा को उसके अपने SELinux डोमेन में रखा गया है और इसे अनुमतियां दी हैं.

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

service foo /system/bin/foo
    class core

1. नया डोमेन "foo" बनाएं
   

   फ़ाइल बनाएं device/manufacturer/device-name/sepolicy/foo.te अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इसमें ये शामिल हैं:

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

   यह 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 नियमों को बेहतर बनाएं.
   

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

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

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

आम तौर पर होने वाली गलतियां

लिखते समय होने वाली आम गलतियों के कुछ समाधान यहां दिए गए हैं खास तौर पर किसी डिवाइस से जुड़ी नीतियां.

नेगेटिव कॉन्टेंट का ज़रूरत से ज़्यादा इस्तेमाल करना

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

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.

एक और सुरक्षित विकल्प यह है कि userडीबग_or_eng स्टेटमेंट.

पॉलिसी साइज़ एक्सप्लोज़न

SEAndroid की अलग-अलग नीतियों के बारे में बताना यह डिवाइस नीति को पसंद के मुताबिक बनाने की सुविधा में हो रहे बदलाव के बारे में बताता है. डिवाइस से जुड़ी नीति, जिस पर चल रही नीति का 5–10% हिस्सा होनी चाहिए डिवाइस. 20%+ रेंज में मौजूद कस्टमाइज़ेशन में खास अधिकार वाले डोमेन और बंद नीति.

ग़ैर-ज़रूरी तौर पर बड़ी नीति:

• जब नीति रैम डिस्क में सेव हो जाती है, तो मेमोरी को दो बार नुकसान पहुंचता है कर्नेल मेमोरी में भी लोड किया जाता है.
• बड़ी बूटइमेज की ज़रूरत के हिसाब से डिस्क की जगह बर्बाद होती है.
• रनटाइम नीति के लुकअप समय पर असर पड़ता है.

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

पहली इमेज. डिवाइस के हिसाब से तुलना सुरक्षा ऑडिट के बाद नीति का साइज़.

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

dac_override की सुविधा देना

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