تطبيق Sandbox

يستفيد نظام Android الأساسي من الحماية المستندة إلى مستخدم Linux لتحديد موارد التطبيق وعزلها. يؤدي هذا إلى عزل التطبيقات عن بعضها البعض وحماية التطبيقات والنظام من التطبيقات الضارة. للقيام بذلك، يقوم Android بتعيين معرف مستخدم فريد (UID) لكل تطبيق Android وتشغيله في العملية الخاصة به.

يستخدم Android UID لإعداد Sandbox للتطبيق على مستوى kernel. يفرض kernel الأمان بين التطبيقات والنظام على مستوى العملية من خلال مرافق Linux القياسية مثل معرفات المستخدم والمجموعة التي تم تعيينها للتطبيقات. افتراضيًا، لا يمكن للتطبيقات التفاعل مع بعضها البعض ويكون وصولها محدودًا إلى نظام التشغيل. إذا حاول التطبيق "أ" القيام بشيء ضار، مثل قراءة بيانات التطبيق "ب" أو الاتصال بالهاتف دون إذن، فسيتم منعه من القيام بذلك لأنه لا يتمتع بامتيازات المستخدم الافتراضية المناسبة. إن وضع الحماية بسيط وقابل للتدقيق ويعتمد على فصل المستخدم للعمليات وأذونات الملفات منذ عقود على طراز UNIX.

نظرًا لأن تطبيق Sandbox موجود في kernel، فإن نموذج الأمان هذا يمتد إلى كل من التعليمات البرمجية الأصلية وتطبيقات نظام التشغيل. تعمل جميع البرامج الموجودة فوق النواة، مثل مكتبات نظام التشغيل وإطار عمل التطبيق ووقت تشغيل التطبيق وجميع التطبيقات، ضمن وضع الحماية للتطبيقات. في بعض الأنظمة الأساسية، يكون المطورون مقيدين بإطار تطوير محدد أو مجموعة من واجهات برمجة التطبيقات أو اللغة. على نظام Android، لا توجد قيود على كيفية كتابة التطبيق المطلوب لفرض الأمان؛ في هذا الصدد، تكون التعليمات البرمجية الأصلية في وضع الحماية مثل التعليمات البرمجية المفسرة.

الحماية

بشكل عام، للخروج من وضع الحماية للتطبيقات في جهاز تم تكوينه بشكل صحيح، يجب على المرء أن يعرض أمان Linux kernel للخطر. ومع ذلك، كما هو الحال مع ميزات الأمان الأخرى، فإن وسائل الحماية الفردية التي تفرض وضع حماية التطبيق ليست معرضة للخطر، لذا فإن الدفاع المتعمق مهم لمنع الثغرات الأمنية الفردية من التسبب في اختراق نظام التشغيل أو التطبيقات الأخرى.

يعتمد Android على عدد من وسائل الحماية لفرض وضع الحماية للتطبيق. لقد تم تقديم إجراءات التنفيذ هذه بمرور الوقت وعززت بشكل كبير صندوق الحماية الأصلي للتحكم في الوصول التقديري (DAC) القائم على UID. تضمنت إصدارات Android السابقة وسائل الحماية التالية:

• في Android 5.0، قدم SELinux فصلًا إلزاميًا للتحكم في الوصول (MAC) بين النظام والتطبيقات. ومع ذلك، تم تشغيل جميع تطبيقات الطرف الثالث ضمن نفس سياق SELinux، لذلك تم فرض العزل بين التطبيقات بشكل أساسي بواسطة UID DAC.
• في Android 6.0، تم توسيع صندوق الحماية SELinux لعزل التطبيقات عبر حدود كل مستخدم فعلي. بالإضافة إلى ذلك، يقوم Android أيضًا بتعيين إعدادات افتراضية أكثر أمانًا لبيانات التطبيق: بالنسبة للتطبيقات التي تحتوي على targetSdkVersion >= 24 ، تم تغيير أذونات DAC الافتراضية على الدليل الرئيسي للتطبيق من 751 إلى 700. وقد وفر هذا افتراضيًا أكثر أمانًا لبيانات التطبيق الخاصة (على الرغم من أن التطبيقات قد تتجاوز هذه الإعدادات الافتراضية) .
• في Android 8.0، تم ضبط جميع التطبيقات لتعمل باستخدام مرشح seccomp-bpf الذي يحد من مكالمات النظام التي يُسمح للتطبيقات باستخدامها، وبالتالي تعزيز حدود التطبيق/النواة.
• في Android 9، يجب تشغيل جميع التطبيقات غير المميزة التي تحتوي على targetSdkVersion >= 28 في صناديق حماية SELinux فردية، مما يوفر MAC على أساس كل تطبيق. تعمل هذه الحماية على تحسين فصل التطبيقات، وتمنع تجاوز الإعدادات الافتراضية الآمنة، و(الأهم من ذلك) تمنع التطبيقات من إتاحة الوصول إلى عالم البيانات الخاص بها.
• تتمتع التطبيقات في Android 10 بعرض أولي محدود لنظام الملفات، مع عدم وجود وصول مباشر إلى مسارات مثل /sdcard/DCIM. ومع ذلك، تحتفظ التطبيقات بالوصول الأولي الكامل إلى مسارات الحزمة الخاصة بها، كما يتم إرجاعها بواسطة أي طرق قابلة للتطبيق، مثل context.getExternalFilesDir() .

إرشادات لمشاركة الملفات

يعد تعيين بيانات التطبيق بحيث يمكن الوصول إليها عالميًا ممارسة أمنية سيئة. يتم منح الوصول للجميع وليس من الممكن قصر الوصول على المستلم (المستلمين) المقصود فقط. وقد أدت هذه الممارسة إلى تسرب المعلومات وإرباك نقاط الضعف، وهي هدف مفضل للبرامج الضارة التي تستهدف التطبيقات ذات البيانات الحساسة (مثل عملاء البريد الإلكتروني). في Android 9 والإصدارات الأحدث، مشاركة الملفات بهذه الطريقة غير مسموح بها بشكل صريح للتطبيقات ذات targetSdkVersion>=28 .

بدلاً من جعل بيانات التطبيق متاحة للجميع، استخدم الإرشادات التالية عند مشاركة الملفات:

• إذا كان تطبيقك يحتاج إلى مشاركة الملفات مع تطبيق آخر، فاستخدم موفر المحتوى . يقوم موفرو المحتوى بمشاركة البيانات بالدقة المناسبة ودون الجوانب السلبية العديدة لأذونات UNIX التي يمكن الوصول إليها عالميًا (لمزيد من التفاصيل، راجع أساسيات موفر المحتوى ).
• إذا كان تطبيقك يحتوي على ملفات يجب أن تكون متاحة للعالم (مثل الصور)، فيجب أن تكون خاصة بالوسائط (الصور ومقاطع الفيديو والملفات الصوتية فقط) ومخزنة باستخدام فئة MediaStore . (لمزيد من التفاصيل حول كيفية إضافة عنصر وسائط، راجع الوصول إلى ملفات الوسائط من وحدة التخزين المشتركة .)

يتحكم إذن وقت تشغيل التخزين في الوصول إلى المجموعات المكتوبة بقوة من خلال MediaStore . للوصول إلى الملفات المكتوبة بشكل ضعيف مثل ملفات PDF وفئة MediaStore.Downloads ، يجب أن تستخدم التطبيقات أهدافًا مثل غرض ACTION_OPEN_DOCUMENT .

لتمكين سلوك Android 10، استخدم سمة بيان requestLegacyExternalStorage ، واتبع أفضل ممارسات أذونات التطبيق .

• تكون القيمة الافتراضية لعلامة البيان true بالنسبة للتطبيقات التي تستهدف Android 9 (والإصدارات الأقدم).
• القيمة الافتراضية خاطئة للتطبيقات التي تستهدف Android 10. لإلغاء الاشتراك مؤقتًا في عرض التخزين المفلتر في التطبيقات التي تستهدف Android 10، قم بتعيين قيمة علامة البيان على true .
• باستخدام الأذونات المقيدة، يقوم برنامج التثبيت بإدراج التطبيقات المسموح بها للتخزين غير المحمي في القائمة البيضاء. يتم وضع الحماية للتطبيقات غير المدرجة في القائمة البيضاء.