تطبيق Sandbox

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

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

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

الحماية

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

يعتمد Android على عدد من وسائل الحماية لفرض حماية التطبيق. تم تقديم هذه الإنفاذات بمرور الوقت وعززت بشكل كبير صندوق الحماية الأصلي للتحكم في الوصول التقديري المستند إلى المعرف الفريد العمومي (DAC). تضمنت إصدارات 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 ".
  • باستخدام الأذونات المقيدة ، يقوم المثبِّت بوضع قائمة بيضاء بالتطبيقات المسموح بها للتخزين غير المزود بوضع الحماية. التطبيقات غير المدرجة في القائمة البيضاء في وضع الحماية.