مفاهيم SELinux

راجع هذه الصفحة لتتعرف على مفاهيم SELinux.

التحكم الإلزامي في الوصول

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

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

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

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

راجع حالات الاستخدام لمزيد من الأمثلة على التهديدات وطرق معالجتها باستخدام SELinux.

مستويات التنفيذ

يمكن تنفيذ SELinux في أوضاع مختلفة:

  • مسموح به - لا يتم فرض سياسة أمان SELinux، بل يتم تسجيلها فقط.
  • التنفيذ - يتم فرض سياسة الأمان وتسجيلها. تظهر حالات الفشل كأخطاء EPERM.

يعد هذا الاختيار ثنائيًا ويحدد ما إذا كانت سياستك ستتخذ إجراءً أم أنها تسمح لك فقط بجمع حالات الفشل المحتملة. المسموح به مفيد بشكل خاص أثناء التنفيذ.

الأنواع والصفات والقواعد

يعتمد Android على مكون فرض النوع (TE) في SELinux في سياسته. هذا يعني أن جميع الكائنات (مثل الملف أو العملية أو المقبس) لها نوع مرتبط بها. على سبيل المثال، بشكل افتراضي، سيكون التطبيق من النوع untrusted_app . بالنسبة للعملية، يُعرف نوعها أيضًا بالمجال الخاص بها. من الممكن إضافة تعليق توضيحي إلى نوع يحتوي على سمة واحدة أو أكثر. السمات مفيدة للإشارة إلى أنواع متعددة في نفس الوقت.

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

تأتي قاعدة السياسة على شكل: allow source target : class permissions ; أين:

  • المصدر - نوع (أو سمة) موضوع القاعدة. من يطلب الوصول؟
  • الهدف - نوع (أو سمة) الكائن. إلى ماذا يطلب الوصول؟
  • الفئة - نوع الكائن (على سبيل المثال، الملف، المقبس) الذي يتم الوصول إليه.
  • الأذونات - العملية (أو مجموعة العمليات) (مثل القراءة والكتابة) التي يتم تنفيذها.

مثال على القاعدة هو:

allow untrusted_app app_data_file:file { read write };

يشير هذا إلى أنه يُسمح للتطبيقات بقراءة وكتابة الملفات المسماة app_data_file . توجد أنواع أخرى للتطبيقات. على سبيل المثال، يتم استخدام isolated_app لخدمات التطبيقات التي تحتوي على isolatedProcess=true في ملف البيان الخاص بها. بدلاً من تكرار القاعدة لكلا النوعين، يستخدم Android سمة تسمى appdomain لجميع الأنواع التي تغطي التطبيقات:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

عند كتابة قاعدة تحدد اسم السمة، يتم توسيع هذا الاسم تلقائيًا إلى قائمة المجالات أو الأنواع المرتبطة بالسمة. بعض السمات البارزة هي:

  • domain - السمة المرتبطة بجميع أنواع العمليات،
  • file_type - السمة المرتبطة بجميع أنواع الملفات.

وحدات الماكرو

للوصول إلى الملفات على وجه الخصوص، هناك العديد من أنواع الأذونات التي يجب مراعاتها. على سبيل المثال، إذن read ليس كافيًا لفتح الملف أو استدعاء stat عليه. لتبسيط تعريف القاعدة، يوفر Android مجموعة من وحدات الماكرو للتعامل مع الحالات الأكثر شيوعًا. على سبيل المثال، لتضمين الأذونات المفقودة مثل open ، يمكن إعادة كتابة القاعدة أعلاه على النحو التالي:

allow appdomain app_data_file:file rw_file_perms;

راجع ملفات global_macros و te_macros للحصول على مزيد من الأمثلة على وحدات الماكرو المفيدة. يجب استخدام وحدات الماكرو كلما أمكن ذلك للمساعدة في تقليل احتمالية الفشل بسبب رفض الأذونات ذات الصلة.

بمجرد تعريف النوع، يجب أن يكون مرتبطًا بالملف أو العملية التي يمثلها. راجع تنفيذ SELinux لمزيد من التفاصيل حول كيفية إجراء هذا الارتباط. لمزيد من المعلومات حول القواعد، راجع مفكرة SELinux .

السياق والفئات الأمنية

عند تصحيح أخطاء سياسات SELinux أو تصنيف الملفات (عبر file_contexts أو عند استخدام ls -Z )، قد تصادف سياقًا أمنيًا (يُعرف أيضًا باسم label ). على سبيل المثال: u:r:untrusted_app:s0:c15,c256,c513,c768 . سياق الأمان له التنسيق: user:role:type:sensitivity[:categories] . يمكنك عادةً تجاهل حقول user role sensitivity الخاصة بالسياق (راجع الخصوصية ). تم شرح حقل type في القسم السابق. تعد categories جزءًا من دعم الأمان متعدد المستويات (MLS) في SELinux. منذ Android S، يتم استخدام الفئات من أجل:

  • عزل بيانات التطبيق عن الوصول إليها عن طريق تطبيق آخر،
  • عزل بيانات التطبيق من مستخدم فعلي إلى آخر.

النوعية

لا يستخدم Android جميع الميزات التي يوفرها SELinux. عند قراءة الوثائق الخارجية، ضع هذه النقاط في الاعتبار:

  • يتم تعريف غالبية السياسات في AOSP باستخدام لغة سياسة Kernel. هناك بعض الاستثناءات لاستخدام اللغة المتوسطة المشتركة (CIL).
  • لا يتم استخدام مستخدمي SELinux. المستخدم الوحيد المحدد هو u . عند الضرورة، يتم تمثيل المستخدمين الفعليين باستخدام حقل الفئات في سياق الأمان.
  • لا يتم استخدام أدوار SELinux والتحكم في الوصول المستند إلى الأدوار (RBAC). يتم تعريف واستخدام دورين افتراضيين: r للمواضيع و object_r للكائنات.
  • لا يتم استخدام حساسيات SELinux. يتم دائمًا ضبط حساسية s0 الافتراضية.
  • لا يتم استخدام القيم المنطقية SELinux. بمجرد إنشاء السياسة لجهاز ما، فإنها لا تعتمد على حالة الجهاز. وهذا يبسط التدقيق وتصحيح السياسات.