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

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

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

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

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

אנדרואיד שומר מיפוי בין סוגי בטון מיוצאים במדיניות פלטפורמה ואת התכונות versioned המתאימות עבור כול גרסת פלטפורמה. זה מבטיח שכאשר אובייקטים מסומנים עם סוג, הוא אינו מפר את ההתנהגות המובטחת על ידי המדיניות הציבורית-פלטפורמה בגרסה קודמת. מיפוי זה מתוחזק על ידי שמירה על קובץ מיפוי עַדכָּנִי עבור כל גירסה פלטפורמה , אשר שומרת את פרטי החברות תכונה עבור כל סוג מיוצא במדיניות ציבורית.

בעלות וסימון חפצים

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

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

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

בנוסף להתנגשויות תוויות, שמות סוג/תכונות SELinux עשויים להתנגש גם הם. התנגשות שם סוג/תכונה תגרום תמיד לשגיאת מהדר מדיניות.

הקלד/מאפיין מרווח שמות

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

type foo, domain; → type np_foo, domain;

בעלות על נכס מערכת ותיוג תהליכים

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

סוג הנכס קידומות מקובלות
ניתן לכתיבה vendor.
לקריאה בלבד ro.vendor.
ro.boot.
ro.hardware.
מַתְמִיד persist.vendor.

ספקים יכולים להמשיך להשתמש ro.boot.* (אשר מגיעה מן cmdline הקרנל) ו ro.hardware.* (נכס חומרה קשור ברור).

כול שירותי הספק בקבצי RC init צריכים vendor. לשירותים בקבצי init rc של מחיצות שאינן מערכת. דומים כללים מוחלים על תוויות SELinux עבור מאפייני ספק ( vendor_ עבור מאפייני ספק).

בעלות על קבצים

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

מערכת (/מערכת)

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

ספק (/ספק)

מדיניות SELinux AOSP כבר תוויות חלקות של 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 תכונה. זה נאכף באמצעות אין אפשרות לעולם.
  • כדי למנוע התנגשויות עם פלטפורמת עתיד / עדכוני מסגרת, קבצי תיוג להימנע מלבד exec_types ב vendor מחיצה.
  • כל תלות הספרייה עבור שכבות HAL אותו תהליך-מזוהה AOSP חייב להיות מתויג בתור same_process_hal_file.

מוכיחים (/proc)

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

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

באגים (/sys/kernel/debug)

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

בשנת 11 אנדרואיד, debugfs לא ניתן לגשת או רכוב על תקני ייצור. יצרני מכשיר צריכים להסיר debugfs .

Tracefs (/sys/kernel/debug/tracing)

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

המלצה: פלטפורמה רק רשאים לתייג tracefs .

Sysfs (/sys)

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

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

tmpfs (/dev)

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

המלצה: Vendor רשאים לתייג רק קבצים /dev/vendor (למשל, /dev/vendor/foo , /dev/vendor/socket/bar ).

Rootfs (/)

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

המלצה: מערכת רק רשאים לתייג קבצים / .

נתונים (/נתונים)

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

המלצה: מחוץ תיוג ספק Disallow /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 הסוג.

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

הגדרת המדיניות הציבורית כתכונות בגרסה עונה על שתי מטרות תאימות למדיניות:

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

יכולת כתיבה של מדיניות

כדי לעמוד ביעד של לא לדרוש ידע לגבי שינויי גרסה ספציפיים לפיתוח מדיניות, אנדרואיד 8.0 כולל מיפוי בין סוגי מדיניות פלטפורמה-ציבורית ותכונותיהם. סוג foo ממופה התכונה foo_v N , שבו N הוא הגרסה המיועדת. vN מתאים PLATFORM_SEPOLICY_VERSION משתנה לבנות והוא מהצורה MM.NN , שבו MM תואם למספר SDK פלטפורמה NN היא גרסה ספציפית פלטפורמה sepolicy.

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

מדיניות Platform-ציבורית מיוצאת כמו allow source_foo target_bar: class perm ; כלול כחלק ממדיניות הספקים. במהלך הידור (הכולל את הגרסה המתאימה) הוא הופך את המדיניות תלך חלק הספק של המכשיר (מוצג שפת ביניים הנפוצה טרנספורמציה (CIL)):

 (allow source_foo_vN target_bar_vN (class (perm)))

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

מדיניות שונה

אוטומטי ליצירת תכונות ידי הוספת _v N עד הסוף של כל סוג עושה כלום בלי מיפוי של תכונות לסוגי פני הבדלי גרסאות. אנדרואיד שומרת על מיפוי בין גרסאות לתכונות ומיפוי סוגים לתכונות אלה. זה נעשה בקבצי המיפוי הנ"ל עם הצהרות, כגון (CIL):

(typeattributeset foo_vN (foo))

שדרוגי פלטפורמה

הסעיף הבא מפרט תרחישים לשדרוג פלטפורמות.

אותם סוגים

תרחיש זה מתרחש כאשר אובייקט אינו משנה תוויות בגרסאות מדיניות. זה זהה עבור סוגי המקור ושפת היעד וניתן לראות עם /dev/binder , אשר מסומן binder_device בכל הגרסאות. הוא מיוצג במדיניות שהשתנתה כ:

binder_device_v1 … binder_device_vN

בעת שדרוג מ- v1v2 , מדיניות הפלטפורמה חייבת לכלול:

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

בקובץ המיפוי v1 (CIL):

(typeattributeset binder_device_v1 (binder_device))

בקובץ מיפוי v2 (CIL):

(typeattributeset binder_device_v2 (binder_device))

במדיניות ספק v1 (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

במדיניות ספק v2 (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
סוגים חדשים

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

  • תכונה חדשה. כאשר הסוג מסמן אובייקט שבעבר לא היה קיים (כגון תהליך שירות חדש), קוד הספק לא יצר איתו אינטראקציה ישירה בעבר כך שלא קיימת מדיניות מקבילה. למאפיין החדש המתאים לסוג אין תכונה בגרסה הקודמת, ולכן לא יהיה צורך בערך בקובץ המיפוי הממוקד לגרסה זו.
  • התקשות מדיניות. כאשר סוג מייצג התקשות מדיניות, מאפיין מהסוג החדש חייב לקשר חזרה לשרשרת של התכונות מתאימות הקודם (בדומה לדוגמה הקודמת שינוי /sys/A מ sysfs כדי sysfs_A ). קוד ספק מסתמך על כלל המאפשר גישת sysfs , ועליו לכלול כלל כתכונה של הסוג החדש.

בעת שדרוג מ- v1v2 , מדיניות הפלטפורמה חייבת לכלול:

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

בקובץ המיפוי v1 (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

בקובץ מיפוי v2 (CIL):

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

במדיניות ספק v1 (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

במדיניות ספק v2 (CIL):

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
סוגים שהוסרו

תרחיש (נדיר) זה מתרחש כאשר סוג מוסר, שיכול לקרות כאשר האובייקט הבסיסי:

  • נשאר אבל מקבל תווית אחרת.
  • מוסר על ידי הרציף.

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

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

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

דוגמה לגרסה 1: סוגים מתמוטטים (הסרת sysfs_A)

בעת שדרוג מ- v1v2 , מדיניות הפלטפורמה חייבת לכלול:

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))

בקובץ מיפוי v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))

במדיניות ספק v1 (CIL):

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

במדיניות ספק v2 (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

דוגמה לגרסה 2: הסרה מלאה (סוג foo)

בעת שדרוג מ- v1v2 , מדיניות הפלטפורמה חייבת לכלול:

# 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))

בקובץ מיפוי v2 (CIL):

# nothing - get rid of it

במדיניות ספק v1 (CIL):

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

במדיניות ספק v2 (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
שיעור/הרשאות חדשות

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

      אוֹ

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

תכונות לא מהימנות

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

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

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

שירותי הכספת כוללים:

  • same_process_hwservice . שירותים אלה (בהגדרה) פועלים בתהליך של הלקוח ובכך יש להם גישה זהה לתחום הלקוח בו פועל התהליך.
  • coredomain_hwservice . שירותים אלה אינם מהווים סיכונים הקשורים בסיבה מס '2.
  • hal_configstore_ISurfaceFlingerConfigs . שירות זה תוכנן במיוחד לשימוש על ידי כל תחום.
  • hal_graphics_allocator_hwservice . פעולות אלו מוצעות גם על ידי surfaceflinger שירות בינדר, אילו אפליקציות מותר גישה.
  • hal_omx_hwservice . זוהי גרסה HwBinder של mediacodec שירות בינדר, אילו אפליקציות מותר גישה.
  • hal_codec2_hwservice . זוהי גרסה חדשה יותר של hal_omx_hwservice .

תכונות שימושיות

כל hwservices לא נחשב מקום מבטחים התכונה untrusted_app_visible_hwservice . שרתי HAL המתאים יש את התכונה untrusted_app_visible_halserver . התקני הפעלה עם MUST 9 אנדרואיד לא משתמשים untrusted תכונה.

המלצה:

  • יישומים לא מהימנים צריכים לדבר עם שירות מערכת שמדבר עם הספק HIDL HAL. לדוגמה, יישומים יכולים לדבר binderservicedomain , אז mediaserver (שהינה binderservicedomain ) במגעים בתורו אל hal_graphics_allocator .

    אוֹ

  • אפליקציות שצריכות גישה ישירה אלי vendor שכבות HAL צריכות תחום sepolicy מוגדר ספקים משלהם.

בדיקות תכונות קבצים

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

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

מדיניות הפלטפורמה-ציבורית היא הליבה בהתאמה למודל האדריכלות של אנדרואיד 8.0 מבלי לשמור על איחוד מדיניות הפלטפורמה מ- v1 ו- v2. ספקי נחשפי משנה של מדיניות פלטפורמה המכיל סוגים שמישים ותכונות ותקנון על אלו סוגים ותכונות אשר לאחר מכן הופך לחלק מדיניות ספק (כלומר vendor_sepolicy.cil ).

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

מיפוי לשרשראות ייחוס

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

שמירה על מטרה להסתיר מידע גרסא בפני כותב המדיניות פירושה יצירת מאפיינים בגרסה אוטומטית והקצאתם לסוגים המתאימים. במקרה הנפוץ של סוגי סטטי, זה פשוט: type_foo מפות כדי type_foo_v1 .

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

גירסאות uprevs

לשם הפשטות, פלטפורמת האנדרואיד מוציאה גרסה קבועה כאשר חותכים ענף מהדורות חדש. כפי שתואר לעיל, מספר הגרסה כלול PLATFORM_SEPOLICY_VERSION והוא מצורת MM.nn , שבו MM מתאים לערך SDK ו nn הוא ערך פרטי קיים ב /platform/system/sepolicy. לדוגמה, 19.0 עבור Kitkat, 21.0 עבור Lollipop, 22.0 עבור Lollipop-MR1 23.0 עבור מרשמלו, 24.0 עבור נוגט, 25.0 עבור נוגט-MR1, 26.0 עבור אוראו, 27.0 עבור אוראו-MR1, ו 28.0 עבור אנדרואיד 9. Uprevs אינם תמיד מספרים שלמים. לדוגמה, אם בליטה MR על גרסאות מצריך משינוי שאינו ב system/sepolicy/public אבל לא גבשושית API, אז הגירסה sepolicy יכול להיות: vN.1 . הווה הגרסה ב ענף פיתוח הוא מעולם ל-להיות-בשימוש-ב-משלוח-התקני 10000.0 .

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

השפעת הביצועים של מספר תכונות

כפי שתואר https://github.com/SELinuxProject/cil/issues/9 , מספר רב של תכונות שהוקצה מכך סוג ב בעיות ביצועים במקרה של פיספוס מטמון מדיניות.

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

תיוג הקשרים של SELinux

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

הקשרים של קבצים

אנדרואיד 8.0 הציג את השינויים הבאים עבור file_contexts :

  • כדי להימנע תקורה הידור נוספת במכשיר במהלך אתחול, file_contexts יחדל להתקיים בצורה בינארית. במקום זאת, הם קריאים, קובץ טקסט ביטוי רגיל כגון {property, service}_contexts (כפי שהם מראש 7.0).
  • file_contexts חצויים בין שני קבצים:
    • plat_file_contexts
      • פלטפורמת אנדרואיד 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 .

הקשרים של נכסים

בשנת אנדרואיד 8.0, את property_contexts הוא מפוצל בין שני קבצים:

  • plat_property_contexts
    • פלטפורמת אנדרואיד 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

הקשרים שירותיים

בשנת אנדרואיד 8.0, את service_contexts הוא מפוצל בין הקבצים הבאים:

  • plat_service_contexts
    • פלטפורמה ספציפית אנדרואיד service_context עבור 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
    • פלטפורמת אנדרואיד 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 בהתחלה.

הקשרים של סיפ

בשנת אנדרואיד 8.0, את seapp_contexts הוא מפוצל בין שני קבצים:

  • plat_seapp_contexts
    • פלטפורמת אנדרואיד 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

בשנת אנדרואיד 8.0, את mac_permissions.xml הוא מפוצל בין שני קבצים:

  • פלטפורמת mac_permissions.xml
    • פלטפורמת אנדרואיד 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/.