راجِع هذه الصفحة للتعرّف على مفاهيم SELinux.
التحكّم الإلزامي في الوصول
Security Enhanced Linux (SELinux) هو نظام التحكّم الإجباري في الوصول (MAC) لنظام التشغيل Linux. وبما أنّه نظام MAC، يختلف عن نظام التحكم في الوصول الاختياري (DAC) المألوف في Linux. في نظام DAC، يتوفّر مفهوم الملكية، حيث يتحكّم مالك مورد معيّن في أذونات الوصول المرتبطة به. ويكون هذا الإجراء بشكل عام ذا نطاق واسع وخاضعًا لتصعيد الأذونات غير المقصود. ومع ذلك، يراجع نظام MAC جهة سلطة مركزية لاتخاذ قرار بشأن جميع محاولات الوصول.
تم تنفيذ SELinux كجزء من إطار عمل "وحدة أمان Linux" (LSM)، الذي يتعرّف على عناصر النواة المختلفة والإجراءات الحسّاسة التي يتم تنفيذها عليها. في النقطة التي سيتم فيها تنفيذ كل من هذين الإجراءين، يتم استدعاء وظيفة خطاف LSM لتحديد ما إذا كان ينبغي السماح بالإجراء استنادًا إلى المعلومات المخزّنة في عنصر أمان غير شفاف. يقدّم SELinux تنفيذًا لهذه العناصر و إدارة عناصر الأمان هذه، والتي تتحدّ مع سياسته الخاصة، لتحديد قرارات الوصول.
إلى جانب إجراءات الأمان الأخرى في Android، تعمل سياسة التحكّم في الوصول في Android على الحدّ بشكل كبير من الأضرار المحتملة للأجهزة والحسابات التي تم اختراقها. من خلال استخدام أدوات مثل عناصر التحكّم في الوصول الاختياري والإلزامي في Android، يمكنك ضمان تشغيل برنامجك بالحد الأدنى من مستوى امتيازاته فقط. ويساعد ذلك في تخفيف تأثير الهجمات ويقلل من احتمالية أن تؤدي العمليات الخاطئة إلى استبدال البيانات أو حتى نقلها.
في الإصدار 4.3 من نظام التشغيل Android والإصدارات الأحدث، يقدّم SELinux منظومة التحكّم الإجباري في الوصول (MAC) على البيئات التقليدية للتحكّم في الوصول الاختياري (DAC). على سبيل المثال، يجب تشغيل البرامج عادةً باسم حساب المستخدم الجذر لكتابة البيانات على وحدات التخزين المكوّنة من وحدات ذاكرة مملوكة لمستخدم واحد. في بيئة Linux التقليدية المستندة إلى DAC، إذا تم اختراق ملف تعريف مستخدم الجذر، يمكن لهذا المستخدم الكتابة في كل جهاز كتلة أساسية. ومع ذلك، يمكن استخدام SELinux لتصنيف هذه الأجهزة حتى لا تتمكّن العملية التي تم منحها امتياز root من الكتابة إلا في الملفات المحدّدة في السياسة المرتبطة. بهذه الطريقة، لا يمكن للمعالجة استبدال البيانات وإعدادات النظام خارج جهاز الكتل الأولية المحدّد.
اطّلِع على حالات الاستخدام لمزيد من الأمثلة على التهديدات وطرق معالجتها باستخدام 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. في الإصدار 12 من نظام التشغيل Android والإصدارات الأحدث، تُستخدَم الفئات لإجراء ما يلي:
- عزل بيانات التطبيق عن الوصول إليها من خلال تطبيق آخر
- عزل بيانات التطبيق من مستخدم فعلي إلى آخر
الدقة
لا يستخدم نظام التشغيل Android جميع الميزات التي يوفّرها SELinux. عند قراءة مستندات خارجية، يُرجى مراعاة النقاط التالية:
- يتم تحديد معظم السياسات في AOSP باستخدام لغة سياسة Kernel. هناك بعض الاستثناءات لاستخدام لغة الواسطة الشائعة (CIL).
- لا يتم استخدام مستخدمي SELinux. المستخدم الوحيد المحدَّد هو
u. يتم تمثيل المستخدمين الفعليين باستخدام حقل الفئات في سياق الأمان عند الضرورة. - لا يتم استخدام أدوار SELinux وميزة "التحكّم في الوصول المستنِد إلى الدور" (RBAC). تمّ تحديد دورَين تلقائيَين واستخدامهما:
rللعناصر الرئيسية وobject_rللكائنات. - لا يتم استخدام حساسيات SELinux. يتم دائمًا ضبط الحساسية التلقائية
s0. - لا يتم استخدام القيم المنطقية لنظام SELinux. عند إنشاء السياسة لجهاز معيّن، لا تعتمد على حالة الجهاز. ويؤدي ذلك إلى تبسيط تدقيق السياسات وتصحيح الأخطاء فيها.