التوافق مع السياسات

توضّح هذه المقالة كيفية تعامل Android مع المشاكل المتعلّقة بتوافق السياسات. مع وكالات السفر على الإنترنت مع النظام الأساسي، حيث قد تختلف إعدادات SELinux للنظام الأساسي الجديد عن إعدادات المورِّد القديم إعدادات SELinux.

يعتبر تصميم سياسة SELinux المستندة إلى التريبلة تمييزًا ثنائيًا بين سياسة المنصّة والمورِّد يصبح المخطط أكثر تعقيدًا إذا كانت أقسام البائع تنشئ تبعيات، مثل platform < vendor < oem

في نظام Android 8.0 والإصدارات الأحدث، تنقسم سياسة SELinux العامة إلى سياسة خاصة والمكونات العامة. تتألف العناصر العامة من السياسة البنية الأساسية، والتي نضمن لك إتاحتها لإصدار النظام الأساسي. سيتم عرض هذه السياسة لكاتبي سياسات المورّدين لتمكين المورّدين من إنشاء ملف سياسة للمورّدين، والذي عند دمجه مع السياسة التي توفّرها المنصة، تؤدي إلى سياسة كاملة الوظائف لأحد الأجهزة.

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

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

ملكية العنصر وتصنيفه

عند تخصيص السياسة في الإصدار Android 8.0 والإصدارات الأحدث، يجب تحديد الملكية بوضوح لكل كائن لإبقاء النظام الأساسي وسياسة المورد منفصلة. على سبيل المثال، إذا تصنِّف المنصة التصنيف /dev/foo وتصنِّف النظام الأساسي /dev/foo في إعادة التوجيه عبر الهواء اللاحقة، سيحدث سلوك غير محدَّد. بالنسبة SELinux، ويظهر هذا على أنه تصادم تسمية. يمكن أن تحتوي عقدة الجهاز على تصنيف واحد يحلّ أي تصنيف يتم تطبيقه في الترتيب الأخير. نتيجة لذلك:

  • ستحتاج العمليات التي تحتاج إلى الوصول إلى التصنيف الذي لم يتم تطبيقه بنجاح يفقد إمكانية الوصول إلى المورد.
  • قد تتعطّل العمليات التي تكتسب إمكانية الوصول إلى الملف بسبب إدخال الخطأ تم إنشاء عقدة جهاز.

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

بالإضافة إلى تضارب التصنيفات، قد تتعارض أسماء الأنواع/السمات في SELinux أيضًا. سيؤدي تضارب النوع/اسم السمة دائمًا إلى خطأ في برنامج تجميع النهج.

تباعد أسماء السمات/النوع

لا تسمح SELinux بتعريفات متعددة من نفس النوع/السمة. السياسة التي تحتوي على تعريفات مكرّرة، سيتعذر تجميعها. لتجنب الكتابة تعارضات في اسم السمة، يجب أن يتم إدراج مساحات الاسم في كل بيانات الموردين بدءًا من vendor_. 

type foo, domain; → type vendor_foo, domain;

خاصية النظام و ملكية تصنيف العمليات

أفضل حل هو تجنب تضاربات العلامات باستخدام مساحات اسم الخاصية. إلى تحديد خصائص النظام الأساسي بسهولة وتجنُّب تعارض الأسماء عند إعادة التسمية أو إضافة خصائص النظام الأساسي التي تم تصديرها، والتأكّد من أنّ جميع خصائص المورّدين البادئات الخاصة:

نوع مكان الإقامة البادئات المقبولة
خصائص التحكّم ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
قابل للقراءة vendor.
القراءة فقط ro.vendor.
ro.boot.
ro.hardware.
مستمر persist.vendor.

يمكن للمورّدين مواصلة استخدام ro.boot.* (التي تأتي من النواة kernel. cmdline) وro.hardware.* (موقع واضح مرتبط بالأجهزة).

يجب أن تتضمّن كل خدمات المورّدين في ملفات init rc vendor.. للخدمات في ملفات init rc في الأقسام غير التابعة للنظام. القواعد المتشابهة هي تم تطبيقها على تصنيفات SELinux لخصائص المورد (vendor_) لخصائص البائع).

ملكية الملفات

يُعد منع التعارضات مع الملفات أمرًا صعبًا لأن المنصة والمورد كلاهما يوفر عادةً تصنيفات لجميع أنظمة الملفات. على عكس تسمية النوع، إلا أن وتيرة أسماء الملفات ليست عملية نظرًا لأن العديد منها تم إنشاؤها بواسطة النواة (النواة). لمنع هذا التضارب، اتبع إرشادات تسمية أنظمة الملفات في هذا القسم. بالنسبة إلى Android 8.0، هذه اقتراحات بدون دعم فني التنفيذ. في المستقبل، سيتم تطبيق هذه الاقتراحات من قِبل حزمة اختبار المورّد (VTS)

النظام (/system)

يجب أن توفّر صورة النظام فقط تصنيفات لمكوّنات /system. وحتى file_contexts وservice_contexts وما إلى ذلك. إذا كانت التصنيفات تتم إضافة /system عنصرًا في سياسة /vendor، قد لا يكون تحديث الهواء عبر الهواء المستند إلى إطار العمل فقط ممكنًا.

المورّد (/المورّد)

تصنِّف سياسة AOSP SELinux أجزاء قسم vendor حاليًا. يتفاعل النظام الأساسي معه، مما يمكّن كتابة قواعد SELinux للنظام الأساسي وهي العمليات التي تمكّنهم من التحدّث و/أو الوصول إلى أجزاء من vendor قسم القرص. أمثلة:

مسار واحد (/vendor) التصنيف الذي وفّره النظام الأساسي عمليات النظام الأساسي استنادًا إلى التصنيف
/vendor(/.*)? vendor_file جميع عملاء HAL في إطار العمل، ueventd وما إلى ذلك
/vendor/framework(/.*)? vendor_framework_file "dex2oat" و"appdomain" وغير ذلك
/vendor/app(/.*)? vendor_app_file "dex2oat" و"installd" و"idmap" وغير ذلك
/vendor/overlay(/.*) vendor_overlay_file "system_server" و"zygote" و"idmap" وغير ذلك

ونتيجة لذلك، يجب اتباع قواعد محددة (يتم فرضها من خلال neverallows) عند تصنيف ملفات إضافية في vendor التقسيم:

  • يجب أن يكون vendor_file هو التصنيف التلقائي لجميع الملفات في قسم vendor. وتتطلّب سياسة المنصة هذا الإذن للوصول إلى عمليات تطبيق HAL العبور.
  • تمت إضافة جميع exec_types الجديدة في القسم vendor. يجب أن يحتوي SEPolicy على المورد على السمة vendor_file_type. هذا النمط يتم فرضها من خلال nonallows.
  • لتجنُّب التضارب مع التحديثات المستقبلية للأنظمة الأساسية/الإطار، تجنَّب تصنيف المحتوى ملفات بخلاف exec_types في قسم vendor.
  • يجب أن تكون جميع تبعيات المكتبة لـ HALs للعملية نفسها التي يحددها AOSP يحمل التصنيف same_process_hal_file.

Procfs (/proc)

قد يتم تصنيف الملفات في /proc باستخدام genfscon فقط. التصنيف. في Android 7.0، المنصة والمورِّد استخدمت السياسة genfscon لتصنيف الملفات في procfs.

اقتراح: تصنيفات سياسات النظام الأساسي /proc فقط إذا كانت عمليات vendor بحاجة إلى الوصول إلى الملفات في /proc، تحمل التصنيف التلقائي (proc) حاليًا، وهي سياسة البائع لا ينبغي تصنيفها بشكل واضح، وبدلاً من ذلك تستخدم التصنيف النوع proc لإضافة قواعد لنطاقات المورّدين. يتيح ذلك للمنصة لاستيعاب واجهات kernel المستقبلية مكشوفة من خلال procfs وصنِّفها بشكل واضح حسب الحاجة.

تصحيح الأخطاء (/sys/kernel/debug)

يمكن تصنيف Debugfs في كل من file_contexts genfscon في Android 7.0 إلى Android 10، تصنيف كلٍّ من النظام الأساسي والمورّد debugfs

في Android 11، لا يمكن استخدام debugfs يتم الوصول إليها أو تثبيتها على أجهزة الإنتاج. ينبغي على الشركات المصنعة للأجهزة إزالة debugfs

آثار الأنشطة (/sys/kernel/debug/tracing)

يمكن تصنيف Tracefs في كل من file_contexts genfscon وفي Android 7.0، تتضمن تصنيفات النظام الأساسي فقط tracefs

اقتراح: يحق للمنصّة فقط تصنيف tracefs.

نظام Sysfs (/sys)

قد يتم تصنيف الملفات في /sys باستخدام كل من file_contexts. وgenfscon. في Android 7.0، يستخدم كل من النظام الأساسي والمورد file_contexts وgenfscon لتصنيف الملفات في sysfs

اقتراح: قد تصنِّف المنصة التصنيف sysfs. عُقد غير خاصة بالجهاز. بخلاف ذلك، يمكن للمورِّد فقط تصنيف الملفات.

tmpfs (/dev)

قد يتم تصنيف الملفات في /dev باستخدام file_contexts. ضِمن الإصدار 7.0 من نظام التشغيل Android، ملفات تصنيفات كلٍّ من النظام الأساسي والمورد هنا.

اقتراح: يمكن للمورّد تصنيف الملفات فقط في /dev/vendor (مثال: /dev/vendor/foo, /dev/vendor/socket/bar).

ملفات Rootfs (/)

قد يتم تصنيف الملفات في / باستخدام file_contexts. في Android 7.0، لكل من ملفات تصنيف النظام الأساسي والمورد هنا.

اقتراح: يمكن للنظام فقط تصنيف الملفات في /.

البيانات (/data)

يتم تصنيف البيانات من خلال مجموعة من file_contexts seapp_contexts

اقتراح: عدم السماح بتصنيف المورّدين من خارج /data/vendor يمكن فقط لمنصة المنصة تصنيف الأجزاء الأخرى من /data

سمات التوافق

سياسة SELinux هي عبارة عن تفاعل بين نوعي المصدر والهدف لأنواع محددة وفئات الكائنات والأذونات. جميع العناصر المتأثرة (العمليات والملفات وغيرها) سياسة SELinux على نوع واحد فقط، ولكن قد يكون لهذا النوع عدة أنواع ذات الصلة.

تمت كتابة السياسة في الغالب وفقًا للأنواع الحالية: 

allow source_type target_type:target_class permission(s);

ويتلاءم هذا الإجراء لأنّ السياسة مكتوبة على دراية بجميع أنواعها. ومع ذلك، إذا كانت سياسة البائعين وسياسة النظام الأساسي تستخدم أنواعًا محددة، وتصنيف تغييرات كائن محددة في واحدة من تلك السياسات فقط، فقد تحتوي الأخرى على التي اكتسبت أو فقدت إمكانية الوصول التي كان يعتمد عليها سابقًا. مثلاً: 

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

يمكن تغييرها إلى: 

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

ولن تتغيّر سياسة المورّدين، إلّا أنّ v_domain سيفقد إمكانية الوصول إلى sysfs_A بسبب عدم توفُّر سياسة الكتابة.

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

تعريف السياسة العامة بوصفها سمات ذات نُسخ طبق الأصل يفي بسياستين أهداف التوافق:

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

قابلية كتابة السياسات

لتحقيق الهدف المتمثل في عدم طلب معرفة تغييرات الإصدار المحددة تطوير السياسة، فإن Android 8.0 يتضمن تعيينًا بين النظام الأساسي العام وأنواع السياسات وسماتها تم ربط النوع foo. إلى السمة foo_vN، حيث يشير N إلى استهداف إصدار معيّن. vN يتجاوب مع متغير إصدار PLATFORM_SEPOLICY_VERSION وهو بالشكل MM.NN، حيث يتوافق MM مع رقم حزمة تطوير البرامج (SDK) للنظام الأساسي وNN هو إصدار خاص بسياسة الخصوصية على مستوى المنصة.

لم يتم تحديد إصدارات للسمات في السياسة العامة، ولكنها موجودة كواجهة برمجة تطبيقات على سياسة النظام الأساسي والمورد التي يمكن إنشاؤها للحفاظ على الواجهة بين الاثنين الأقسام الثابتة. يمكن لكل من كاتبي سياسات المنصات والموردين مواصلة كتابة وسياسة كما هي مكتوبة اليوم.

ويتم تضمين السياسة العامة للمنصات التي يتم تصديرها باسم allow source_foo target_bar:class perm; كجزء من سياسة المورّدين. خلال Compilation (التي تتضمن المقابلة) يتم تحويلها إلى السياسة التي ستنقل إلى الجزء الخاص بالمورِّد من الجهاز (كما هو موضح في متوسط مشترك تم تحويله اللغة (CIL): 

 (allow source_foo_vN target_bar_vN (class (perm)))

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

اختلافات السياسات

إنشاء السمات تلقائيًا عن طريق إضافة _vN إلى النهاية من كل نوع لا يفعل أي شيء دون تعيين السمات للأنواع عبر الإصدار الاختلافات. يحافظ Android على عملية تعيين بين إصدارات السمات تعيين الأنواع لتلك التصنيفات. يتم ذلك في عملية التخطيط المذكورة أعلاه الملفات التي تحتوي على عبارات مثل (CIL): 

(typeattributeset foo_vN (foo))

ترقيات النظام الأساسي

يوضّح القسم التالي تفاصيل السيناريوهات المتعلقة بترقيات الأنظمة الأساسية.

الأنواع نفسها

يحدث هذا السيناريو عندما لا يغيّر العنصر التصنيفات في إصدارات السياسات. ينطبق ذلك على أنواع المصادر والأهداف، ويمكن ملاحظته باستخدام /dev/binder، الذي يحمل التصنيف binder_device على مستوى جميع والإصدارات. ويتم تمثيلها في السياسة المعدَّلة على النحو التالي: 

binder_device_v1 … binder_device_vN

عند الترقية من v1 ← v2، يجب أن تسري سياسة النظام الأساسي على تحتوي على: 

type binder_device; -> (type binder_device) (in CIL)

في ملف الربط v1 (CIL): 

(typeattributeset binder_device_v1 (binder_device))

في ملف الربط للإصدار 2 (CIL): 

(typeattributeset binder_device_v2 (binder_device))

في سياسة المورِّدين للإصدار 1 (CIL): 

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

في الإصدار 2 من سياسة المورّدين (CIL): 

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
الأنواع الجديدة

يحدث هذا السيناريو عندما تضيف المنصة نوعًا جديدًا، وقد يحدث هذا عند إضافة ميزات جديدة أو أثناء تعزيز السياسات

  • ميزة جديدة: عندما يقوم النوع بتسمية كائن كان وهي غير موجودة سابقًا (مثل عملية خدمة جديدة)، فإن رمز البائع أن يتفاعلوا معه مباشرةً في وقت سابق بحيث لا تتوفر سياسة مقابلة. لا تتضمن السمة المطابقة للنوع سمة في السابق وبالتالي لن تحتاج إلى إدخال في استهداف ملف الربط الذي .
  • تشديد السياسات: عندما يمثّل النوع السياسة فإن تصنيف النوع الجديد يجب أن يرتبط بسلسلة من السمات مطابق للمثال السابق (على غرار المثال السابق المتغير /sys/A من sysfs إلى sysfs_A). المورّد الرمز البرمجي يعتمد على قاعدة تتيح الوصول إلى sysfs، ويحتاج إلى لتضمين تلك القاعدة كسمة للنوع الجديد.

عند الترقية من v1 ← v2، يجب أن تسري سياسة النظام الأساسي على تحتوي على: 

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

في ملف الربط v1 (CIL): 

(typeattributeset sysfs_v1 (sysfs sysfs_A))

في ملف الربط للإصدار 2 (CIL): 

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

في سياسة المورِّدين للإصدار 1 (CIL): 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

في الإصدار 2 من سياسة المورّدين (CIL): 

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
الأنواع التي تمت إزالتها

يحدث هذا السيناريو (النادر) عند إزالة نوع، وهو ما قد يحدث عندما الكائن الأساسي:

  • يبقى ولكن يحصل على تصنيف مختلف.
  • إذا تمّت إزالته بواسطة المنصة

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

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

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

مثال على الإصدار 1: أنواع الجداول القابلة للتصغير (إزالة sysfs_A)

عند الترقية من v1 ← v2، يجب أن تسري سياسة النظام الأساسي على تحتوي على: 

type sysfs; (type sysfs) (in CIL)

في ملف الربط v1 (CIL): 

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

في ملف الربط للإصدار 2 (CIL): 

(typeattributeset sysfs_v2 (sysfs))

في سياسة المورِّدين للإصدار 1 (CIL): 

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

في الإصدار 2 من سياسة المورّدين (CIL): 

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

مثال على الإصدار 2: الإزالة نهائيًا (نوع foo)

عند الترقية من v1 ← v2، يجب أن تسري سياسة النظام الأساسي على تحتوي على: 

# nothing - we got rid of the type

في ملف الربط v1 (CIL): 

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

في ملف الربط للإصدار 2 (CIL): 

# nothing - get rid of it

في سياسة المورِّدين للإصدار 1 (CIL): 

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

في الإصدار 2 من سياسة المورّدين (CIL): 

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
فئة/أذونات جديدة

يحدث هذا السيناريو عندما تطرح ترقية النظام الأساسي مكونات جديدة للسياسة التي لا توجد في الإصدارات السابقة. على سبيل المثال، عندما أضاف Android مدير عناصر "servicemanager" الذي أنشأ الإضافة والبحث والقائمة أو برامج خفية للبائعين تريد التسجيل باستخدام كان يجب منح servicemanager أذونات لم يتم إجراؤها المتوفرة. في Android 8.0، لا يجوز إضافة فئات جديدة الأذونات.

السماح بجميع النطاقات التي كان من الممكن إنشاؤها أو توسيعها بواسطة سياسة المورِّد لاستخدام الفئة الجديدة بدون عوائق، يجب أن تتضمن سياسة النظام الأساسي قاعدة مشابهة لـ: 

allow {domain -coredomain} *:new_class perm;

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

الصف/الأذونات التي تمت إزالتها

يحدث هذا السيناريو عند إزالة مدير عناصر (مثل مدير عناصر ZygoteConnection) ومن المفترض ألا تتسبب في أي مشاكل. تشير رسالة الأشكال البيانية يمكن أن تظل فئة مدير الكائنات والأذونات محددة في السياسة حتى لم يعد يستخدمه الإصدار. يتم ذلك عن طريق إضافة التعريفات إلى ملف التعيين المقابل.

تخصيص البائعين من أجل الأنواع الجديدة/التي تمت إعادة تصنيفها

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

نظرًا لأن سياسة البائع هي دائمًا الأقدم على الجهاز، ما مِن حاجة إلى يتم تلقائيًا تحويل جميع أنواع المورّدين إلى سمات في السياسة. النظام الأساسي لا تعتمد على أي عنصر مصنف في سياسة المورد لأن المنصة لا تحتوي معرفتها؛ ستوفّر المنصة السمات والبيانات التي تستخدمها للتفاعل مع الكائنات المصنفة بهذه الأنواع (مثل domain أو sysfs_type أو غير ذلك). بالنسبة إلى المنصة التفاعل بشكل صحيح مع هذه الكائنات، والسمات والأنواع أن يتم تطبيقها بشكل مناسب وقد يلزم إضافة قواعد محددة إلى النطاقات القابلة للتخصيص (مثل init).

التغييرات في السمات لنظام Android 9

يمكن للأجهزة التي تتم ترقيتها إلى Android 9 استخدام السمات التالية، ولكن الأجهزة مع Android 9 في جميع الأحوال.

سمات المستخدمين المخالِفين

يتضمّن Android 9 السمات التالية المتعلقة بالنطاق:

  • data_between_core_and_vendor_violators سمة لجميع النطاقات التي تنتهك مطلب عدم مشاركة الملفات عن طريق بين vendor وcoredomains. النظام الأساسي عمليات المورِّد ملفات على القرص للتواصل (واجهة ABI غير مستقرة). اقتراح:
    • يجب أن يستخدم رمز المورّد السمة /data/vendor.
    • يجب ألا يستخدم النظام /data/vendor.
  • system_executes_vendor_violators السمة لجميع نطاقات النظام (باستثناء init وshell domains) تنتهك متطلبات عدم تنفيذ البرامج الثنائية للمورّدين. تنفيذ تحتوي البرامج الثنائية للبائع على واجهة برمجة تطبيقات غير مستقرة. يجب ألا ينفذ النظام الأساسي البرامج الثنائية للمورد مباشرةً. اقتراح:
    • يجب أن تكون تبعيات النظام الأساسي على البرامج الثنائية للموردين وراء HIDL HALs.

      أو

    • يجب تنفيذ الإجراءات التالية على coredomains التي تحتاج إلى الوصول إلى البرامج الثنائية للمورّدين. إلى قسم المورد ومن ثم يتوقف عن العمل coredomain.

سمات غير موثوق بها

يجب ألّا تتمكّن التطبيقات غير الموثوق بها التي تستضيف رموزًا عشوائية من الوصول إلى HwBinder. باستثناء تلك التي تُعتبر آمنة بما يكفي للوصول إليها من هذه التطبيقات (اطّلِع على الخدمات الآمنة أدناه). وفي ما يلي السببان الرئيسيان لذلك:

  1. لا تُجري خوادم HwBinder مصادقة العميل لأنّ HIDL حاليًا. لا يعرض معلومات المعرّف الفريد (UID) للمتصل. حتى لو كشف HIDL هذه البيانات، فإن العديد من تعمل خدمات HwBinder إما على مستوى أقل من مستوى التطبيقات (مثل HALs). يجب ألا تعتمد على هوية التطبيق للحصول على التفويض. وبالتالي، للحفاظ على الأمان، يجب أن يكون افتراض أن كل خدمة من خدمات HwBinder تعامل جميع عملائها بالتساوي مخول لأداء العمليات التي تقدمها الخدمة.
  2. تحتوي خوادم HAL (مجموعة فرعية من خدمات HwBinder) على رمز يحتوي على معدّل حدوث مشاكل الأمان مقارنةً بـ system/core عنصرًا من الوصول إلى الطبقات السفلية من المكدس (وصولاً إلى الأجهزة) ومن ثم زيادة فرص تجاوز نموذج أمان Android.

خدمات آمنة

تشمل الخدمات الآمنة ما يلي:

  • same_process_hwservice يتم تشغيل هذه الخدمات (حسب التعريف) في عملية العميل وبالتالي يكون له نفس الوصول الذي يتمتع به نطاق العميل في أثناء تشغيل العملية.
  • coredomain_hwservice لا تشكِّل هذه الخدمات مخاطر المرتبطة بالسبب رقم 2.
  • hal_configstore_ISurfaceFlingerConfigs هذه الخدمة تم تصميمه خصيصًا للاستخدام من خلال أي نطاق.
  • hal_graphics_allocator_hwservice تتم أيضًا هذه العمليات مقدَّمة من خدمة Binder surfaceflinger، وهي التطبيقات المسموح بها الوصول إليه.
  • hal_omx_hwservice هذا إصدار من HwBinder من mediacodec خدمة Binder، التطبيقات المسموح لها بالوصول إليها.
  • hal_codec2_hwservice هذا إصدار أحدث من hal_omx_hwservice

السمات القابلة للاستخدام

تتضمّن جميع hwservices التي لا تُعتبر آمنة السمة. untrusted_app_visible_hwservice تحتوي خوادم HAL المقابلة على السمة untrusted_app_visible_halserver. إطلاق الأجهزة مع Android 9، يجب ألا يستخدم أي منهما untrusted.

اقتراح:

  • وبدلاً من ذلك، يجب أن تتواصل التطبيقات غير الموثوق بها مع إحدى خدمات النظام التي تتواصل مع البائع HIDL HAL. على سبيل المثال، يمكن للتطبيقات التحدّث إلى binderservicedomain، ثم mediaserver (وهو binderservicedomain) يتحدث بدوره إلى hal_graphics_allocator.

    أو

  • يجب أن تحصل التطبيقات التي تحتاج إلى إمكانية الوصول المباشر إلى vendor HALs على ما يلي: نطاق سياسة سياسة محددة يحدده المورّد.

اختبارات سمات الملفات

يشمل نظام Android 9 اختبارات وقت الإصدار لضمان دقّة جميع الملفات في مواقع لها السمات المناسبة (مثل أن جميع الملفات في sysfs تتضمّن السمة sysfs_type المطلوبة).

السياسة العامة للمنصة

تُعدّ السياسة العامة بين النظام الأساسي ركيزة أساسية للتوافق مع Android 8.0 هندسة معمارية بدون الاكتفاء بالحفاظ على توحيد سياسات المنصة من v1 وv2 يخضع المورّدون لمجموعة فرعية من سياسة النظام الأساسي يحتوي على أنواع وسمات قابلة للاستخدام وقواعد على هذه الأنواع والسمات والتي تصبح بعد ذلك جزءًا من سياسة البائعين (أي vendor_sepolicy.cil).

تتم ترجمة الأنواع والقواعد تلقائيًا إلى السياسة التي ينشئها المورّد. إلى attribute_vN بحيث تكون كل الأنواع التي توفّرها المنصة تعتبر سمات ذات نُسخ مختلفة (ومع ذلك ليس هناك إصدارات من السمات). المنصة عبارة عن مسئولاً عن وضع أنواع الخرسانة التي توفرها في الأنواع المناسبة لضمان استمرار عمل سياسة البائعين، وأنّ القواعد المقدمة لإصدار معين. مزيج من السياسة العامة بين النظام الأساسي وسياسة البائعين تتوافق مع بنية Android 8.0 ونموذج الهدف المتمثل في السماح بإنشاء منصات ومورِّدين مستقلين.

تعيين سلاسل السمات

عند استخدام سمات للتعيين إلى إصدارات السياسة، يتم ربط نوع بسمة أو سمات متعددة، لضمان إمكانية الوصول إلى الكائنات المصنفة بالنوع من خلال المناسبة لأنواعها السابقة.

يعني وضع هدف لإخفاء معلومات النسخة عن كاتب السياسة إنشاء السمات ذات الإصدارات وتعيينها إلى والأنواع المناسبة. في الحالة الشائعة للأنواع الثابتة، يكون الأمر واضحًا: ربط type_foo بـ type_foo_v1.

بالنسبة إلى تغيير تصنيف عنصر، مثل sysfs ← sysfs_A أو mediaserver ← audioserver، جارٍ إنشاء عملية الربط هذه غير تافه (وهو موصوف في الأمثلة أعلاه). مسؤولو الحفاظ على سياسات النظام الأساسي تحديد كيفية إنشاء التعيين عند نقاط الانتقال للكائنات، والتي فهم العلاقة بين الكائنات والعناصر المخصصة لها المحددة وتحديد وقت حدوث ذلك. للتوافق مع الأنظمة القديمة، ينبغي إدارة التعقيدات على جانب النظام الأساسي، وهو القسم الوحيد التي قد ترتفع.

عمليات تحسين الإصدار

للتبسيط، يُصدِر نظام Android الأساسي إصدار سياسة sepolicy عندما يتم إصدار يتم قص فرع الإصدار. وكما هو موضح أعلاه، يوجد رقم الإصدار في PLATFORM_SEPOLICY_VERSION وتكون بالصيغة MM.nn، حيث تتجاوب MM مع قيمة حزمة SDK وnn هي تم الاحتفاظ بقيمة خاصة في /platform/system/sepolicy. على سبيل المثال، 19.0 for Kitkat، و21.0 for Lollipop، 22.0 لـ Lollipop-MR1 23.0 لنظام Marshmallow، 24.0 لـ Nougat، و25.0 لـ Nougat-MR1، 26.0 لـ Oreo، و27.0 لـ Oreo-MR1، 28.0 لنظام التشغيل Android 9. لا تكون الارتفاعات دائمًا أعدادًا صحيحة. بالنسبة على سبيل المثال، إذا كان ارتطام MR بإصدارات ما يستلزم تغيير غير متوافق في system/sepolicy/public ولكن ليس خطأ في واجهة برمجة التطبيقات، إذن هذه السياسة يمكن أن تكون النسخة: vN.1. هذا الإصدار موجود في مرحلة التطوير الفرع الخاص بـ 10000.0 هو جهاز لا يتم استخدامه مطلقًا في الشحن.

قد يوقف نظام Android الإصدار الأقدم نهائيًا عند الترقية. لإدخال معلومات حول الوقت إيقاف إصدار نهائيًا، فقد يجمع نظام Android عدد الأجهزة التي يتوفر لديها التي تستخدم إصدار Android هذا ولا تزال تتلقى نظامًا أساسيًا رئيسيًا التحديثات. وإذا كان الرقم أقل من حد معين، فإن هذا الإصدار نهائيًا.

تأثير أداء سمات متعددة

كما هو موضّح في https://github.com/SELinuxProject/cil/issues/9، يؤدي عدد كبير من السمات المعينة إلى نوع إلى حدوث مشكلات في الأداء في في حالة عدم وجود ذاكرة تخزين مؤقت للسياسة.

تم التأكّد من أنّ هذه المشكلة هي في نظام Android، لذا سيتم إجراء تغييرات. إلى الإصدار 8.0 من نظام التشغيل Android لإزالة السمات التي تمت إضافتها إلى السياسة من قِبل برنامج تجميع السياسات، بالإضافة إلى إزالة السمات غير المستخدمة. تم حلّ هذه التغييرات. تراجع الأداء.

السياسة العامة والسياسة العامة للمنتج System_ext

بدءًا من نظام التشغيل Android 11، سيتم السماح بأجزاء نظام التشغيل (system_ext) وقسم "المنتج" تصدير الأنواع العامة المخصصة لها إلى قسم البائع. مثل المنصة يستخدم البائع الأنواع والقواعد المترجمة تلقائيًا إلى السياسة العامة، بإصدارات محددة، مثل من type إلى type_N، حيث N هو الإصدار للنظام الأساسي الذي تم إنشاء قسم البائع وفقًا له.

عندما تستند أقسام النظام (system_ext) وقسم "المنتج" إلى إصدار النظام الأساسي نفسه N، ينشئ نظام التصميم ملفات تعيين أساسية system_ext/etc/selinux/mapping/N.cil و product/etc/selinux/mapping/N.cil، التي تحتوي على الهوية التعيينات من type إلى type_N. يمكن للبائع يمكن الوصول إلى type باستخدام السمة ذات الإصدارات type_N.

وفي حال لم يتم تحديث سوى system_ext وقسم المنتج، لنفترض من N إلى N+1 (أو لاحقًا)، بينما بقاء المورّد في N، قد يفقد المورّد إمكانية الوصول إلى أنواع System_ext وأقسام المنتج. لمنع الكسر، يجب يجب أن توفر أقسام System_ext والمنتج ملفات تعيين من أنواعها إلى سمات type_N. يتميز كل شريك مسئولاً عن الحفاظ على ملفات التعيين، إذا كانت ستدعم مورّد واحد (N) لديه N+1 (أو إصدار أحدث) system_ext وأقسام المنتج.

لتحقيق هذا الهدف، على الشركاء تنفيذ ما يلي:

  1. نسخ ملفات الربط الأساسية التي تم إنشاؤها من N System_ext وأقسام المنتج إلى شجرة المصادر
  2. تعديل ملفات الربط حسب الحاجة:
  3. تثبيت ملفات الربط إلى N+1 (أو إصدار أحدث) system_ext و أقسام المنتج.

على سبيل المثال، لنفترض أنّ هناك N system_ext لها قائمة علنية واحدة النوع باسم foo_type. ثم system_ext/etc/selinux/mapping/N.cil في القسم N System_ext على النحو التالي: 

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

في حال إضافة الدالة bar_type إلى N+1 system_ext إذا كان يجب تعيين bar_type إلى foo_type من أجل مورِّد N، يمكن تعديل N.cil من 

(typeattributeset foo_type_N (foo_type))

إلى 

(typeattributeset foo_type_N (foo_type bar_type))

ثم تثبيتها في قسم N+1 system_ext. يمكن لمورّد واحد (N) مواصلة الوصول إلى N+1. foo_type وbar_type لـ system_ext.

تصنيف سياقات SELinux

لدعم التمييز بين سياسة النظام الأساسي والمورّد، ينشئ النظام ملفات سياق SELinux بشكل مختلف لإبقائها منفصلة.

سياقات الملفات

أجرى Android 8.0 التغييرات التالية على file_contexts:

  • لتجنُّب استخدام أعباء تجميع إضافية على الجهاز أثناء التشغيل، لم يعد file_contexts متاحًا في النموذج الثنائي. بدلاً من ذلك، ملف نصي وقابل للقراءة وتعبير عادي مثل {property, service}_contexts (كما كان الإصدار قبل 7.0).
  • يتم تقسيم file_contexts بين ملفَّين:
    • plat_file_contexts
      • نظام Android الأساسي file_context الذي لا يتضمن الخاصة بالجهاز، باستثناء تصنيف أجزاء من قسم /vendor الذي يجب تسميته بدقة لضمان الأداء السليم لملفات sepolicy.
      • يجب أن تكون مقيمًا في قسم system في /system/etc/selinux/plat_file_contexts على الجهاز سيتم تحميله بواسطة init في البداية إلى جانب البائع file_context.
    • vendor_file_contexts
      • تم تصميم "file_context" الخاص بالجهاز من خلال الجمع بين تم العثور على file_contexts في الأدلة المشار إليها بواسطة BOARD_SEPOLICY_DIRS في الجهاز Boardconfig.mk ملف.
      • يجب التثبيت في /vendor/etc/selinux/vendor_file_contexts بوصة قسم vendor وسيتم تحميله من خلال init عند البداية جنبًا إلى جنب مع المنصة file_context.

سياقات الموقع

في الإصدار Android 8.0، يتم تقسيم property_contexts بين ملفَّين:

  • plat_property_contexts
    • نظام Android الأساسي property_context الذي لا يتضمن التصنيفات الخاصة بالأجهزة.
    • يجب أن تكون مقيمًا في قسم system في /system/etc/selinux/plat_property_contexts وسيتم تحميلها بواسطة init في البداية مع البائع property_contexts
  • vendor_property_contexts
    • تم تصميم "property_context" الخاص بالجهاز من خلال الجمع بين تم العثور على property_contexts في الأدلة المشار إليها بواسطة BOARD_SEPOLICY_DIRS في الجهاز Boardconfig.mk ملف.
    • يجب أن تكون مقيمًا في قسم vendor في /vendor/etc/selinux/vendor_property_contexts وسيكون تم تحميله من قِبل init في البداية إلى جانب المنصة property_context

سياقات الخدمة

في الإصدار Android 8.0، يتم تقسيم service_contexts بين ما يلي: الملفات:

  • plat_service_contexts
    • service_context الخاص بنظام Android الأساسي servicemanager لا تتضمن service_context التصنيفات الخاصة بالأجهزة.
    • يجب أن تكون مقيمًا في قسم system في /system/etc/selinux/plat_service_contexts وسيتم التحميل بحلول servicemanager في البداية مع البائع service_contexts
  • vendor_service_contexts
    • تم تصميم "service_context" الخاص بالجهاز من خلال الجمع بين تم العثور على service_contexts في الأدلة المشار إليها بواسطة BOARD_SEPOLICY_DIRS في الجهاز Boardconfig.mk ملف.
    • يجب أن تكون مقيمًا في قسم vendor في /vendor/etc/selinux/vendor_service_contexts وسيتم تحميلها بواسطة servicemanager في بداية الفيديو إلى جانب المنصة service_contexts
    • على الرغم من أنّ servicemanager يبحث عن هذا الملف في وقت التشغيل، لجهاز TREBLE متوافق بالكامل، يجب ألا يكون "vendor_service_contexts" موجودًا. هذا بسبب كل التفاعلات بين vendor وsystem العمليات يجب أن تمر عبر hwservicemanager/hwbinder
  • plat_hwservice_contexts
    • نظام Android الأساسي hwservice_context لـ hwservicemanager الذي لا يتضمن أي تصنيفات خاصة بالجهاز.
    • يجب أن تكون مقيمًا في قسم system في /system/etc/selinux/plat_hwservice_contexts وسيتم التحميل بحلول hwservicemanager في البداية مع vendor_hwservice_contexts
  • vendor_hwservice_contexts
    • تم تصميم "hwservice_context" الخاص بالجهاز من خلال الجمع بين تم العثور على hwservice_contexts في الأدلة المشار إليها بواسطة BOARD_SEPOLICY_DIRS في الجهاز Boardconfig.mk ملف.
    • يجب أن تكون مقيمًا في قسم vendor في /vendor/etc/selinux/vendor_hwservice_contexts وسيكون تم تحميله بواسطة hwservicemanager في البداية إلى جانب plat_service_contexts
  • vndservice_contexts
    • service_context الخاص بالجهاز تم إنشاء vndservicemanager من خلال الجمع بين تم العثور على vndservice_contexts في الأدلة المشار إليها بواسطة BOARD_SEPOLICY_DIRS في الجهاز Boardconfig.mk
    • يجب أن يكون هذا الملف موجودًا في قسم vendor على /vendor/etc/selinux/vndservice_contexts وسيتم التحميل بحلول vndservicemanager في البداية.

سياقات Seapp

في الإصدار Android 8.0، يتم تقسيم seapp_contexts بين ملفَّين:

  • plat_seapp_contexts
    • نظام Android الأساسي seapp_context الذي لا يتضمن التغييرات.
    • يجب أن تكون مقيمًا في قسم system في /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • تم إنشاء إضافة خاصة بالجهاز للنظام الأساسي seapp_context من خلال دمج seapp_contexts في الأدلّة الذي أشار إليه BOARD_SEPOLICY_DIRS في قسم Boardconfig.mk ملف.
    • يجب أن تكون مقيمًا في قسم vendor في /vendor/etc/selinux/vendor_seapp_contexts

أذونات MAC

في الإصدار Android 8.0، يتم تقسيم mac_permissions.xml بين ملفَّين:

  • الرصيف mac_permissions.xml
    • نظام Android الأساسي mac_permissions.xml الذي لا يتضمن التغييرات الخاصة بالجهاز.
    • يجب أن تكون مقيمًا في قسم system في /system/etc/selinux/.
  • mac_permissions.xml غير تابع للمنصة
    • إضافة خاصة بالجهاز إلى النظام الأساسي mac_permissions.xml من إنشاء تم العثور على mac_permissions.xml في الأدلة المُشار إليها بواسطة BOARD_SEPOLICY_DIRS في الجهاز Boardconfig.mk ملف.
    • يجب أن تكون مقيمًا في قسم vendor في /vendor/etc/selinux/.