راجع هذه الصفحة للتعرف على مفاهيم SELinux.
التحكم الإلزامي في الوصول
نظام التشغيل Linux المحسّن (SELinux)، هو نظام إلزامي للتحكّم في الوصول (MAC) لنظام التشغيل Linux. فهو يختلف عن نظام MAC لنظام التشغيل Linux نظام التحكم في الوصول التقديري (DAC) المألوف. أما في نظام DAC، فهو مفهوم للملكية، حيث يتحكم مالك مورد معين في الوصول الأذونات المرتبطة به. ويكون هذا بشكل عام دقيقًا وموضوعيًا إلى تصعيد امتيازات غير مقصودة. ومع ذلك، يستشير نظام MAC وحدة مركزية هيئة إصدار قرار بشأن جميع محاولات الوصول.
تم تنفيذ آلية SELinux كجزء من وحدة أمان Linux (LSM). ويتعرّف على كائنات النواة المتنوعة والإجراءات الحساسة يتم تنفيذه عليهم. في المرحلة التي يتم فيها اعتبار كل إجراء من هذه الإجراءات مختلف، يتم استدعاء دالة خطّاف LSM لتحديد ما إذا كان بناءً على المعلومات الخاصة به المخزنة بشكل غير شفاف كائن الأمان. توفر SELinux تنفيذًا لهذه العناصر الجذابة إدارة عناصر الأمان هذه، والتي تندمج مع سياستها الخاصة، لتحديد قرارات الوصول.
إلى جانب إجراءات الأمان الأخرى لنظام التشغيل Android، يمكنك الآن التحكّم في الوصول إلى أجهزة Android تحد من الضرر المحتمل للأجهزة المخترقة بشكل كبير الحسابات. استخدام أدوات مثل أدوات الوصول الحصرية والإلزامية إلى Android بنية تضمن عدم تشغيل برنامجك إلا على أقل تقدير مستوى الامتياز. يخفف هذا من آثار الهجمات ويقلل من احتمالية استبدال العمليات الخاطئة أو حتى نقلها.
في نظام Android 4.3 والإصدارات الأحدث، توفر SELinux التحكم الإلزامي بالوصول (MAC) نظام شامل على بيئات التحكم في الوصول التقديري التقليدية (DAC). بالنسبة على سبيل المثال، يجب تشغيل البرنامج عادةً كحساب مستخدم جذر لكتابة محتوى غير حظر الأجهزة. في بيئة Linux التقليدية القائمة على DAC، إذا حاول مستخدم الجذر يمكن للمستخدم الكتابة إلى كل جهاز كتلة أولية. ومع ذلك، ويمكن استخدام SELinux لتصنيف هذه الأجهزة بحيث تقوم العملية بتعيين الجذر لا يمكنه الكتابة إلا إلى المستخدمين المحدَّدين في السياسة المرتبطة. في هذه الدورة، فإن هذه العملية لا يمكن أن تؤدي إلى استبدال البيانات وإعدادات النظام خارج لجهاز كتلة أولية محددة.
راجِع حالات الاستخدام. للحصول على مزيد من الأمثلة على التهديدات وطرق معالجتها باستخدام SELinux.
مستويات التنفيذ
يمكن تنفيذ SELinux بأوضاع مختلفة:
- متساهلة - لا يتم فرض سياسة أمان SELinux، بل يتم تسجيلها فقط.
- الفرض: يتم فرض سياسة الأمان وتسجيلها. المستلمون الذين تعذُّر الإرسال إليهم تظهر كأخطاء EPERM.
يعتمد هذا الاختيار على نظام ثنائي ويحدّد ما إذا كانت سياستك ستتخذ إجراءً أم مجرد بجمع حالات الإخفاق المحتملة. "متساهلة" مفيدة بشكل خاص أثناء التنفيذ.
الأنواع والسمات والقواعد
يعتمد Android على مكون فرض الكتابة (TE) في SELinux
. وهذا يعني أن جميع الكائنات (مثل ملف أو عملية أو مقبس) لها
type المرتبطة بها. على سبيل المثال، يغني تطبيق
من النوع 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 Notebook.
سياق الأمان وفئاته
عند تصحيح أخطاء سياسات 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. وبعد إنشاء السياسة لأحد الأجهزة، فإنّها لا يعتمد على حالة الجهاز. يعمل ذلك على تبسيط التدقيق في السياسات وتصحيحها.