مفاهيم SELinux

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

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

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

تم تنفيذ SELinux كجزء من إطار عمل Linux Security Module (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 ) ، قد تصادف سياق أمان (يُعرف أيضًا باسم التسمية ). على سبيل المثال: 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 المنطقية. بمجرد إنشاء السياسة لجهاز ، فإنها لا تعتمد على حالة الجهاز. هذا يبسط التدقيق وتصحيح السياسات.