كتابة سياسة SELinux

يوفر المشروع المفتوح المصدر لنظام Android (AOSP) سياسة أساسية صلبة التطبيقات والخدمات الشائعة عبر جميع أجهزة Android. يحسّن المساهمون في AOSP هذه السياسة بانتظام. من المتوقّع أن نصل السياسة الأساسية لحوالي 90% إلى 95% من السياسة النهائية الخاصة بالأجهزة التخصيصات التي تشكل النسبة المتبقية من 5 إلى 10٪. تركز هذه المقالة على هذه التخصيصات الخاصة بالجهاز، وكيفية كتابة سياسة خاصة بكل جهاز، بعض الصعاب التي يجب تجنبها طوال العملية.

إظهار الجهاز

عند كتابة سياسة خاصة بالجهاز، اتّبِع الخطوات التالية.

التنفيذ في الوضع المتساهِل

عندما يكون الجهاز في وضع التساهل، ويتم تسجيل عمليات الرفض ولكن لا يتم فرضها. "وضع التساهل" مهم لشخصَين الأسباب:

  • يضمن الوضع المتساهِل ألّا يؤدي عرض السياسات إلى أي تأخير في أوقات أخرى. مهام إظهار الجهاز.
  • وقد يؤدي الرفض القسري إلى إخفاء حالات رفض أخرى. على سبيل المثال، يمكن الوصول إلى الملفات ما يتطلبه الأمر عادةً البحث عن دليل ثم فتح ملف ثم قراءة ملف. ضِمن وضع الفرض، فلن يحدث سوى رفض البحث في الدليل. متساهل يضمن رؤية جميع عمليات الرفض.

إنّ أبسط طريقة لوضع الجهاز في وضع التساهل هي استخدام أمر kernel السطر. يمكن إضافة ذلك إلى ملف BoardConfig.mk للجهاز: platform/device/<vendor>/<target>/BoardConfig.mk بعد تعديل سطر الأوامر، يمكنك تنفيذ make clean، ثم make bootimage، واحصل على فلاش صورة التشغيل الجديدة.

بعد ذلك، يمكنك تأكيد الوضع المتساهِل باستخدام ما يلي:

adb shell getenforce

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

التنفيذ مبكرًا

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

إزالة السياسة الحالية أو حذفها

هناك عدد من الأسباب الوجيهة لإنشاء سياسة خاصة بالجهاز من نقطة الصفر على جهاز جديد، والذي يشمل:

معالجة عمليات رفض الخدمات الأساسية

تتم معالجة عمليات الرفض التي تنشأ عن الخدمات الأساسية عادةً من خلال تصنيف الملفات. مثلاً:

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

تتم معالجته بالكامل من خلال تصنيف /dev/kgsl-3d0 بشكل صحيح. ضِمن في هذا المثال، tcontext هي device. يمثل ذلك السياق التلقائي حيث يتلقى كل شيء في /dev " جهاز" ما لم يتم تحديد تصنيف أكثر تحديدًا. مجرد قبول الناتج من audit2allow سوف ينتج عنه قاعدة غير صحيحة ومفرطة في التساهل.

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

الملفات الأخرى الخاصة بالجهاز والتي يجب تصنيفها بأنواع محددة مسبقًا السياسة الأساسية:

بشكل عام، إنّ منح الأذونات للتصنيفات التلقائية ليس صحيحًا. فالعديد من هذه الأذونات غير مسموح بها من قِبل neverallow، لكن حتى عندما لا يُسمَح بذلك بشكل صريح، فإن أفضل ممارسة هي تقديم سطر التصنيف.

تصنيف الخدمات والعناوين الجديدة عمليات الرفض

يجب أن يتم تشغيل الخدمات التي يتم إطلاقها في نطاقات SELinux الخاصة بها. تشير رسالة الأشكال البيانية في المثال التالي تضع الخدمة "foo" في نطاق SELinux الخاص بها وتمنحها الأذونات.

يتم إطلاق الخدمة في ملف init.device.rc باسم:

service foo /system/bin/foo
    class core
  1. إنشاء نطاق جديد "foo"

    إنشاء الملف device/manufacturer/device-name/sepolicy/foo.te تشتمل على المحتوى التالي:

    # foo service
type foo, domain;
type foo_exec, exec_type, file_type;

init_daemon_domain(foo)

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

  2. تصنيف /system/bin/foo

    إضافة ما يلي إلى device/manufacturer/device-name/sepolicy/file_contexts:

    /system/bin/foo   u:object_r:foo_exec:s0

    هذا من شأنه التأكد من تسمية الملف التنفيذي بشكل صحيح بحيث تقوم SELinux بتشغيل في المجال الصحيح.

  3. أنشِئ وشغِّل صور نظام التشغيل والتشغيل.
  4. عليك تحسين قواعد SELinux الخاصة بالمجال.

    استخدِم عمليات الرفض لتحديد الأذونات المطلوبة. تشير رسالة الأشكال البيانية audit2allow هذه الأداة إرشادات جيدة، ولكن لا تستخدمها إلا لإبلاغ السياسة الكتابة. ولا تنسخ المخرجات فقط.

الرجوع إلى وضع الفرض

لا بأس في تحديد المشاكل وحلّها في الوضع المتساهِل، ولكن مع العودة إلى وضع فرض في أقرب وقت ممكن ومحاولة البقاء فيه.

أخطاء شائعة

فيما يلي بعض الحلول للأخطاء الشائعة التي تحدث عند الكتابة سياسات خاصة بكل جهاز.

الإفراط في استخدام النفي

تشبه قاعدة المثال التالي قفل الباب الأمامي مع ترك النوافذ المفتوحة:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

الهدف واضح: يمكن للجميع الوصول إلى تصحيح الأخطاء باستثناء التطبيقات التابعة لجهات خارجية. الخاص بك.

والقاعدة معيبة في عدة جوانب. استبعاد untrusted_app البساطة في حل هذه المشكلة لأن جميع التطبيقات قد تشغل خدمات بشكل اختياري في نطاق isolated_app. وبالمثل، إذا كانت النطاقات الجديدة للتطبيقات التابعة لجهات خارجية تمت إضافتها إلى AOSP، سيكون بإمكانهم أيضًا الوصول إلى scary_debug_device. القاعدة متساهلة للغاية. لن تستفيد معظم النطاقات من وجود الوصول إلى أداة تصحيح الأخطاء هذه. ينبغي أن تتم كتابة القاعدة للسماح فقط النطاقات التي تتطلب الوصول.

تصحيح الأخطاء في الميزات في الإنتاج

يجب ألا تكون ميزات تصحيح الأخطاء موجودة في بُنى الإنتاج ويجب ألا .

وأبسط بديل هو السماح بميزة تصحيح الأخطاء فقط عندما تكون SELinux غير مفعَّل في إصدارات eng/userdebug، مثل adb root adb shell setenforce 0

هناك بديل آمن آخر وهو تضمين أذونات تصحيح الأخطاء في userdebug_or_eng.

الزيادة في حجم السياسات

توضيح سياسات SEAndroid بشكل عام يصف اتجاهًا مثيرًا للقلق في زيادة تخصيصات سياسة الأجهزة. يجب أن تمثّل السياسة الخاصة بالجهاز نسبة %5 إلى %10 من السياسة الإجمالية التي يتم تطبيقها على أحد الأجهزة. من المؤكد أن التخصيصات في النطاق 20٪ أو أكثر تحتوي على ما يزيد عن والنطاقات الخاصة والسياسة المعطلة.

سياسة كبيرة غير ضرورية:

  • والآن لم يكُن هناك أي تأثير لهذه السياسة في هذا الإطار أيضًا في ذاكرة النواة.
  • إهدار مساحة القرص من خلال الحاجة إلى صورة تشغيل أكبر.
  • تؤثِّر المشكلة في أوقات البحث في سياسة بيئة التشغيل.

ويوضح المثال التالي جهازين حيث كانت الشركة المصنِّعة على 50% و40% من سياسة الجهاز. إعادة صياغة السياسة إلى إجراء تحسينات كبيرة في الأمان بدون خسارة في الوظائف، كما هو موضح أدناه. (يتم تضمين أجهزة AOSP مثل Shamu وFlounder للمقارنة بينهما).

الشكل 1: مقارنة بين حجم السياسة الخاصة بالجهاز بعد تدقيق الأمان.

الشكل 1. مقارنة خاصة بجهاز حجم السياسة بعد تدقيق الأمان.

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

منح إمكانية dac_override

يعني الرفض dac_override أنّ العملية المخالفة تتم محاولة الوصول إلى ملف بأذونات مستخدم/مجموعة/عالم غير صحيحة في نظام التشغيل Unix. يكمن الحل المناسب في عدم منح إذن dac_override في أغلب الأحيان. بدلاً من ذلك تغيير أذونات يونكس في الملف أو العملية هناك عدد قليل من النطاقات مثل init وvold وinstalld بحاجة حقًا القدرة على إلغاء أذونات ملفات يونكس للوصول إلى ملفات العمليات الأخرى. الاطّلاع على مدونة "دان والش" للحصول على شرح أكثر تفصيلاً