Android, OEM को SELinux लागू करने के तरीकों की जांच करने के लिए बढ़ावा देता है अच्छी तरह से पढ़ें. जैसे-जैसे मैन्युफ़ैक्चरर SELinux को लागू करते हैं, उन्हें अपनी साइट पर टेस्ट पूल में जोड़ दी जाती हैं.
नई नीति लागू करने के बाद, पक्का करें कि SELinux सही से चल रहा है
getenforce
आदेश जारी करके डिवाइस पर मोड चालू करें.
यह वैश्विक SELinux मोड को प्रिंट करता है: या तो एनफ़ोर्स करना या अनुमति देने वाला. यहां की यात्रा पर हूं
तो आपको हर डोमेन के लिए SELinux मोड का पता लगाना होगा
फ़ाइलें डाउनलोड करें या sepolicy-analyze
के सबसे नए वर्शन को
सही (-p
) फ़्लैग, इसमें मौजूद है
/platform/system/sepolicy/tools/
.
रीडिंग डिनायल
उन गड़बड़ियों की जांच करें जिन्हें इवेंट लॉग के तौर पर dmesg
पर भेजा जाता है
और logcat
को डिवाइस पर देखा जा सकता है. निर्माता
को इन डिवाइसों पर, dmesg
के लिए SELinux आउटपुट की जाँच करनी चाहिए और
अनुमति देने वाले मोड और आखिर में स्विच करने वाले मोड में, सार्वजनिक तौर पर रिलीज़ करने से पहले सेटिंग को बेहतर बना देता है
लागू करने वाले मोड तक. SELinux लॉग मैसेज में avc:
है और इसलिए हो सकता है
grep
की मदद से इसे आसानी से खोजा जा सकता है. मौजूदा स्थिति को कैप्चर करना मुमकिन है
cat /proc/kmsg
चलाकर या अस्वीकार किए गए लॉग कैप्चर करने के लिए, अस्वीकार किए गए लॉग
पिछले बूट से
cat /sys/fs/pstore/console-ramoops
.
स्वैपिंग से बचने के लिए, बूट पूरा होने के बाद SELinux गड़बड़ी के मैसेज रेट-सीमित होते हैं
लॉग. अगर आप चाहते हैं कि आपको सभी काम के मैसेज दिखें, तो इस सुविधा को बंद करें
adb shell auditctl -r 0
चलाकर देखें.
इस आउटपुट की मदद से, मैन्युफ़ैक्चरर यह आसानी से पहचान सकते हैं कि सिस्टम के उपयोगकर्ता या घटक SELinux नीति का उल्लंघन कर रहे हैं. इसके बाद, मैन्युफ़ैक्चरर सॉफ़्टवेयर, SELinux नीति में बदलाव या दोनों में बदलाव करने से.
खास तौर पर, ये लॉग मैसेज बताते हैं कि कौनसी प्रोसेस पूरी नहीं होंगी लागू करने वाला मोड और क्यों लागू करें. उदाहरण के लिए:
avc: denied { connectto } for pid=2671 comm="ping" path="/dev/socket/dnsproxyd" scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket
इस आउटपुट को कुछ इस तरह समझें:
- ऊपर दिए गए
{ connectto }
में, की जा रही कार्रवाई के बारे में बताया गया है. एक साथ आख़िर मेंtclass
(unix_stream_socket
), यह आपको बताता है कि YouTube पर किस तक. इस मामले में, किसी यूनिक्स स्ट्रीम सॉकेट से कनेक्ट करने की कोशिश की जा रही थी. -
scontext (u:r:shell:s0)
से आपको पता चलता है कि किस संदर्भ ने कार्रवाई शुरू की. तय सीमा में यह कुछ ऐसा है जो शेल की तरह चल रहा है. -
tcontext (u:r:netd:s0)
आपको कार्रवाई के टारगेट का संदर्भ बताता है. तय सीमा में इस मामले में, यह एक Unix_stream_socket है, जिसका मालिकाना हकnetd
के पास है. - सबसे ऊपर मौजूद
comm="ping"
से यह पता चलता है कि आगे क्या था को अस्वीकार किए जाने के समय लागू किया जाएगा. इस मामले में, यह काफ़ी अच्छा संकेत है.
एक और उदाहरण:
adb shell su root dmesg | grep 'avc: '
आउटपुट:
<5> type=1400 audit: avc: denied { read write } for pid=177 comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0 tcontext=u:object_r:kmem_device:s0 tclass=chr_file
इस डिनायल की मुख्य बातें यहां दी गई हैं:
- कार्रवाई - आपने जिस कार्रवाई को करने की कोशिश की है उसे ब्रैकेट में हाइलाइट किया गया है,
read write
याsetenforce
. - ऐक्टर -
scontext
(सोर्स कॉन्टेक्स्ट) एंट्री से पता चलता है कि का मतलब है. इस मामले मेंrmt_storage
डीमन है. - ऑब्जेक्ट -
tcontext
(टारगेट कॉन्टेक्स्ट) एंट्री दिखाती है वह ऑब्जेक्ट जिस पर कार्रवाई की जा रही है, इस मामले में kmem. - नतीजे -
tclass
(टारगेट क्लास) एंट्री, टाइप दिखाती है ऑब्जेक्ट पर कार्रवाई की जा रही है, इस मामले में एकchr_file
(वर्ण डिवाइस).
उपयोगकर्ता और कर्नेल स्टैक डंप करना
कुछ मामलों में, इवेंट लॉग में शामिल जानकारी यह पता लगाने के लिए काफ़ी नहीं है कि अस्वीकार किए जाने की वजह. कॉल चेन को इकट्ठा करना अक्सर फ़ायदेमंद होता है, जिसमें कर्नेल और अस्वीकार किए जाने की वजह को बेहतर ढंग से समझने के लिए, उपयोगकर्तास्पेस का इस्तेमाल करें.
हाल ही के कर्नेल, avc:selinux_audited
नाम का ट्रेसपॉइंट तय करते हैं. Android का इस्तेमाल करें
इस ट्रेसपॉइंट को चालू करने और कॉलचेन को कैप्चर करने के लिए, simpleperf
.
इस्तेमाल किया जा सकने वाला कॉन्फ़िगरेशन
- Linux कर्नेल >= 5.10, खास तौर पर Android Common Kernel ब्रांच
मेनलाइन
और
Android12-5.10
समर्थित हैं.
Android12-5.4
ब्रांच से भी मदद मिल सकती है.
simpleperf
का इस्तेमाल करके, यह पता लगाया जा सकता है कि ट्रेसपॉइंट सही है या नहीं आपके डिवाइस पर परिभाषित:adb root && adb shell simpleperf list | grep avc:selinux_audited
. अन्य kernel वर्शन के लिए, आप चुन सकते हैं dd81662 और 30969bc. - इस सुविधा से उस इवेंट को फिर से देखा जा सकता है जिसे डीबग किया जा रहा है. बूट टाइम इवेंट नहीं हैं Simpleperf का इस्तेमाल करके काम करता है; हालांकि, आपके पास अब भी अपनी वेबसाइट पर काम करने के लिए, इवेंट.
कॉल चेन कैप्चर की जा रही है
सबसे पहले, simpleperf record
का इस्तेमाल करके इवेंट को रिकॉर्ड करें:
adb shell -t "cd /data/local/tmp && su root simpleperf record -a -g -e avc:selinux_audited"
इसके बाद, वह इवेंट ट्रिगर होगा जिसकी वजह से अनुरोध अस्वीकार किया गया था. इसके बाद, रिकॉर्डिंग को
उन्हें रोका नहीं जाएगा. इस उदाहरण में, Ctrl-c
का इस्तेमाल करके, सैंपल कैप्चर किया जाना चाहिए था:
^Csimpleperf I cmd_record.cpp:751] Samples recorded: 1. Samples lost: 0.
आखिर में, कैप्चर किए गए स्टैकट्रेस की जांच करने के लिए, simpleperf report
का इस्तेमाल किया जा सकता है.
उदाहरण के लिए:
adb shell -t "cd /data/local/tmp && su root simpleperf report -g --full-callgraph" [...] Children Self Command Pid Tid Shared Object Symbol 100.00% 0.00% dmesg 3318 3318 /apex/com.android.runtime/lib64/bionic/libc.so __libc_init | -- __libc_init | -- main toybox_main toy_exec_which dmesg_main klogctl entry_SYSCALL_64_after_hwframe do_syscall_64 __x64_sys_syslog do_syslog selinux_syslog slow_avc_audit common_lsm_audit avc_audit_post_callback avc_audit_post_callback
ऊपर दी गई कॉल चेन, एक यूनिफ़ाइड कर्नेल और यूज़रस्पेस कॉल चेन है. इससे आपको बेहतर तरीके से
यूज़रस्पेस से लेकर कर्नेल तक ट्रेस शुरू करके कोड फ़्लो का व्यू
अस्वीकार किया जाता है. simpleperf
के बारे में ज़्यादा जानकारी के लिए, इसे देखें
Simpleperf एक्ज़ीक्यूटेबल निर्देशों के बारे में जानकारी
अनुमति वाली सुविधा पर स्विच किया जा रहा है
userdebug या eng बिल्ड पर ADB की मदद से, SELinux लागू करने की सुविधा को बंद किया जा सकता है. ऐसा करने के लिए,
पहले adb root
को चलाकर ADB को रूट पर ले जाएं. इसके बाद, SELinux को बंद करने के लिए
नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) को लागू करने के लिए, चलाएं:
adb shell setenforce 0
या कर्नेल कमांड लाइन पर (डिवाइस के शुरुआती दौर में):
androidboot.selinux=permissive
androidboot.selinux=enforcing
इसके अलावा, Android 12 में बूट कॉन्फ़िगरेशन की मदद से ऐसा किया जा सकता है:
androidboot.selinux=permissive
androidboot.selinux=enforcing
ऑडिट2allow का इस्तेमाल किया जा रहा है
audit2allow
टूल, अनुरोध को अस्वीकार किए जाने की dmesg
वजह और
उन्हें संबंधित SELinux नीति स्टेटमेंट में बदल देता है. इसलिए, यह काम कर सकता है
SELinux डेवलपमेंट को तेज़ी से पूरा करता है.
इसका इस्तेमाल करने के लिए, चलाएँ:
adb pull /sys/fs/selinux/policy
adb logcat -b events -d | audit2allow -p policy
फिर भी, इस बात का ध्यान रखना चाहिए कि
उसे ऐक्सेस करने की अनुमति नहीं है. उदाहरण के लिए, audit2allow
को फ़ीड करना
rmt_storage
अस्वीकार करने की वजह से, पहले के नतीजे इस तरह दिखाए गए
सुझाया गया SELinux नीति स्टेटमेंट:
#============= shell ============== allow shell kernel:security setenforce; #============= rmt ============== allow rmt kmem_device:chr_file { read write };
इससे rmt
को कर्नेल मेमोरी लिखने की सुविधा मिल जाएगी,
चमकता हुआ सुरक्षा होल. अक्सर audit2allow
स्टेटमेंट सिर्फ़
प्रारंभ बिंदु. इन स्टेटमेंट को लागू करने के बाद, आपको
सोर्स डोमेन और टारगेट के लेबल के साथ-साथ,
मैक्रो, ताकि आप एक अच्छी नीति तैयार कर सकें. कभी-कभी जिस डिनायल की जांच की जा रही है उसे
नीति में किसी तरह का बदलाव नहीं होगा; बल्कि आपत्तिजनक ऐप्लिकेशन का इस्तेमाल करते हैं.
बदला जाना चाहिए.