بعد دمج المستوى الأساسي لوظيفة SELinux وتحليل النتائج بدقة ، يمكنك إضافة إعدادات السياسة الخاصة بك لتغطية تخصيصاتك لنظام التشغيل Android. يجب أن تظل هذه السياسات تفي بمتطلبات برنامج التوافق مع Android ويجب ألا تزيل إعدادات SELinux الافتراضية.
يجب على الشركات المصنعة عدم إزالة سياسة SELinux الحالية. خلاف ذلك ، فإنهم يخاطرون بخرق تطبيق Android SELinux والتطبيقات التي يحكمها. يتضمن ذلك تطبيقات الجهات الخارجية التي من المحتمل أن تحتاج إلى تحسين لتكون متوافقة وقابلة للتشغيل. يجب ألا تتطلب التطبيقات أي تعديل لمواصلة العمل على الأجهزة التي تدعم SELinux.
عند الشروع في تخصيص SELinux ، تذكر أن:
- اكتب سياسة SELinux لجميع الشياطين الجديدة
- استخدم المجالات المحددة مسبقًا متى كان ذلك مناسبًا
- قم بتعيين مجال لأي عملية يتم إنتاجها كخدمة
init - التعرف على وحدات الماكرو قبل كتابة السياسة
- إرسال التغييرات على السياسة الأساسية إلى AOSP
وتذكر ألا:
- إنشاء سياسة غير متوافقة
- السماح بتخصيص نهج المستخدم النهائي
- السماح بتخصيصات نهج MDM
- تخويف المستخدمين من انتهاكات السياسة
- أضف أبواب خلفية
راجع قسم ميزات أمان Kernel في مستند تعريف توافق Android للتعرف على متطلبات محددة.
يستخدم SELinux نهج القائمة البيضاء ، مما يعني أنه يجب السماح بكل وصول صريحًا في السياسة حتى يتم منحه. نظرًا لأن سياسة SELinux الافتراضية لنظام Android تدعم بالفعل مشروع Android Open Source Project ، فلا يلزمك تعديل إعدادات SELinux بأي طريقة. إذا قمت بتخصيص إعدادات SELinux ، فاحرص على عدم كسر التطبيقات الحالية. للبدء:
- استخدم أحدث إصدار من Android kernel .
- تبني مبدأ الامتياز الأقل .
- تناول فقط الإضافات الخاصة بك إلى Android. تعمل السياسة الافتراضية مع قاعدة بيانات مشروع Android Open Source Project تلقائيًا.
- قسِّم مكونات البرامج إلى وحدات نمطية تؤدي مهامًا فردية.
- قم بإنشاء سياسات SELinux التي تعزل تلك المهام عن الوظائف غير ذات الصلة.
- ضع هذه السياسات في ملفات
*.te(امتداد ملفات مصدر سياسة SELinux) داخل الدليل/device/ manufacturer / device-name /sepolicyواستخدم متغيراتBOARD_SEPOLICYلتضمينها في جهازك. - اجعل المجالات الجديدة متساهلة في البداية. يتم ذلك باستخدام تصريح مسموح به في ملف
.teالخاص بالمجال. - تحليل النتائج وتحسين تعريفات المجال الخاص بك.
- قم بإزالة التصريح المسموح به في حالة عدم ظهور المزيد من عمليات الرفض في إصدارات userdebug.
بعد دمج تغيير سياسة SELinux ، أضف خطوة إلى سير عمل التطوير لضمان توافق SELinux من الآن فصاعدًا. في عملية تطوير البرمجيات المثالية ، تتغير سياسة SELinux فقط عندما يتغير نموذج البرنامج وليس التنفيذ الفعلي.
عندما تبدأ في تخصيص SELinux ، قم أولاً بمراجعة إضافاتك إلى Android. إذا أضفت مكونًا يقوم بوظيفة جديدة ، فتأكد من أن المكون يلبي سياسة أمان Android ، بالإضافة إلى أي سياسة مرتبطة بها صاغتها الشركة المصنعة للمعدات الأصلية ، قبل تشغيل وضع الفرض.
لمنع المشكلات غير الضرورية ، من الأفضل أن تكون واسع النطاق ومتوافقًا أكثر من التقييد الشديد وغير المتوافق ، مما يؤدي إلى وظائف الجهاز المعطلة. على العكس من ذلك ، إذا كانت تغييراتك ستفيد الآخرين ، فيجب عليك إرسال التعديلات إلى سياسة SELinux الافتراضية كتصحيح . إذا تم تطبيق التصحيح على سياسة الأمان الافتراضية ، فلن تحتاج إلى إجراء هذا التغيير مع كل إصدار Android جديد.
أمثلة على بيانات السياسة
يعتمد SELinux على لغة الكمبيوتر M4 وبالتالي يدعم مجموعة متنوعة من وحدات الماكرو لتوفير الوقت.
في المثال التالي ، يتم منح جميع المجالات حق الوصول للقراءة من أو الكتابة إلى /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 macros (اختصار):
# 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 .
في السطر الثاني ، يتم تحديد 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 |
أكثر | و اكثر |
قواعد لا تسمح
تحظر قواعد 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 لمشروع Android مفتوح المصدر (AOSP). لمزيد من المعلومات حول كيفية الحفاظ على توافق سياسة SELinux عبر الأقسام وإصدارات Android ، راجع التوافق .
وضع السياسة
في الإصدار Android 7.0 والإصدارات الأقدم ، يمكن للشركات المصنّعة للأجهزة إضافة سياسة إلى BOARD_SEPOLICY_DIRS ، بما في ذلك السياسة التي تهدف إلى تعزيز سياسة AOSP عبر أنواع الأجهزة المختلفة. في الإصدار Android 8.0 والإصدارات الأحدث ، تؤدي إضافة سياسة إلى BOARD_SEPOLICY_DIRS إلى وضع السياسة في صورة البائع فقط.
في Android 8.0 والإصدارات الأحدث ، توجد السياسة في المواقع التالية في AOSP:
- نظام / بوليسي / عام . يشمل السياسة المصدرة للاستخدام في السياسة الخاصة بالبائع. يذهب كل شيء إلى البنية التحتية لتوافق Android 8.0. تهدف السياسة العامة إلى الاستمرار عبر الإصدارات بحيث يمكنك تضمين أي شيء
/publicعام في سياستك المخصصة. لهذا السبب ، فإن نوع السياسة التي يمكن وضعها في/publicيكون أكثر تقييدًا. ضع في اعتبارك واجهة برمجة تطبيقات السياسة المصدرة للنظام الأساسي: أي شيء يتعامل مع الواجهة بين/systemو/vendorينتمي هنا. - نظام / بوليسي / خاص . يتضمن السياسة اللازمة لتشغيل صورة النظام ، ولكن سياسة صورة البائع يجب ألا تكون على دراية بها.
- نظام / بوليسي / بائع . يتضمن نهج المكونات التي تدخل
/vendorولكنها موجودة في شجرة النظام الأساسي الأساسية (وليس الدلائل الخاصة بالجهاز). هذه نتيجة لتمييز نظام البناء بين الأجهزة والمكونات العالمية ؛ من الناحية المفاهيمية ، يعد هذا جزءًا من السياسة الخاصة بالجهاز الموضحة أدناه. - الجهاز / manufacturer / device-name / منفصل . يتضمن سياسة خاصة بالجهاز. يتضمن أيضًا تخصيصات الجهاز للسياسة ، والتي تتوافق في Android 8.0 والإصدارات الأحدث مع سياسة المكونات الموجودة في صورة البائع.
في Android 11 والإصدارات الأحدث ، يمكن أن تتضمن أقسام system_ext والمنتج أيضًا سياسات خاصة بالقسم. يتم أيضًا تقسيم system_ext وسياسات المنتج إلى عام وخاص ، ويمكن للبائعين استخدام سياسات system_ext's وسياسات المنتج العامة ، مثل سياسة النظام.
-
SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS. يشمل السياسة المصدرة للاستخدام في السياسة الخاصة بالبائع. مثبت على قسم system_ext. -
SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS. يتضمن السياسة اللازمة لتشغيل صورة system_ext ، ولكن سياسة صورة البائع يجب ألا تكون على دراية بها. مثبت على قسم system_ext. -
PRODUCT_PUBLIC_SEPOLICY_DIRS. يشمل السياسة المصدرة للاستخدام في السياسة الخاصة بالبائع. مثبت على قسم المنتج. -
PRODUCT_PRIVATE_SEPOLICY_DIRS. يتضمن السياسة اللازمة لتشغيل صورة المنتج ، ولكن سياسة صورة البائع يجب ألا تكون على دراية بها. مثبت على قسم المنتج.
سيناريوهات السياسة المدعومة
على الأجهزة التي تعمل بنظام Android 8.0 والإصدارات الأحدث ، يجب أن تعمل صورة البائع مع صورة نظام OEM وصورة نظام AOSP المرجعية التي توفرها Google (وتمرير CTS على هذه الصورة المرجعية). تضمن هذه المتطلبات فصلًا نظيفًا بين إطار العمل ورمز البائع. تدعم هذه الأجهزة السيناريوهات التالية.
امتدادات صور البائعين فقط
مثال : إضافة خدمة جديدة إلى vndservicemanager من صورة البائع التي تدعم العمليات من صورة البائع.
كما هو الحال مع الأجهزة التي يتم تشغيلها مع إصدارات Android السابقة ، أضف التخصيص الخاص بالجهاز في device/ manufacturer / device-name /sepolicy . يجب أن تتضمن السياسة الجديدة التي تحكم كيفية تفاعل مكونات البائع مع مكونات البائع الأخرى (فقط) أنواعًا موجودة فقط في device/ manufacturer / device-name /sepolicy . السياسة المكتوبة هنا تسمح للكود الخاص بالمورد بالعمل ، ولن يتم تحديثه كجزء من إطار العمل فقط OTA ، وسيكون موجودًا في السياسة المدمجة على الجهاز مع صورة نظام AOSP المرجعية.
دعم صورة البائع للعمل مع AOSP
مثال : إضافة عملية جديدة (مسجلة مع hwservicemanager من صورة البائع) التي تنفذ HAL معرّف AOSP.
كما هو الحال مع الأجهزة التي يتم تشغيلها مع إصدارات Android السابقة ، قم بإجراء التخصيص الخاص بالجهاز في device/ manufacturer / device-name /sepolicy . السياسة التي تم تصديرها كجزء من system/sepolicy/public/ متاحة للاستخدام ، ويتم شحنها كجزء من سياسة البائع. يمكن استخدام الأنواع والسمات من السياسة العامة في القواعد الجديدة التي تملي التفاعلات مع وحدات البت الخاصة بالمورد الجديد ، وفقًا neverallow المقدمة أبدًا. كما هو الحال مع حالة البائع فقط ، لن يتم تحديث السياسة الجديدة هنا كجزء من إطار العمل فقط OTA وستكون موجودة في السياسة المدمجة على جهاز مع صورة نظام AOSP المرجعية.
امتدادات صور النظام فقط
مثال : إضافة خدمة جديدة (مسجلة لدى مدير الخدمة) لا يتم الوصول إليها إلا من خلال عمليات أخرى من صورة النظام.
أضف هذه السياسة إلى system/sepolicy/private . يمكنك إضافة عمليات أو كائنات إضافية لتمكين الوظائف في صورة نظام شريك ، بشرط ألا تحتاج تلك البتات الجديدة إلى التفاعل مع المكونات الجديدة في صورة البائع (على وجه التحديد ، يجب أن تعمل هذه العمليات أو الكائنات بشكل كامل بدون سياسة من صورة البائع) . السياسة التي تم تصديرها بواسطة system/sepolicy/public متاحة هنا تمامًا كما هي للإضافات ذات الصور الموردة فقط. تعد هذه السياسة جزءًا من صورة النظام ويمكن تحديثها في OTA للإطار فقط ، ولكنها لن تكون موجودة عند استخدام صورة نظام AOSP المرجعية.
امتدادات صور البائع التي تخدم مكونات AOSP الموسعة
مثال: HAL جديد غير AOSP للاستخدام من قبل العملاء الممتدين والموجود أيضًا في صورة نظام AOSP (مثل خادم system_server الممتد).
يجب تضمين سياسة التفاعل بين النظام والمورد في دليل device/ manufacturer / device-name /sepolicy المشحون على قسم البائع. هذا مشابه للسيناريو أعلاه لإضافة دعم صورة البائع للعمل مع صورة AOSP المرجعية ، باستثناء أن مكونات AOSP المعدلة قد تتطلب أيضًا سياسة إضافية للعمل بشكل صحيح مع بقية قسم النظام (وهو أمر جيد طالما أنها لا تزال موجودة لديك تسميات نوع AOSP العامة).
يجب أن تكون سياسة تفاعل مكونات AOSP العامة مع امتدادات صورة النظام فقط في system/sepolicy/private .
امتدادات صور النظام التي تصل فقط إلى واجهات AOSP
مثال: يجب أن تصل عملية النظام الجديدة غير AOSP إلى HAL الذي تعتمد عليه AOSP.
هذا مشابه لمثال ملحق صورة النظام فقط ، باستثناء أن مكونات النظام الجديدة قد تتفاعل عبر واجهة system/vendor . يجب أن تنتقل السياسة الخاصة بمكون النظام الجديد إلى system/sepolicy/private ، وهو أمر مقبول بشرط أن يكون من خلال واجهة تم إنشاؤها بالفعل بواسطة AOSP في system/sepolicy/public (أي الأنواع والسمات المطلوبة للوظائف موجودة). بينما يمكن تضمين السياسة في السياسة الخاصة بالجهاز ، فإنه لن يكون قادرًا على استخدام system/sepolicy/private أخرى أو تغيير (بأي طريقة تؤثر على السياسة) كنتيجة لتحديث إطار العمل فقط. قد يتم تغيير السياسة في OTA للإطار فقط ، ولكنها لن تكون موجودة عند استخدام صورة نظام AOSP (والتي لن تحتوي على مكون النظام الجديد أيضًا).
امتدادات صور البائع التي تخدم مكونات النظام الجديدة
مثال: إضافة طبقة تجريد الأجهزة (HAL) جديدة غير تابعة لـ AOSP للاستخدام بواسطة عملية عميل بدون نظير AOSP (وبالتالي يتطلب مجاله الخاص).
على غرار مثال امتدادات AOSP ، يجب أن تدخل سياسة التفاعلات بين النظام والمورد في دليل 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) وتفاعل مكونات البائع ، باستثناء نوع النظام الجديد الذي تم تقديمه في إطار العمل فقط. على الرغم من أنه يمكن إضافة النوع الجديد إلى السياسة في 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.