لدى عملية البدء أذونات غير مقيدة تقريبًا وتستخدم نصوصًا برمجية للإدخال من كل من أقسام النظام والمورد لتهيئة النظام أثناء بدء التشغيل الدفع. ويسبب هذا الوصول فجوة كبيرة في تقسيم نظام التريبل/المورِّد، حيث النصوص البرمجية للمورد إرشاده للوصول إلى الملفات والخصائص وغيرها التي لا تشكل جزءًا من الواجهة الثنائية لتطبيق مورّد النظام الثابت (ABI).
تم تصميم الإطار الخاص بالمورّد لإغلاق هذه الفتحة باستخدام
نطاق vendor_init لنظام التشغيل Linux (SELinux) المحسّن للأمان لتشغيله
في /vendor بأذونات خاصة بالمورِّد.
الآلية
يقوم المورّد بإنشاء عملية فرعية من init في وقت مبكر من عملية التمهيد باستخدام
سياق SELinux u:r:vendor_init:s0. يحتوي سياق SELinux هذا على
أقل بكثير من سياق البدء الافتراضي، كما أن إمكانية الوصول إليه
التي تقتصر على الملفات والخصائص وغيرها من الملفات الخاصة بالمورد أو جزء من
واجهة التطبيق الثنائية (ABI) التي تعتمد على نظام مستقر.
يتحقق Init من كل نص برمجي يحمِّله لمعرفة ما إذا كان مساره يبدأ
/vendor، وإذا كان الأمر كذلك، عليك الإشارة إليه مع الإشارة إلى أنّ أوامره
أن يتم تشغيله في سياق الإعداد الخاص بالمورّد. يتم التعليق على كل إعداد مدمج
قيمة منطقية تحدد ما إذا كان يجب تشغيل الأمر في ملف init الخاص بالمورّد
المعالجة الفرعية:
- تتم إضافة تعليقات توضيحية لمعظم الأوامر التي تصل إلى نظام الملفات لتشغيلها في المورد في عملية init الفرعية ومن ثم تخضع لسياسة SEPolicy في المورد.
- معظم الأوامر التي تؤثر في حالة الإعداد الداخلي (مثل البدء والإيقاف) الخدمات) ضمن عملية البدء العادية. يتم إنشاء هذه الأوامر أن هناك نصًا برمجيًا للمورد يطلب منهم إجراء عمليات خاصة بهم بخلاف SELinux التعامل مع الأذونات.
تحتوي حلقة المعالجة الرئيسية في init على تحقق من وجود تعليق توضيحي للأمر أن يتم تشغيله في العملية الفرعية للمورّد وينشأ من النص البرمجي للمورّد، والذي يتم إرسال الأمر عن طريق الاتصال بين العمليات (IPC) إلى تهيئة البائع عملية فرعية، تقوم بتشغيل الأمر وترسل النتيجة مرة أخرى إلى init.
استخدام Init للمورّد
يتم تفعيل init للمورّد تلقائيًا وتنطبق قيوده على جميع النصوص البرمجية init
حاليًا في قسم /vendor. يجب أن يتحلى المورّد بالشفافية
إلى البائعين الذين لا تصل نصوصهم البرمجية بالفعل إلى ملفات النظام فقط،
والخصائص وغيرها.
ومع ذلك، إذا انتهكت أوامر في نص برمجي معين للمورد إعداد القيود، فستفشل الأوامر. تحتوي الأوامر التي لم يتم اجتيازها على سطر في النواة kernel سجل (مرئي باستخدام dmesg) من init يشير إلى الفشل. تدقيق SELinux يصاحب أي أمر فاشل فشل بسبب سياسة SELinux. مثال أي فشل، بما في ذلك تدقيق SELinux:
type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission denied
إذا فشل الأمر، فهناك خياران:
- فإذا فشل الأمر بسبب قيد مقصود (على سبيل المثال إذا كان هناك يصل الأمر إلى ملف نظام أو خاصية)، يجب نقل الأمر إعادة تنفيذه بطريقة تتوافق مع الوضع الثلاثي الأبعاد، من خلال واجهات ثابتة فقط. عدم السماح بالقواعد تمنع إضافة أذونات للوصول إلى ملفات النظام غير المسموح بها جزءًا من واجهة التطبيق الثنائية (ABI) التي تعتمد على نظام مستقر.
- إذا كانت تصنيف SELinux جديدًا ولم يتم منحه أذونات بالفعل في
النظام
vendor_init.teأو أذونات مستبعدة من خلال عدم السماح مطلقًا قواعد، قد يتم منح التصنيف الجديد أذونات في العمليات الخاصة بالجهازvendor_init.te
بالنسبة إلى الأجهزة التي سيتم إطلاقها قبل نظام التشغيل Android 9، قد يتم تجاوز قواعد الحدّ الأقصى لهذه القاعدة من خلال
إضافة سمة النوع data_between_core_and_vendor_violators إلى
ملف vendor_init.te الخاص بالجهاز
مواقع الرموز
يكمن الجزء الأكبر من منطق IPC في تهيئة المورِّد في system/core/init/subcontext.cpp.
يتوفّر جدول الأوامر في الفئة BuiltinFunctionMap ضمن system/core/init/builtins.cpp.
وتشمل تعليقات توضيحية تشير إلى ما إذا كان يجب تشغيل الأمر في المورد
لبدء العملية الفرعية.
يتم تقسيم SEPolicy لـ "المورِّد" (init) على الخاص (system/sepolicy/private/vendor_init.te) والعلني (system/sepolicy/public/vendor_init.te) في System/sepolicy.