एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। मूल उपयोगकर्ता स्थान, भाग 2

प्रविष्टि

आज मैं कोर से थोड़ा ऊपर के स्तर पर सुरक्षा पर विचार करना जारी रखूंगा। दूसरे भाग में, हम देखेंगे कि कहां से। system.img, userdata.img, और cache.img आते हैं, साथ ही मूल उपयोगकर्ता स्थान में सुरक्षा कैसे प्रदान की जाती है।
हर कोई जो दिलचस्पी है, स्वागत है!

लेखों की सूची

इस विषय से मेरे लेखों के लिंक यहां दिए गए हैं:

1. एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। कोर स्तर
2. एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। मूल उपयोगकर्ता स्थान, भाग 1
3. एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। मूल उपयोगकर्ता स्थान, भाग 2
4. एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा मूल बातें। अनुप्रयोग फ्रेमवर्क स्तर पर सुरक्षा। बाइंडर आई.पी.सी.

देशी उपयोगकर्ता अंतरिक्ष से क्या मतलब है

मूल उपयोगकर्ता स्थान उन सभी उपयोगकर्ता-अंतरिक्ष घटकों को संदर्भित करता है जो Dalvik वर्चुअल मशीन के बाहर चलते हैं और जो लिनक्स कर्नेल का हिस्सा नहीं हैं। मूल उपयोगकर्ता स्थान निष्पादन योग्य फाइलें हैं जो एक विशिष्ट वास्तुकला के लिए संकलित हैं। इनमें निष्पादन योग्य फाइलें शामिल हैं जो कि init स्क्रिप्ट से स्वचालित रूप से या किसी ईवेंट, टूलबॉक्स उपयोगिताओं, साथ ही कुछ निष्पादन योग्य फ़ाइलों को लॉन्च करती हैं, जो उपयोगकर्ता शेल के नीचे से चला सकते हैं।

शुरुआत

जैसा कि मैंने पहले भाग में कहा, एंड्रॉइड लिनक्स कर्नेल पर आधारित है। सभी लिनक्स प्रणालियों के साथ, Android की सुरक्षा अभिगम नियंत्रण पर आधारित है। यानी प्रत्येक संसाधन (उदाहरण के लिए, एक फ़ाइल) में मेटा-जानकारी होती है कि किसने इस फ़ाइल को बनाया है - स्वामी (स्वामी) - और कौन सा मुख्य समूह (स्वामी समूह) स्वामी (स्वामी) का है। प्रत्येक प्रक्रिया कुछ उपयोगकर्ता (उपयोगकर्ता) की ओर से शुरू की जाती है। प्रत्येक उपयोगकर्ता का एक मुख्य समूह होता है। इसके अलावा, वह अन्य समूहों का सदस्य हो सकता है। इस प्रकार, यदि आप प्रत्येक संसाधन (rwxrwxrwx प्रारूप में) के बारे में जानकारी संलग्न करते हैं जो संसाधन को पढ़ / लिख / निष्पादित कर सकते हैं (उदाहरण के लिए, एक फ़ाइल), तो आप इस फ़ाइल तक पहुँच को नियंत्रित कर सकते हैं। उदाहरण के लिए, आप किसी फ़ाइल को अनुमति दे सकते हैं: इस फ़ाइल का स्वामी (स्वामी) इस फ़ाइल के साथ क्या कर सकता है; जो उपयोगकर्ता स्वामी समूह का हिस्सा हैं वे क्या कर सकते हैं; बाकी सब क्या कर सकते हैं। यहाँ आप इस बारे में अधिक पढ़ सकते हैं।

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

जैसा कि मैंने पहले ही नोट किया है, यह प्रक्रिया उसी उपयोगकर्ता (यूआईडी) की ओर से शुरू होती है जो इस नई प्रक्रिया को शुरू करने वाली प्रक्रिया के रूप में होती है, अर्थात्। यूआईडी (कॉलिंग_प्रोसेस) == यूआईडी (जिसे_प्रोसेस) कहा जाता है। पहली प्रक्रिया जो Android पर चलती है - init - root (UID == 0) के रूप में चलती है। इस प्रकार, सिद्धांत रूप में, सभी प्रक्रियाएं समान उपयोगकर्ताओं की ओर से भी शुरू की जानी चाहिए। तो यह शायद होता। लेकिन, सबसे पहले, एक विशेषाधिकार प्राप्त उपयोगकर्ता (साथ ही कुछ क्षमताओं वाले लोग) की ओर से चलने वाली प्रक्रियाएं उनके यूआईडी को कम विशेषाधिकार प्राप्त व्यक्ति में बदल सकती हैं। और दूसरी बात, एंड्रॉइड में, जब एक init.rc स्क्रिप्ट में डेमन लॉन्च करते हैं, तो आप यह भी निर्दिष्ट कर सकते हैं कि इस प्रक्रिया को शुरू करने के लिए कौन से उपयोगकर्ता और किन समूहों के विशेषाधिकार हैं।

... service console /system/bin/sh class core console disabled user shell group log ... service servicemanager /system/bin/servicemanager class core user system group system critical onrestart restart zygote onrestart restart media onrestart restart surfaceflinger onrestart restart drm ... service media /system/bin/mediaserver class main user media group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc ioprio rt 4 ... 

इन डेमों के माध्यम से लॉन्च की जाने वाली सभी प्रक्रियाओं में अब रूट विशेषाधिकार नहीं होंगे।

सिस्टम, डेटा और कैश

मैंने कई बार इस विषय की घोषणा की है कि कोई यह सोचेगा कि यह बहुत जटिल और भ्रमित करने वाला है। वास्तव में, ऐसा नहीं है। System.img , userdata.img और cache.img Android ऑपरेटिंग सिस्टम को संकलित करने के परिणाम हैं। यही है, सिस्टम को इकट्ठा करने के परिणामस्वरूप, ये तीन फाइलें प्राप्त की जाती हैं, जिसे हम अपने डिवाइस पर लिखते हैं।

लेकिन सबसे महत्वपूर्ण बात यह नहीं है। इस तथ्य के कारण कि एंड्रॉइड सिस्टम में उपयोगकर्ता नाम और सिस्टम उपयोगकर्ताओं का यूआईडी हार्ड-कोडेड है, पहले से ही संकलन चरण में हम इन छवियों में विभिन्न निर्देशिकाओं के लिए विभिन्न सिस्टम उपयोगकर्ताओं के एक्सेस अधिकारों को निर्धारित कर सकते हैं। ये अनुमतियाँ सिस्टम / कोर / निर्दिष्ट / निजी / android_filesystem_config.h फ़ाइल में निर्दिष्ट हैं, जिसे हमने पहले लेख में कवर किया है। एक्सेस राइट्स को डायरेक्ट्री (android_dirs []] के लिए अलग से और फाइलों के लिए अलग से परिभाषित किया गया है (android_files []) इस प्रकार है:

 ... struct fs_path_config { unsigned mode; unsigned uid; unsigned gid; uint64_t capabilities; const char *prefix; }; /* Rules for directories. ** These rules are applied based on "first match", so they ** should start with the most specific path and work their ** way up to the root. */ static const struct fs_path_config android_dirs[] = { { 00770, AID_SYSTEM, AID_CACHE, 0, "cache" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/dalvik-cache" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/data" }, { 00771, AID_SHELL, AID_SHELL, 0, "data/local/tmp" }, { 00771, AID_SHELL, AID_SHELL, 0, "data/local" }, { 01771, AID_SYSTEM, AID_MISC, 0, "data/misc" }, { 00770, AID_DHCP, AID_DHCP, 0, "data/misc/dhcp" }, { 00775, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media" }, { 00775, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media/Music" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data" }, { 00750, AID_ROOT, AID_SHELL, 0, "sbin" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/bin" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/vendor" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/xbin" }, { 00755, AID_ROOT, AID_ROOT, 0, "system/etc/ppp" }, { 00777, AID_ROOT, AID_ROOT, 0, "sdcard" }, { 00755, AID_ROOT, AID_ROOT, 0, 0 }, }; /* Rules for files. ** These rules are applied based on "first match", so they ** should start with the most specific path and work their ** way up to the root. Prefixes ending in * denotes wildcard ** and will allow partial matches. */ static const struct fs_path_config android_files[] = { { 00440, AID_ROOT, AID_SHELL, 0, "system/etc/init.goldfish.rc" }, { 00550, AID_ROOT, AID_SHELL, 0, "system/etc/init.goldfish.sh" }, { 00440, AID_ROOT, AID_SHELL, 0, "system/etc/init.trout.rc" }, { 00550, AID_ROOT, AID_SHELL, 0, "system/etc/init.ril" }, { 00550, AID_ROOT, AID_SHELL, 0, "system/etc/init.testmenu" }, { 00550, AID_DHCP, AID_SHELL, 0, "system/etc/dhcpcd/dhcpcd-run-hooks" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, 0, "system/etc/dbus.conf" }, { 00444, AID_RADIO, AID_AUDIO, 0, "system/etc/AudioPara4.csv" }, { 00555, AID_ROOT, AID_ROOT, 0, "system/etc/ppp/*" }, { 00555, AID_ROOT, AID_ROOT, 0, "system/etc/rc.*" }, { 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app/*" }, { 00644, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media/*" }, { 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private/*" }, { 00644, AID_APP, AID_APP, 0, "data/data/*" }, { 00755, AID_ROOT, AID_ROOT, 0, "system/bin/ping" }, /* the following file is INTENTIONALLY set-gid and not set-uid. * Do not change. */ { 02750, AID_ROOT, AID_INET, 0, "system/bin/netcfg" }, /* the following five files are INTENTIONALLY set-uid, but they * are NOT included on user builds. */ { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/su" }, { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/librank" }, { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/procrank" }, { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/procmem" }, { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/tcpdump" }, { 04770, AID_ROOT, AID_RADIO, 0, "system/bin/pppd-ril" }, /* the following file has enhanced capabilities and IS included in user builds. */ { 00750, AID_ROOT, AID_SHELL, (1 << CAP_SETUID) | (1 << CAP_SETGID), "system/bin/run-as" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/bin/*" }, { 00755, AID_ROOT, AID_ROOT, 0, "system/lib/valgrind/*" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/xbin/*" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/vendor/bin/*" }, { 00750, AID_ROOT, AID_SHELL, 0, "sbin/*" }, { 00755, AID_ROOT, AID_ROOT, 0, "bin/*" }, { 00750, AID_ROOT, AID_SHELL, 0, "init*" }, { 00750, AID_ROOT, AID_SHELL, 0, "charger*" }, { 00750, AID_ROOT, AID_SHELL, 0, "sbin/fs_mgr" }, { 00640, AID_ROOT, AID_SHELL, 0, "fstab.*" }, { 00644, AID_ROOT, AID_ROOT, 0, 0 }, }; ... 

और स्थिर इनलाइन vs fs_config फ़ंक्शन (const char * path, int dir, unsigned * uid, अहस्ताक्षरित * gid, अहस्ताक्षरित * मोड, uint64_t * क्षमताएं) , जिसे बाद में इस फ़ाइल में परिभाषित किया गया है, जो स्वामी, स्वामी समूह, क्षमताओं और एक्सेस अधिकारों को सेट करने के लिए ज़िम्मेदार है। । यह फ़ंक्शन छवि असेंबली के दौरान कहा जाता है।

सामान्य तौर पर, कुछ फ़ाइलों के लिए अनुमतियाँ फ़्लैग (सेटिड और सेटगिड) सेट करने के अलावा यहां सब कुछ अधिक या कम स्पष्ट होना चाहिए (उदाहरण के लिए, "सिस्टम / xbin / su" के लिए अनुमतियाँ 06755 के रूप में परिभाषित की गई हैं, जहाँ पहले 6 का अर्थ है कि ध्वज सेट है सेट यूजर आईडी (4) और ग्रुप आईडी (2) सेट करने के लिए झंडा। इन झंडों को सेट करने का अर्थ है कि उपयोगकर्ता लॉन्च की गई प्रक्रिया के अधिकार को फ़ाइल या स्वामी समूह (स्वामी के समूह) के स्वामी (स्वामी) के स्तर तक बढ़ा सकता है। एंड्रॉइड के मामले में, प्रत्येक एप्लिकेशन अपने स्वयं के यूआईडी और जीआईडी ​​के साथ एक उपयोगकर्ता है। इस प्रकार, डिफ़ॉल्ट रूप से, यदि आप अपने एप्लिकेशन से कुछ मूल निष्पादन योग्य चलाते हैं, तो यह उसी UID और GID के साथ निष्पादित होता है, जिस एप्लिकेशन ने इसे बुलाया था। इन अनुमतियों के झंडे स्थापित करने से आप मालिक अधिकारों के साथ मूल निष्पादन योग्य प्रदर्शन कर सकते हैं। हमारे मामले में, मालिक AID_ROOT (रूट) है। यह निम्नलिखित सिस्टम / एक्स्ट्रा / su / su.c के साथ होता है:

 int main(int argc, char **argv) { ... int uid, gid, myuid; ... if(setgid(gid) || setuid(uid)) { ... } ... } 

यानी setuid और setgid फ़ंक्शन कहलाते हैं। इस मामले में, यदि ये फ़ंक्शन सफलतापूर्वक पूरा हो गए थे, तो इस फ़ाइल के स्वामी और स्वामी समूह की ओर से प्रक्रिया काम करना शुरू कर देती है। हमारे उदाहरण में, इस प्रक्रिया को सुपरयुसर अधिकार प्राप्त हैं, अर्थात। वह जो चाहे कर सकता है :) ऐसी अराजकता हमेशा उचित नहीं है, इसलिए लिनक्स ने क्षमताओं की अवधारणा पेश की। चूंकि रन-अस एप्लिकेशन को सभी सुपरयुजर अधिकारों की आवश्यकता नहीं है, इसलिए इसे केवल विभिन्न उपयोगकर्ताओं की ओर से एप्लिकेशन चलाने के लिए अपने पहचानकर्ता को बदलने में सक्षम होना चाहिए। वैसे, क्षमताओं को हाल ही में दिखाई दिया है - एंड्रॉइड 2.3.x में मैंने उन्हें नहीं देखा है।

सुरक्षा

विशेषाधिकार प्राप्त कार्यक्रमों (जैसे सु) के मामले में, उन अनुप्रयोगों की सीमा को सीमित करना आवश्यक है जिन्हें ये प्रोग्राम कॉल कर सकते हैं। अन्यथा, कोई भी एप्लिकेशन सुपरयुसर अधिकार प्राप्त कर सकता है। इसलिए, बहुत बार यूआईडी सत्यापन ऐसे कार्यक्रमों में बनाया जाता है:

 ... #include <private/android_filesystem_config.h> ... int main(int argc, char **argv) { struct passwd *pw; int uid, gid, myuid; /* Until we have something better, only root and the shell can use su. */ myuid = getuid(); if (myuid != AID_ROOT && myuid != AID_SHELL) { fprintf(stderr,"su: uid %d not allowed to su\n", myuid); return 1; } ... } 

यानी प्रोग्राम पहले चेक करता है कि किसकी ओर से कॉलिंग प्रक्रिया को गेट्यूड () फ़ंक्शन का उपयोग करना शुरू किया गया है। और फिर इन मूल्यों की तुलना उन मूल्यों से करता है जो सिस्टम में हार्ड-कोडित हैं। इस मामले में, केवल "सिस्टम" और "रूट" की ओर से चल रही प्रक्रियाओं में सु का उपयोग करने का अधिकार है।

निष्कर्ष

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

PS हमें DevConf @ mobi पर एक रिपोर्ट तैयार करने के लिए आमंत्रित किया गया था क्या आपको लगता है कि दर्शकों को एंड्रॉइड ऑपरेटिंग सिस्टम की सुरक्षा पर एक सम्मेलन में रुचि होगी जो कि एप्लिकेशन डेवलपर्स पर अधिक केंद्रित है?

संदर्भ

1. करीम यागमोर द्वारा "एंबेडेड एंड्रॉइड"
2. मार्को गार्जेंटा द्वारा एंड्रॉइड सिक्योरिटी अंडरपिनिंग्स
3. लिनक्स उपयोगकर्ता और समूह
4. छवि विन्यास
5. SUID
6. क्षमताओं का अवलोकन