Linux المحسّن للأمان في Android

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

يعمل SELinux على مبدأ الرفض الافتراضي: يتم رفض أي شيء غير مسموح به صراحة. يمكن لـ SELinux العمل في وضعين عالميين:

  • الوضع المسموح به ، حيث يتم تسجيل حالات رفض الأذونات ولكن لا يتم فرضها.
  • وضع الإنفاذ ، حيث يتم تسجيل حالات رفض الأذونات وفرضها .

يشتمل Android على SELinux في وضع الإنفاذ وسياسة أمان مقابلة تعمل افتراضيًا عبر AOSP. في وضع الإنفاذ ، يتم منع الإجراءات غير المسموح بها ويتم تسجيل جميع محاولات الانتهاكات بواسطة kernel إلى dmesg و logcat . عند التطوير ، يجب عليك استخدام هذه الأخطاء لتحسين برامجك وسياسات SELinux قبل فرضها. لمزيد من التفاصيل ، راجع تنفيذ SELinux .

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

خلفية

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

في Android 5.0 والإصدارات الأحدث ، يتم تطبيق SELinux بالكامل ، بناءً على الإصدار المسموح به من Android 4.3 والتطبيق الجزئي لنظام Android 4.4. مع هذا التغيير ، تحول Android من فرض مجموعة محدودة من المجالات الحاسمة ( installd و netd و vold و zygote ) إلى كل شيء (أكثر من 60 نطاقًا). خاصة:

  • كل شيء في وضع الإنفاذ في Android 5.x والإصدارات الأحدث.
  • يجب عدم تشغيل أي عمليات بخلاف init في المجال init .
  • يشير أي رفض عام (لجهاز block_device ، socket_device ، default_service ) إلى أن الجهاز يحتاج إلى مجال خاص.

عمل Android 6.0 على تقوية النظام عن طريق الحد من سماح سياستنا لتشمل عزلًا أفضل بين المستخدمين ، وتصفية IOCTL ، وتقليل تهديد الخدمات المكشوفة ، وزيادة تشديد نطاقات SELinux ، والوصول المحدود للغاية /proc .

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

قام Android 8.0 بتحديث SELinux للعمل مع Treble ، والذي يفصل رمز البائع ذي المستوى الأدنى عن إطار عمل نظام Android. قام هذا الإصدار بتحديث سياسة SELinux للسماح لمصنعي الأجهزة وبائعي SOC بتحديث أجزاء السياسة الخاصة بهم ، وبناء صورهم ( vendor.img ، boot.img ، إلخ) ، ثم تحديث تلك الصور بشكل مستقل عن النظام الأساسي أو العكس.

في حين أنه من الممكن أن يكون لديك إصدار نظام أساسي (إطار عمل) أعلى / أحدث يعمل على الجهاز ، فإن الحالة المعاكسة غير مدعومة ؛ لا يمكن أن تحتوي صور البائع ( vendor.img/odm.img ) على إصدار أحدث من النظام الأساسي ( system.img ). لذلك ، قد يعرض إصدار النظام الأساسي الجديد مشكلات توافق SELinux لأن سياسة SELinux للنظام الأساسي في إصدار أحدث من أجزاء البائع SELinux من السياسة. يوفر نموذج Android 8.0 طريقة للاحتفاظ بالتوافق لمنع OTAs المتزامنة غير الضرورية.

مصادر إضافية

للمساعدة في بناء سياسات SELinux المفيدة ، راجع المصادر التالية. لا يتم استخدام بعض مفاهيم SELinux بواسطة Android ، راجع قسم Specificity عند التفكير في التوثيق الخارجي.