تلتزم Google بتعزيز المساواة العرقية للمجتمعات السوداء. أنظر كيف.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

تخصيص SELinux

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

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

عند الشروع في تخصيص SELinux ، تذكر ما يلي:

  • كتابة سياسة SELinux لجميع الشياطين الجديدة
  • استخدم المجالات المحددة مسبقًا كلما كان ذلك مناسبًا
  • قم بتعيين نطاق لأي عملية init كخدمة init
  • تعرف على وحدات الماكرو قبل كتابة السياسة
  • إرسال التغييرات على السياسة الأساسية إلى AOSP

وتذكر عدم القيام بما يلي:

  • إنشاء سياسة غير متوافقة
  • السماح بتخصيص سياسة المستخدم النهائي
  • السماح بتخصيصات سياسة MDM
  • تخويف المستخدمين من انتهاكات السياسة
  • أضف الباب الخلفي

راجع قسم ميزات أمان Kernel من مستند تعريف توافق Android للحصول على متطلبات محددة.

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

  1. استخدم أحدث إصدار من Android kernel .
  2. اعتماد مبدأ الامتياز الأقل .
  3. معالجة الإضافات الخاصة بك فقط على Android. تعمل السياسة الافتراضية مع قاعدة بيانات مشروع Android Open Source Project تلقائيًا.
  4. تجزئة مكونات البرامج إلى وحدات تؤدي مهام فردية.
  5. إنشاء سياسات SELinux التي تعزل هذه المهام عن الوظائف غير ذات الصلة.
  6. ضع هذه السياسات في ملفات *.te (امتداد ملفات مصدر سياسة SELinux) ضمن الدليل /device/ manufacturer / device-name /sepolicy واستخدم متغيرات BOARD_SEPOLICY لتضمينها في جهازك.
  7. اجعل المجالات الجديدة متساهلة في البداية. يتم ذلك باستخدام تصريح متساهل في ملف .te .
  8. تحليل النتائج وتحسين تعريفات المجال الخاص بك.
  9. قم بإزالة التصريح المتساهل عند عدم ظهور المزيد من حالات الرفض في إصدارات Userdebug.

بعد دمج تغيير سياسة SELinux ، أضف خطوة إلى سير عمل التطوير لضمان توافق SELinux للمضي قدمًا. في عملية تطوير البرمجيات المثالية ، تتغير سياسة SELinux فقط عندما يتغير نموذج البرنامج وليس التنفيذ الفعلي.

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

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

عبارات سياسة مثال

يعتمد SELinux على لغة الكمبيوتر M4 وبالتالي يدعم مجموعة متنوعة من وحدات الماكرو لتوفير الوقت.

في المثال التالي ، يتم منح جميع المجالات حق الوصول للقراءة من /dev/null الكتابة إلى /dev/null والقراءة من /dev/zero .

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

يمكن كتابة هذا البيان نفسه باستخدام وحدات ماكرو SELinux *_file_perms (الاختصار):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

سياسة المثال

فيما يلي مثال كامل لسياسة DHCP ، والتي ندرسها أدناه:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

دعونا تشريح المثال:

في السطر الأول ، إعلان النوع ، يرث البرنامج الخفي لـ DHCP من سياسة الأمان الأساسية ( domain ). من أمثلة العبارة السابقة ، يمكن لـ DHCP القراءة من /dev/null الكتابة إلى /dev/null .

في السطر الثاني ، يتم تحديد DHCP كمجال متساهل.

في init_daemon_domain(dhcp) ، تنص السياسة على أن بروتوكول DHCP يتم إنتاجه من init ويسمح له بالتواصل معه.

في net_domain(dhcp) ، تسمح السياسة لـ DHCP باستخدام وظائف الشبكة الشائعة من المجال net مثل قراءة حزم TCP وكتابتها ، والتواصل عبر مآخذ التوصيل ، وإجراء طلبات DNS.

في السطر allow dhcp proc_net:file write; ، تنص السياسة على أن بروتوكول DHCP يمكنه الكتابة إلى ملفات محددة في /proc . يوضح هذا الخط وضع العلامات الدقيقة على ملف SELinux. يستخدم التسمية proc_net للحد من الوصول للكتابة فقط للملفات ضمن /proc/sys/net .

الكتلة النهائية للمثال تبدأ allow dhcp netd:fd use; يصور كيف يمكن السماح للتطبيقات بالتفاعل مع بعضها البعض. تنص السياسة على أن DHCP و netd قد يتواصلان مع بعضهما البعض عبر واصفات الملفات ، وملفات FIFO ، ومآخذ البيانات ، ومآخذ دفق UNIX. قد يقوم DHCP بالقراءة والكتابة فقط من مآخذ مخطط البيانات ومآخذ دفق UNIX وليس إنشائها أو فتحها.

الضوابط المتاحة

صف دراسي الإذن
ملف
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
الدليل
add_name remove_name reparent search rmdir open audit_access execmod
قابس كهرباء
ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind
نظام الملفات
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
معالجة
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate
الأمان
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
الإمكانية
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

أكثر

و اكثر

أبدا القواعد

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

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

القاعدة 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
انظر صفحة الرجل ptrace . و sys_ptrace القدرة تمنح القدرة على ptrace أي عملية، والذي يسمح قدرا كبيرا من السيطرة على عمليات أخرى ويجب أن تنتمي فقط إلى مكونات النظام المعين، المبينة في القاعدة. غالبًا ما تشير الحاجة إلى هذه الإمكانية إلى وجود شيء غير مخصص للبنيات أو الوظائف التي لا يحتاجها المستخدم. قم بإزالة المكون غير الضروري.

القاعدة 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
تهدف هذه القاعدة إلى منع تنفيذ التعليمات البرمجية التعسفية على النظام. على وجه التحديد ، يؤكد أنه يتم تنفيذ التعليمات البرمجية /system ، مما يسمح بضمانات الأمان بفضل آليات مثل التمهيد الذي تم التحقق منه. غالبًا ما يكون الحل الأفضل عند مواجهة مشكلة مع هذه القاعدة غير neverallow هو نقل الشفرة المسيئة إلى قسم /system .

تخصيص SEPolicy في Android 8.0+

يقدم هذا القسم إرشادات لسياسة البائع SELinux في نظام التشغيل Android 8.0 والإصدارات الأحدث ، بما في ذلك التفاصيل حول ملحقات SEPolicy و SEPolicy لمشروع Open Source Project (AOSP). لمزيد من المعلومات حول كيفية الحفاظ على توافق سياسة SELinux عبر الأقسام وإصدارات Android ، راجع التوافق .

موضع السياسة

في Android 7.0 والإصدارات الأقدم ، يمكن BOARD_SEPOLICY_DIRS المصنّعة للأجهزة إضافة سياسة إلى BOARD_SEPOLICY_DIRS ، بما في ذلك السياسة التي تهدف إلى زيادة سياسة AOSP عبر أنواع الأجهزة المختلفة. في Android 8.0 والإصدارات الأحدث ، تؤدي إضافة سياسة إلى BOARD_SEPOLICY_DIRS إلى وضع السياسة فقط في صورة المورد.

في الإصدار Android 8.0 والإصدارات الأحدث ، توجد السياسة في المواقع التالية في AOSP:

  • النظام / sepolicy / الجمهور . يتضمن سياسة تم تصديرها للاستخدام في السياسة الخاصة بالبائع. كل شيء يدخل في البنية التحتية للتوافق مع Android 8.0. تهدف السياسة العامة إلى الاستمرار عبر الإصدارات حتى تتمكن من تضمين أي شيء /public عام في سياستك المخصصة. وبسبب هذا ، فإن نوع السياسة التي يمكن وضعها في /public أكثر تقييدًا. ضع في اعتبارك واجهة برمجة تطبيقات السياسة المصدرة للنظام الأساسي: أي شيء يتعامل مع الواجهة بين /system و /vendor ينتمي هنا.
  • نظام / sepolicy / خاص . يتضمن السياسة اللازمة لعمل صورة النظام ، ولكن لا يجب أن يكون لسياسة صورة البائع أي معرفة.
  • النظام / sepolicy / البائع . يتضمن سياسة للمكونات التي تدخل /vendor ولكنها موجودة في شجرة النظام الأساسي الأساسي (وليس الدلائل الخاصة بالجهاز). هذه قطعة أثرية لتمييز نظام البناء بين الأجهزة والمكونات العالمية ؛ من الناحية النظرية ، يعد هذا جزءًا من السياسة الخاصة بالجهاز الموضحة أدناه.
  • الجهاز / manufacturer / device-name / sepolicy . يتضمن سياسة خاصة بالجهاز. يتضمن أيضًا تخصيصات الجهاز للسياسة ، والتي تتوافق في Android 8.0 والإصدارات الأحدث مع سياسة المكونات في صورة البائع.

سيناريوهات السياسة المدعومة

على الأجهزة التي يتم إطلاقها بنظام التشغيل Android 8.0 والإصدارات الأحدث ، يجب أن تعمل صورة المورد مع صورة نظام OEM وصورة نظام AOSP المرجعية المقدمة من Google (وتمرير CTS على هذه الصورة المرجعية). تضمن هذه المتطلبات فصلًا نظيفًا بين إطار العمل ورمز البائع. تدعم هذه الأجهزة السيناريوهات التالية.

ملحقات بائع الصور فقط

مثال : إضافة خدمة جديدة إلى vndservicemanager من صورة البائع التي تدعم العمليات من صورة البائع.

كما هو الحال مع الأجهزة التي يتم إطلاقها مع إصدارات Android السابقة ، أضف التخصيص الخاص device/ manufacturer / device-name /sepolicy في device/ manufacturer / device-name /sepolicy . يجب أن تتضمن السياسة الجديدة التي تحكم كيفية تفاعل مكونات البائع مع (فقط) مكونات البائع الأخرى الأنواع الموجودة فقط في device/ manufacturer / device-name /sepolicy . تسمح السياسة المكتوبة هنا بتشغيل التعليمات البرمجية للمورّد ، ولن يتم تحديثها كجزء من إطار عمل OTA فقط ، وستكون موجودة في السياسة المدمجة على جهاز مع صورة نظام AOSP المرجعي.

دعم بائع صورة للعمل مع AOSP

مثال : إضافة عملية جديدة (مسجلة مع hwservicemanager من صورة البائع) تنفذ HAL المعرفة بـ AOSP.

كما هو الحال مع الأجهزة التي يتم إطلاقها مع إصدارات Android السابقة ، قم بإجراء التخصيص الخاص device/ manufacturer / device-name /sepolicy في device/ manufacturer / device-name /sepolicy . السياسة المصدرة كجزء من system/sepolicy/public/ متاحة للاستخدام ، ويتم شحنها كجزء من سياسة المورد. يمكن استخدام أنواع وسمات السياسة العامة في القواعد الجديدة التي تملي التفاعل مع البتات الجديدة الخاصة بالمورد ، مع neverallow القيود التي لا neverallow . كما هو الحال مع حالة البائع فقط ، لن يتم تحديث السياسة الجديدة هنا كجزء من إطار OTA لإطار العمل فقط وستكون موجودة في السياسة المدمجة على جهاز مع صورة نظام AOSP المرجعي.

ملحقات صورة النظام فقط

مثال : إضافة خدمة جديدة (مسجلة مع servicemanager) يتم الوصول إليها فقط من خلال عمليات أخرى من صورة النظام.

أضف هذه السياسة إلى system/sepolicy/private . يمكنك إضافة عمليات أو كائنات إضافية لتمكين الوظائف في صورة نظام الشريك ، بشرط ألا تحتاج هذه البتات الجديدة إلى التفاعل مع المكونات الجديدة في صورة المورد (على وجه التحديد ، يجب أن تعمل هذه العمليات أو الكائنات بشكل كامل بدون سياسة من صورة البائع) . السياسة التي تم تصديرها من قبل system/sepolicy/public متاحة هنا تمامًا كما هي بالنسبة إلى ملحقات صورة البائع فقط. هذه السياسة هي جزء من صورة النظام ويمكن تحديثها في إطار OTA للإطار فقط ، ولكنها لن تكون موجودة عند استخدام صورة نظام AOSP المرجعية.

ملحقات صورة المورد التي تخدم مكونات AOSP الممتدة

مثال: إصدار تجريبي جديد بخلاف AOSP لاستخدامه من قبل العملاء الموسَّعين والذي يوجد أيضًا في صورة نظام AOSP (مثل خادم نظام موسع).

يجب تضمين سياسة التفاعل بين النظام والبائع في دليل device/ manufacturer / device-name /sepolicy المشحون في قسم البائع. هذا مشابه للسيناريو السابق لإضافة دعم صورة البائع للعمل مع صورة AOSP المرجعية ، باستثناء مكونات AOSP المعدلة قد تتطلب أيضًا سياسة إضافية للعمل بشكل صحيح مع باقي قسم النظام (وهو أمر جيد طالما أنها لا تزال لديها ملصقات نوع AOSP العامة).

يجب أن تكون سياسة تفاعل مكونات AOSP العامة مع ملحقات صورة النظام فقط في system/sepolicy/private .

ملحقات صورة النظام التي تصل إلى واجهات AOSP فقط

مثال: يجب أن تصل عملية نظام غير AOSP جديدة إلى HAL تعتمد عليها AOSP.

وهذا مشابه لمثال ملحق صورة النظام فقط ، باستثناء أن مكونات النظام الجديدة قد تتفاعل عبر واجهة system/vendor . يجب أن system/sepolicy/private سياسة مكون النظام الجديد في system/sepolicy/private ، وهو أمر مقبول بشرط أن يكون ذلك من خلال واجهة تم إنشاؤها بالفعل بواسطة AOSP في system/sepolicy/public (أي الأنواع والسمات المطلوبة للوظائف موجودة). على الرغم من إمكانية تضمين السياسة في السياسة الخاصة بالجهاز ، إلا أنها لن تتمكن من استخدام أنواع أخرى من system/sepolicy/private أو تغيير (بأي طريقة تؤثر على السياسة) نتيجة لتحديث إطار العمل فقط. قد يتم تغيير السياسة في إطار OTA للإطار فقط ، ولكنها لن تكون موجودة عند استخدام صورة نظام AOSP (والتي لن تحتوي على مكون النظام الجديد أيضًا).

ملحقات صورة المورد التي تخدم مكونات النظام الجديدة

مثال: إضافة HAL جديدة بخلاف AOSP لاستخدامها من قبل عملية العميل بدون نظير AOSP (وبالتالي يتطلب المجال الخاص به).

على غرار مثال ملحقات AOSP ، يجب أن تنتقل سياسة التفاعلات بين النظام device/ manufacturer / device-name /sepolicy دليل device/ manufacturer / device-name /sepolicy المشحون على قسم البائع (لضمان عدم معرفة سياسة النظام بالتفاصيل الخاصة بالمورد). يمكنك إضافة أنواع عامة جديدة توسع السياسة في system/sepolicy/public ؛ يجب أن يتم ذلك فقط بالإضافة إلى سياسة AOSP الحالية ، أي لا تقم بإزالة سياسة AOSP العامة. يمكن بعد ذلك استخدام الأنواع العامة الجديدة للسياسة في system/sepolicy/private وفي device/ manufacturer / device-name /sepolicy .

ضع في اعتبارك أن كل إضافة إلى system/sepolicy/public تضيف التعقيد من خلال الكشف عن ضمان توافق جديد يجب تتبعه في ملف رسم الخرائط والذي يخضع لقيود أخرى. يمكن فقط إضافة أنواع جديدة وقواعد السماح المقابلة في system/sepolicy/public ؛ السمات وبيانات السياسة الأخرى غير معتمدة. بالإضافة إلى ذلك ، لا يمكن استخدام أنواع عامة جديدة لتسمية الكائنات مباشرة في سياسة /vendor .

سيناريوهات سياسة غير مدعومة

الأجهزة التي تعمل بنظام Android 8.0 والإصدارات الأحدث لا تدعم سيناريو وأمثلة السياسة التالية.

ملحقات إضافية لصورة النظام التي تحتاج إلى إذن لمكونات صورة البائع الجديدة بعد OTA إطار العمل فقط

مثال: تمت إضافة عملية نظام جديدة بخلاف AOSP ، تتطلب نطاقها الخاص ، في إصدار Android التالي وتحتاج إلى الوصول إلى HAL جديد غير AOSP.

على غرار النظام الجديد (غير AOSP) وتفاعل مكونات البائع ، باستثناء نوع النظام الجديد الذي تم تقديمه في إطار OTA فقط. على الرغم من أنه يمكن إضافة النوع الجديد إلى السياسة في system/sepolicy/public ، إلا أن سياسة الموردين الحالية ليس لديها معرفة بالنوع الجديد لأنها تتبع السياسة العامة لنظام Android 8.0 فقط. يعالج AOSP هذا من خلال الكشف عن الموارد التي يوفرها المورد عبر سمة (مثل سمة hal_foo ) ولكن نظرًا لأن ملحقات شركاء السمة غير مدعومة في system/sepolicy/public ، فإن هذه الطريقة غير متاحة لسياسة المورد. يجب توفير الوصول من خلال نوع عام موجود مسبقًا.

مثال: يجب أن يغير تغيير عملية النظام (AOSP أو غير AOSP) كيفية تفاعله مع مكون البائع الجديد غير AOSP.

يجب كتابة السياسة على صورة النظام دون معرفة تخصيصات بائع محددة. وبالتالي ، يتم الكشف عن السياسة المتعلقة بواجهات محددة في AOSP عبر سمات في النظام / سياسة عامة / عامة بحيث يمكن لسياسة المورد الاشتراك في سياسة النظام المستقبلية التي تستخدم هذه السمات. ومع ذلك ، لا يتم دعم إضافات السمات في system/sepolicy/public ، لذا يجب أن تكون جميع السياسات التي تملي كيفية تفاعل مكونات النظام مع مكونات البائع الجديدة (والتي لا يتم التعامل معها من خلال السمات الموجودة بالفعل في system/sepolicy/public ) في device/ manufacturer / device-name /sepolicy . هذا يعني أن أنواع النظام لا يمكنها تغيير الوصول المسموح به لأنواع البائعين كجزء من إطار عمل OTA فقط.