تستفيد منصة Android من الحماية المستندة إلى المستخدم في Linux لتحديد موارد التطبيقات وعزلتها. ويؤدي ذلك إلى عزل التطبيقات عن بعضها ويحمي التطبيقات والنظام من التطبيقات الضارة. ولإجراء ذلك، يخصّص نظام التشغيل Android رقم تعريف مستخدم فريدًا (UID) لكل تطبيق Android ويشغّله في عملية خاصة به.
يستخدم نظام التشغيل Android رقم التعريف المطلق لإعداد "وضع الحماية للتطبيقات" على مستوى النواة. يفرض ملف المعالجة الأساسية الأمان بين التطبيقات والنظام على مستوى العملية من خلال مرافق Linux العادية، مثل أرقام تعريف المستخدمين والمجموعات التي يتم إسنادها إلى التطبيقات. لا يمكن للتطبيقات التفاعل مع بعضها تلقائيًا، ويكون لديها إذن وصول محدود إلى نظام التشغيل. إذا حاول التطبيق "أ" تنفيذ إجراء ضار، مثل قراءة بيانات التطبيق "ب" أو الاتصال بالهاتف بدون إذن، سيتم منعه من تنفيذ ذلك لأنّه لا يملك امتيازات المستخدم التلقائية المناسبة. إنّ مساحة المحاكاة بسيطة ويمكن مراجعتها، وهي تستند إلى أسلوب UNIX القديم في فصل المستخدمين عن العمليات وأذونات الملفات.
بما أنّ "حاجز التطبيقات" مضمّن في النواة، فإنّ نموذج الأمان هذا يشمل كلّ من الرموز البرمجية الأصلية وتطبيقات نظام التشغيل. يتم تشغيل جميع البرامج فوق النواة، مثل مكتبات نظام التشغيل وإطار عمل التطبيق ووقت تشغيل التطبيق وجميع التطبيقات، داخل "وضع الحماية للتطبيقات". في بعض المنصّات، يقتصر المطوّرون على إطار عمل تطوير معيّن أو مجموعة من واجهات برمجة التطبيقات أو لغة معيّنة. في نظام التشغيل Android، لا تُفرض أي قيود على كيفية كتابة التطبيق لفرض الأمان، وفي هذا الصدد، يتم وضع الرمز البرمجي الأصلي في مساحة مغلقة مثل الرمز البرمجي المُفترَض.
إجراءات الحماية
بشكل عام، للخروج من "وضع الحماية للتطبيقات" في جهاز تم ضبطه بشكل صحيح، يجب اختراق أمان نواة Linux. ومع ذلك، فإنّ وسائل الحماية الفردية التي تفرض بيئة التطبيق المُدمَجة ليست محصّنة تمامًا، تمامًا مثل ميزات الأمان الأخرى، لذا من المهم استخدام استراتيجية "الحماية الشاملة" لمنع هجمات تكنولوجيا المعلومات الفردية من التسبب في اختراق نظام التشغيل أو التطبيقات الأخرى.
يعتمد Android على عدد من إجراءات الحماية لفرض "وضع الحماية" في التطبيقات. تمّ تقديم إجراءات التنفيذ هذه بمرور الوقت، وساهمت في strengthening significantly the original UID-based discretionary access control (DAC) sandbox. تضمّنت إصدارات Android السابقة الحماية التالية:
- في نظام التشغيل Android 5.0، وفّر SELinux ميزة التحكّم الإلزامي في الوصول (MAC) بين النظام والتطبيقات. ومع ذلك، كانت جميع التطبيقات التابعة لجهات خارجية تعمل ضمن سياق SELinux نفسه، لذا تم فرض العزل بين التطبيقات بشكل أساسي من خلال UID DAC.
- في Android 6.0، تم توسيع نطاق مساحة وضع الحماية في SELinux لعزل التطبيقات على مستوى
حدود كل مستخدم فعلي. بالإضافة إلى ذلك، يضبط Android أيضًا إعدادات تلقائية أكثر أمانًا لملف ملف ملف
بيانات التطبيق: بالنسبة إلى التطبيقات التي تستخدم
targetSdkVersion >= 24، تم تغيير أذونات DAC التلقائية في الدليل الرئيسي للتطبيق من 751 إلى 700. وقد وفّرت هذه الإعدادات خيارًا تلقائيًا أكثر أمانًا لبيانات التطبيقات الخاصة (على الرغم من أنّ التطبيقات يمكنها إلغاء هذه الإعدادات التلقائية). - في الإصدار 8.0 من نظام التشغيل Android، تم ضبط جميع التطبيقات لتعمل باستخدام
seccomp-bpfفلتر يحدّ من طلبات نظام التشغيل التي يُسمح للتطبيقات باستخدامها، وبالتالي تعزيز حدود التطبيق/النواة. - في Android 9، يجب تشغيل جميع التطبيقات غير المميّزة التي تتضمّن
targetSdkVersion >= 28في قيود حماية فردية في SELinux، ما يوفر إمكانية الوصول إلى MAC على أساس كل تطبيق. تحسِّن هذه الحماية عملية فصل التطبيقات، وتمنع إلغاء الإعدادات التلقائية الآمنة، (والأهم من ذلك) تمنع التطبيقات من إتاحة الوصول إلى بياناتها على مستوى العالم. - في Android 10، تتوفّر للتطبيقات طريقة عرض محدودة للملفّات في ملف DCIM، بدون إمكانية الوصول مباشرةً إلى مسارات مثل /sdcard/DCIM. ومع ذلك، تحتفظ التطبيقات بإمكانية الوصول الكامل إلى المسارات الخاصة بحزمها، كما تظهر في أي methods سارية، مثل Context.getExternalFilesDir().
إرشادات حول مشاركة الملفات
إنّ ضبط بيانات التطبيق على أنّها متاحة للجميع هو ممارسة أمنية سيئة. يتم منح إذن الوصول
لجميع المستخدمين، ولا يمكن حصر إذن الوصول بالمستقبلين المقصودين
فقط. وقد أدّت هذه الممارسة إلى تسرُّب معلومات واختلاط
بالثغرات الأمنية، وهي هدف مفضّل للبرامج الضارة التي تستهدف التطبيقات التي تتعلّق
ببيانات حسّاسة (مثل برامج البريد الإلكتروني). في الإصدار 9 من Android والإصدارات الأحدث، لا يُسمح صراحةً بمشاركة
الملفات بهذه الطريقة للتطبيقات التي تستخدم
targetSdkVersion>=28.
بدلاً من إتاحة بيانات التطبيق للجميع، اتّبِع الإرشادات التالية عند مشاركة الملفات:
- إذا كان تطبيقك يحتاج إلى مشاركة الملفات مع تطبيق آخر، استخدِم فئة ContentProvider. يشارك موفّرو المحتوى البيانات بالدقة المناسبة وبدون السلبيات العديدة لأذونات UNIX التي يمكن للجميع الوصول إليها (للحصول على التفاصيل، يُرجى الاطّلاع على أساسيات موفّري المحتوى).
- إذا كان تطبيقك يتضمّن ملفات يجب أن يتمكن الجميع من الوصول إليها (مثل الصور)، يجب أن تكون ملفات خاصة بالوسائط (الصور والفيديوهات والملفات الصوتية فقط) وأن يتم تخزينها باستخدام فئة MediaStore. (لمزيد من التفاصيل حول كيفية إضافة ملف وسائط، يُرجى الاطّلاع على مقالة الوصول إلى ملفات الوسائط من مساحة تخزين مشتركة.)
يتحكّم إذن التشغيل مساحة التخزين في الوصول
إلى المجموعات ذات النوع المحدد بدقة من خلال MediaStore.
للوصول إلى الملفات ذات النوع غير المحدد بدقة، مثل ملفات PDF وفئتها MediaStore.Downloads، يجب أن تستخدم التطبيقات
المهام مثل مهمة ACTION_OPEN_DOCUMENT.
لتفعيل سلوك Android 10، استخدِم سمة
requestLegacyExternalStorage manifest
واتّبِع أفضل الممارسات المتعلّقة بأذونات التطبيقات.
- القيمة التلقائية لعلامة البيان هي
trueلتطبيقات التي تستهدف الإصدار 9 من نظام التشغيل Android والإصدارات الأقدم. - القيمة التلقائية هي false للتطبيقات التي تستهدف الإصدار 10 من Android. لإيقاف عرض مساحة التخزين المنفلت
مؤقتًا في التطبيقات التي تستهدف الإصدار 10 من Android،
اضبط قيمة علامة البيان على
true. - باستخدام الأذونات المحظورة، يضيف مثبّت التطبيق التطبيقات المُسموحة لوحدة التخزين غير المحمية ببيئة معزولة إلى القائمة المسموح بها. يتم وضع التطبيقات غير المدرَجة في القائمة المسموح بها في بيئة معزولة.