תאימות למדיניות

בדף הזה מוסבר איך מערכת Android מטפלת בבעיות תאימות למדיניות בעדכונים של הפלטפורמה דרך האוויר (OTA), שבהם הגדרות SELinux חדשות של הפלטפורמה עשויות להיות שונות מהגדרות SELinux ישנות של הספק.

בעלות על אובייקטים ותיוג שלהם

צריך להגדיר בבירור את הבעלות על כל אובייקט כדי להפריד בין המדיניות של הפלטפורמה לבין המדיניות של הספק. לדוגמה, אם תוויות מדיניות הספק /dev/foo ותוויות מדיניות הפלטפורמה /dev/foo מופיעות בעדכון OTA עוקב, תהיה התנהגות לא מוגדרת כמו דחייה לא צפויה, או גרוע מכך, כשל באתחול. ב-SELinux, זה מתבטא בהתנגשות של תוויות. לצומת device יכולה להיות רק תווית אחת, שמוגדרת לתווית האחרונה שמוחלת. כתוצאה מכך:

• תהליכים שזקוקים לגישה לתווית שלא הוחלה בהצלחה מאבדים את הגישה למשאב.
• תהליכים שמקבלים גישה לקובץ עלולים להיכשל כי נוצר צומת מכשיר שגוי.

התנגשויות בין תוויות של פלטפורמה לבין תוויות של ספק יכולות להתרחש בכל אובייקט שיש לו תווית SELinux, כולל מאפיינים, שירותים, תהליכים, קבצים ושקעים. כדי להימנע מהבעיות האלה, צריך להגדיר בבירור את הבעלות על האובייקטים האלה.

הוספת מרחב שמות לסוגים או למאפיינים

בנוסף להתנגשויות בין תוויות, יכולות להיות גם התנגשויות בין שמות של סוגים ומאפיינים ב-SELinux. ‫SELinux לא מאפשר הצהרות מרובות של אותם סוגים ומאפיינים. קומפילציה של מדיניות עם הצהרות כפולות נכשלת. כדי להימנע מהתנגשויות בין סוגים ושמות של מאפיינים, מומלץ מאוד שכל הצהרות הספקים יתחילו בקידומת vendor_. לדוגמה, ספקים צריכים להשתמש ב-type vendor_foo, domain; במקום ב-type foo, domain;.

הבעלות על הקובץ

קשה למנוע התנגשויות בקבצים כי המדיניות של הפלטפורמה ושל הספק מספקת בדרך כלל תוויות לכל מערכות הקבצים. בניגוד לשמות של סוגים, לא מעשי להשתמש במרחבי שמות לקבצים, כי הרבה מהם נוצרים על ידי ליבת המערכת. כדי למנוע התנגשויות כאלה, כדאי לפעול לפי ההנחיות למתן שמות למערכות קבצים שמפורטות בקטע הזה. ב-Android מגרסה 8.0, אלה המלצות ללא אכיפה טכנית. בעתיד, ההמלצות האלה ייאכפו על ידי חבילת הבדיקות של הספקים (VTS).

מערכת (/system)

רק תמונת המערכת צריכה לספק תוויות לרכיבים /system עד file_contexts, service_contexts וכו'. אם מוסיפים תוויות לרכיבים /system במדיניות הספק, יכול להיות שעדכון OTA רק של המסגרת לא יתאפשר.

ספק (/vendor)

מדיניות SELinux של AOSP כבר מתייגת חלקים של מחיצת vendor שהפלטפורמה מקיימת איתה אינטראקציה, מה שמאפשר לכתוב כללי SELinux לתהליכי פלטפורמה כדי שיוכלו לתקשר עם חלקים של מחיצת vendor או לגשת אליהם. לדוגמה:

לכן, כשמתייגים קבצים נוספים במחיצה vendor, צריך לפעול לפי כללים ספציפיים (שנאכפים באמצעות neverallows):

• vendor_file חייבת להיות התווית שמוגדרת כברירת מחדל לכל הקבצים במחיצה vendor. מדיניות הפלטפורמה מחייבת את זה כדי לגשת להטמעות של HAL passthrough.
• לכל exec_types חדש שנוסף במחיצה vendor דרך מדיניות הספק צריך להיות מאפיין vendor_file_type. האכיפה מתבצעת באמצעות neverallows.
• כדי למנוע התנגשויות עם עדכונים עתידיים של פלטפורמות או מסגרות, אל תתייגו קבצים אחרים מלבד exec_types במחיצה vendor.
• כל התלות בספריות עבור HALs באותו תהליך שזוהו ב-AOSP צריכה להיות מסומנת בתווית same_process_hal_file.

Procfs ‏ (/proc)

אפשר להוסיף תוויות לקבצים ב-/proc רק באמצעות התווית genfscon label. ב-Android 7.0, גם המדיניות של הפלטפורמה וגם המדיניות של הספק השתמשו ב-genfscon כדי לתייג קבצים ב-procfs.

המלצה: רק תוויות של מדיניות הפלטפורמה /proc. אם לספק יש צורך לגשת לקבצים ב-/proc שכרגע מסומנים בתווית ברירת המחדל (proc), מדיניות הספק לא צריכה לסמן אותם באופן מפורש, אלא להשתמש בסוג הכללי proc כדי להוסיף כללים לדומיינים של הספק. כך עדכוני הפלטפורמה יוכלו להתאים לממשקי ליבה עתידיים שנחשפים דרך procfs ולסמן אותם באופן מפורש לפי הצורך.

Debugfs (/sys/kernel/debug)

אפשר לתייג את Debugfs גם ב-file_contexts וגם ב-genfscon. ב-Android מגרסה 7.0 עד גרסה 10, התווית של הפלטפורמה וגם התווית של הספק debugfs.

ב-Android 11, אי אפשר לגשת אל debugfs או לטעון אותו במכשירי ייצור. יצרני המכשירים צריכים להסיר את debugfs.

Tracefs (/sys/kernel/debug/tracing)

אפשר לתייג את Tracefs גם ב-file_contexts וגם ב-genfscon. ב-Android 7.0, רק תוויות הפלטפורמה tracefs.

המלצה: רק הפלטפורמה יכולה להוסיף את התווית tracefs.

Sysfs ‏ (/sys)

אפשר להוסיף תוויות לקבצים ב-/sys באמצעות file_contexts וגם באמצעות genfscon. ב-Android 7.0, גם הפלטפורמה וגם הספק משתמשים ב-genfscon כדי לתייג קבצים ב-sysfs.

המלצה: יכול להיות שהפלטפורמה תסמן צמתי sysfs שאינם ספציפיים למכשיר. אחרת, רק ספקים יכולים להוסיף תוויות לקבצים.

tmpfs (/dev)

יכול להיות שקבצים ב-/dev יסומנו בתווית ב-file_contexts. ב-Android 7.0, קובצי התוויות של הפלטפורמה ושל הספק נמצאים כאן.

המלצה: יכול להיות שהספק יסמן רק קבצים ב-/dev/vendor (לדוגמה, /dev/vendor/foo,‏ /dev/vendor/socket/bar).

Rootfs ‏ (/)

יכול להיות שקבצים ב-/ יסומנו בתווית ב-file_contexts. ב-Android 7.0, קובצי התוויות של הפלטפורמה והספק נמצאים כאן.

המלצה: רק המערכת יכולה להוסיף תוויות לקבצים ב-/.

נתונים (/data)

הנתונים מתויגים באמצעות שילוב של file_contexts ושל seapp_contexts.

המלצה: לא לאפשר לספקים להוסיף תוויות מחוץ ל-/data/vendor. רק הפלטפורמה יכולה לתייג חלקים אחרים של /data.

גרסת תוויות Genfs

החל מרמת vendor API‏ 202504, תוויות SELinux חדשות יותר שהוקצו באמצעות genfscon ב-system/sepolicy/compat/plat_sepolicy_genfs_ver.cil הן אופציונליות למחיצות ישנות יותר של vendor. כך מחיצות ישנות יותר של vendor יכולות לשמור על ההטמעה הקיימת של SEPolicy. השליטה בכך מתבצעת באמצעות המשתנה BOARD_GENFS_LABELS_VERSION בקובץ /vendor/etc/selinux/genfs_labels_version.txt.

דוגמה:

• ב-API של הספק ברמה 202404, הצומת /sys/class/udc מסומן כ-sysfs כברירת מחדל.
• החל מרמת ספק API‏ 202504, התווית של /sys/class/udc היא sysfs_udc. sysfs_udc.

עם זאת, יכול להיות שהמחיצות /sys/class/udc נמצאות בשימוש ב-API ברמה 202404, עם התווית sysfs שמוגדרת כברירת מחדל או עם תווית ספציפית לספק.vendor הוספת התווית sysfs_udc ל-/sys/class/udc ללא תנאי עלולה לפגוע בתאימות למחיצות vendor האלה. אם מסמנים את התיבה BOARD_GENFS_LABELS_VERSION, הפלטפורמה ממשיכה להשתמש בתוויות ובהרשאות הקודמות למחיצות הישנות יותר של vendor.

הערך של BOARD_GENFS_LABELS_VERSION יכול להיות גדול או שווה לרמת ה-API של הספק. לדוגמה, vendor מחיצות שמשתמשות ברמת API‏ 202404 יכולות להגדיר את BOARD_GENFS_LABELS_VERSION ל-202504 כדי להשתמש בתוויות חדשות שהוצגו ב-202504. רשימת תוויות GenFS ספציפיות ל-202504

כשמתייגים צמתים של genfscon, הפלטפורמה צריכה להתחשב במחיצות ישנות יותר של vendor ולהטמיע מנגנוני חזרה לתאימות כשצריך. הפלטפורמה יכולה להשתמש בספריות שפועלות רק בפלטפורמה כדי לשלוח שאילתות לגבי גרסת התוויות של genfs.

• במודעות מותאמות, צריך להשתמש ב-libgenfslabelsversion. למידע על קובץ הכותרת של libgenfslabelsversion, ראו genfslabelsversion.h.
• ב-Java, משתמשים ב- android.os.SELinux.getGenfsLabelsVersion().

מדיניות ציבורית של פלטפורמה

מדיניות SELinux של הפלטפורמה מחולקת לפרטית ולציבורית. מדיניות הפלטפורמה הציבורית מורכבת מסוגים וממאפיינים שתמיד זמינים ברמת ספק API, ומשמשת כ-API בין הפלטפורמה לספק. המדיניות הזו מוצגת לכותבי מדיניות של ספקים כדי לאפשר להם ליצור קובצי מדיניות של ספקים. כשמשלבים את קובצי המדיניות האלה עם המדיניות הפרטית של הפלטפורמה, מתקבלת מדיניות מתפקדת באופן מלא למכשיר. מדיניות הפלטפורמה לציבור מוגדרת ב-system/sepolicy/public.

לדוגמה, סוג vendor_init, שמייצג את תהליך האתחול בהקשר של ספק, מוגדר בקטע system/sepolicy/public/vendor_init.te:

type vendor_init, domain;

ספקים יכולים להשתמש בסוג vendor_init כדי לכתוב כללי מדיניות בהתאמה אישית:

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

מאפייני תאימות

מדיניות SELinux היא אינטראקציה בין סוגי מקור וסוגי יעד עבור מחלקות אובייקטים והרשאות ספציפיות. לכל אובייקט (לדוגמה, תהליכים, קבצים) שמושפע ממדיניות SELinux יכול להיות רק סוג אחד, אבל לסוג הזה יכולים להיות כמה מאפיינים.

המדיניות כתובה בעיקר במונחים של סוגים קיימים. בדוגמה הזו, גם vendor_init וגם debugfs הם סוגים:

allow vendor_init debugfs:dir { mounton };

השיטה הזו עובדת כי המדיניות נכתבה על סמך ידע בכל הסוגים. עם זאת, אם במדיניות הספק ובמדיניות הפלטפורמה נעשה שימוש בסוגים ספציפיים, והתווית של אובייקט ספציפי משתנה רק באחת מהמדיניות האלה, יכול להיות שהמדיניות השנייה תכיל מדיניות שקיבלה או איבדה גישה שהסתמכה עליה בעבר. לדוגמה, נניח שתוויות המדיניות של הפלטפורמה מסמנות צמתים של sysfs כ-sysfs:

/sys(/.*)? u:object_r:sysfs:s0

מדיניות הספק מעניקה גישה אל /sys/usb, שמסומן כ-sysfs:

allow vendor_init sysfs:chr_file rw_file_perms;

אם מדיניות הפלטפורמה משתנה לתווית /sys/usb בתור sysfs_usb, מדיניות הספק נשארת ללא שינוי, אבל vendor_init מאבדת את הגישה ל-/sys/usb בגלל היעדר מדיניות לסוג החדש sysfs_usb:

/sys/usb u:object_r:sysfs_usb:s0

כדי לפתור את הבעיה, ב-Android מוצג קונספט של מאפיינים עם גרסאות. בזמן ההידור, מערכת ה-Build מתרגמת באופן אוטומטי את הסוגים הציבוריים של הפלטפורמה שנעשה בהם שימוש במדיניות הספק למאפיינים האלה עם הגרסה. התרגום הזה מופעל על ידי מיפוי קבצים שמשייכים מאפיין עם ניהול גרסאות לסוג ציבורי אחד או יותר מהפלטפורמה.

לדוגמה, נניח שהמוצר /sys/usb מסומן בתווית sysfs במדיניות הפלטפורמה 202504, ומדיניות הספק 202504 מעניקה ל-vendor_init גישה ל-/sys/usb. במקרה כזה:

• מדיניות הספק כותבת כלל allow vendor_init sysfs:chr_file rw_file_perms;, כי /sys/usb מסומן בתווית sysfs במדיניות הפלטפורמה 202504. כשמערכת ה-build מבצעת קומפילציה של מדיניות הספק, היא מתרגמת אוטומטית את הכלל ל-allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;. המאפיינים vendor_init_202504 ו-sysfs_202504 תואמים לסוגים vendor_init ו-sysfs, שהם הסוגים שמוגדרים על ידי הפלטפורמה.
• מערכת ה-build יוצרת קובץ מיפוי זהויות /system/etc/selinux/mapping/202504.cil. מכיוון שגם המחיצות system וגם המחיצות vendor משתמשות באותה גרסה של 202504, קובץ המיפוי מכיל מיפויי זהויות מ-type_202504 ל-type. לדוגמה: vendor_init_202504 ממופה ל-vendor_init, ו- sysfs_202504 ממופה ל-sysfs:

  (typeattributeset sysfs_202504 (sysfs))
  (typeattributeset vendor_init_202504 (vendor_init))
  ...

כשהגרסה משתנה מ-202504 ל-202604, נוצר קובץ מיפוי חדש למחיצות 202504 vendor בתיקייה system/sepolicy/private/compat/202504/202504.cil, שמותקן ב-/system/etc/selinux/mapping/202504.cil למחיצות 202604 או חדשות יותר system. בתחילה, קובץ המיפוי הזה מכיל מיפויי זהויות, כפי שתיארנו קודם. אם תווית חדשה sysfs_usb בשביל /sys/usb תתווסף למדיניות הפלטפורמה 202604, קובץ המיפוי יעודכן כדי למפות את sysfs_202504 ל-sysfs_usb:

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

העדכון הזה מאפשר לכלל המדיניות של הספק שהומר allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; להעניק באופן אוטומטי גישה לטיפוס החדש sysfs_usb.vendor_init

כדי לשמור על תאימות למחיצות vendor ישנות יותר, בכל פעם שמוסיפים סוג חדש של נתונים שגלויים לציבור, צריך למפות את הסוג הזה לפחות לאחד מהמאפיינים עם הגרסאות בקובץ המיפוי system/sepolicy/private/compat/ver/ver.cil, או לציין אותו בקטע system/sepolicy/private/compat/ver/ver.ignore.cil כדי לציין שאין סוג תואם בגרסאות הקודמות של הספק.

השילוב של מדיניות הפלטפורמה, מדיניות הספק וקובץ המיפוי מאפשר למערכת להתעדכן בלי לעדכן את מדיניות הספק. בנוסף, ההמרה למאפיינים עם מספור גרסאות מתבצעת באופן אוטומטי, כך שמדיניות הספק לא צריכה לטפל בניהול הגרסאות, והיא ממשיכה להשתמש בסוגים הציבוריים כמו שהם.

מדיניות ציבורית של מערכת_ext ומדיניות ציבורית של מוצרים

החל מ-Android 11, למחיצות system_ext ו-product מותר לייצא את הסוגים הציבוריים המיועדים שלהן למחיצה vendor. בדומה למדיניות הציבורית של הפלטפורמה, מדיניות הספק משתמשת בסוגים ובכללים שמתורגמים אוטומטית למאפיינים עם ניהול גרסאות. לדוגמה, מ-type ל-type_ver, כאשר ver הוא רמת ה-API של הספק במחיצה vendor.

אם המחיצות system_ext ו-product מבוססות על אותה גרסת פלטפורמה ver, מערכת ה-build יוצרת קובצי מיפוי בסיסיים ל-system_ext/etc/selinux/mapping/ver.cil ול-product/etc/selinux/mapping/ver.cil, שמכילים מיפויי זהות מ-type ל-type_ver. ספק המדיניות יכול לגשת אל type באמצעות מאפיין עם גרסה type_ver.

אם רק המחיצות system_ext ו-product מתעדכנות, למשל מ-ver ל-ver+1 (או לגרסה מאוחרת יותר), בזמן שהמחיצה vendor נשארת בגרסה ver, יכול להיות שהמדיניות של הספק תאבד את הגישה לסוגים של המחיצות system_ext ו-product. כדי למנוע שבירה, מחיצות system_ext ו-product צריכות לספק קובצי מיפוי מסוגים קונקרטיים למאפייני type_ver. כל שותף אחראי לתחזוקת קובצי המיפוי, אם הוא תומך בחלוקת מחיצות של ver vendor עם ver+1 (או גרסה מתקדמת יותר) system_ext ומחיצות product.

כדי להתקין קובצי מיפוי במחיצות system_ext ו-product, יצרני מכשירים או ספקים צריכים:

1. מעתיקים את קובצי מיפוי הבסיס שנוצרו מהמחיצות ver system_ext ו-product אל עץ המקור שלהן.
2. משנים את קובצי המיפוי לפי הצורך.
3. מתקינים את קובצי המיפוי ב-ver+1 (או בגרסה מתקדמת יותר) system_ext ובמחיצות product.

לדוגמה, נניח שלמחיצה 202504 system_ext יש סוג ציבורי אחד בשם foo_type. אחר כך system_ext/etc/selinux/mapping/202504.cil במחיצה 202504 system_ext זה נראה כך:

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

אם bar_type נוסף ל-202604 system_ext, ואם צריך למפות את bar_type ל-foo_type עבור המחיצה 202504vendor, אפשר לעדכן את 202504.cil מ-(typeattributeset foo_type_202504 (foo_type)) ל-(typeattributeset foo_type_202504 (foo_type bar_type)) ואז להתקין אותו במחיצה 202604 system_ext. מחיצת 202504 vendor יכולה להמשיך לגשת אל foo_type וbar_type של 202604 system_ext.

שינויים במאפיינים ב-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) שמפירים את הדרישה שלא להפעיל קבצים בינאריים של ספקים. ההרצה של קבצים בינאריים של ספקים כוללת API לא יציב. הפלטפורמה לא אמורה להריץ קבצים בינאריים של ספקים באופן ישיר. המלצה:
  • יחסי תלות כאלה של פלטפורמות בקבצים בינאריים של ספקים חייבים להיות מאחורי HIDL HAL.

    או

  • coredomains שצריכים גישה לקבצים בינאריים של ספקים צריכים לעבור למחיצה vendor וכך להפסיק להיות coredomain.

מאפיינים לא מהימנים

לאפליקציות לא מהימנות שמארחות קוד שרירותי לא צריכה להיות גישה לשירותי HwBinder, למעט לאפליקציות שנחשבות בטוחות מספיק לגישה מאפליקציות כאלה (ראו את רשימת השירותים הבטוחים בהמשך). יש שתי סיבות עיקריות לכך:

1. שרתי HwBinder לא מבצעים אימות של לקוחות כי HIDL לא חושף כרגע מידע על מזהה המשתמש של המתקשר. גם אם HIDL היה חושף נתונים כאלה, הרבה שירותי HwBinder פועלים ברמה שמתחת לרמת האפליקציות (לדוגמה, HAL) או שלא יכולים להסתמך על זהות האפליקציה לצורך הרשאה. לכן, כדי להיות בטוחים, ההנחה שמוגדרת כברירת מחדל היא שכל שירות HwBinder מתייחס לכל הלקוחות שלו כבעלי הרשאה שווה לבצע פעולות שהשירות מציע.
2. שרתי HAL (קבוצת משנה של שירותי HwBinder) מכילים קוד עם שיעור גבוה יותר של בעיות אבטחה בהשוואה לרכיבי system/core, ויש להם גישה לשכבות הנמוכות יותר של המערך (עד לרמת החומרה), ולכן הם מגדילים את הסיכוי לעקוף את מודל האבטחה של Android.

שירותים בטוחים

שירותים בטוחים כוללים:

• same_process_hwservice. השירותים האלה (בהגדרה) פועלים בתהליך של הלקוח, ולכן יש להם את אותה גישה כמו לדומיין של הלקוח שבו התהליך פועל.
• coredomain_hwservice. השירותים האלה לא יוצרים סיכונים שקשורים לסיבה מספר 2.
• hal_configstore_ISurfaceFlingerConfigs. השירות הזה מיועד לשימוש בכל דומיין.
• ‫hal_graphics_allocator_hwservice. הפעולות האלה מוצעות גם על ידי שירות surfaceflinger Binder, שאפליקציות מורשות יכולות לגשת אליו.
• ‫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 צריכות להיות בעלות דומיין sepolicy משלהן שמוגדר על ידי הספק.

בדיקות של מאפייני קובץ

‫Android 9 כולל בדיקות בזמן בנייה שמוודאות שלכל הקבצים במיקומים ספציפיים יש את המאפיינים המתאימים (לדוגמה, לכל הקבצים ב-sysfs יש את המאפיין הנדרש sysfs_type).

הוספת תוויות להקשרים של 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/.