התאמה אישית של SELinux

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

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

כשאתם יוצאים להתאמה אישית של SELinux, חשוב לזכור:

  • כתיבת מדיניות SELinux לכל הדימונים החדשים
  • שימוש בדומיינים מוגדרים מראש לפי הצורך
  • הקצאת דומיין לכל תהליך שנוצר בתור שירות init
  • חשוב להכיר את פקודות המאקרו לפני כתיבת המדיניות
  • שליחת השינויים במדיניות הליבה אל AOSP

וחשוב לזכור:

  • יצירת מדיניות לא תואמת
  • התאמה אישית של המדיניות למשתמשי קצה
  • אישור להתאמה אישית של מדיניות MDM (ניהול מכשירים ניידים)
  • הפחדת משתמשים באמצעות הפרות מדיניות
  • הוספת דלתות אחוריות

אפשר לקרוא מידע נוסף בקטע תכונות אבטחה של ליבה (Kernel) Android מסמך הגדרת התאימות לדרישות ספציפיות.

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

  1. משתמשים ב גרסת Android העדכנית ביותר ליבה (kernel).
  2. ליישם עיקרון הרשאות מינימליות.
  3. מציינים רק את התוספות שלכם ל-Android. מדיניות ברירת המחדל פועלת עם קוד המקור הפתוח של Android ה-codebase של הפרויקט באופן אוטומטי.
  4. בצעו השוואה בין רכיבי תוכנה למודולים בעלי יחיד למשימות סיווג.
  5. ליצור כללי מדיניות SELinux שמבודדים את המשימות האלה מאלה שלא קשורות למשימות ספציפיות.
  6. צריך למקם את כללי המדיניות האלה ב-*.te קבצים (התוסף ל-SELinux) קובצי מקור של המדיניות) בתוך /device/manufacturer/device-name/sepolicy את הספרייה ולהשתמש במשתנים ב-BOARD_SEPOLICY כדי לכלול אותם את ה-build שלך.
  7. ודאו שדומיינים חדשים יהיו מותרים בהתחלה. לשם כך, נדרשת הצהרה בקובץ .te של הדומיין.
  8. ניתוח התוצאות וצמצום הגדרות הדומיין.
  9. הסרת ההצהרה המתקנת אם לא מופיעות דחיות נוספות ב-Userdebug לבנות.

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

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

כדי למנוע בעיות מיותרות, עדיף להשתמש ביותר מדי תואם מדי מאשר מגביל מדי ולא תואם, וגורם לשיבושים של המכשיר. לעומת זאת, אם השינויים שלך יועילו לאחרים, לשלוח את השינויים למדיניות ברירת המחדל של SELinux בתור patch. אם התיקון הוחלה על מדיניות האבטחה המוגדרת כברירת מחדל, לא יהיה צורך לבצע את השינוי הזה באמצעות בכל מהדורה חדשה של 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 פקודות מאקרו (קיצור):

# 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 };

ננתח את הדוגמה:

בשורה הראשונה, הצהרת הסוג, הדימון (daemon) של 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, שקעי Datagram וזרם UNIX שקעים. DHCP יכול לקרוא ולכתוב רק משקעי ה-datagram ומ-UNIX sockets ולא ליצור או לפתוח אותם.

אמצעי בקרה זמינים

דרגה הרשאה
קובץ 
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 של SELinux נאכפים עכשיו בכל המכשירים.

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

כלל 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
הצגת דף הגבר של ptrace. sys_ptrace מעניקה את היכולת ptrace לכל תהליך, וכך שליטה על תהליכים אחרים והם צריכים להיות שייכים רק למערכת ייעודית הרכיבים המתוארים בכלל. הצורך ביכולות האלה בדרך כלל מצביע על את הנוכחות של משהו שלא מיועד לגרסאות build שניתנות למשתמשים או פונקציונליות שלא נחוצה לה. מסירים את הרכיב הלא נחוץ.

כלל 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 בפרויקט קוד פתוח של Android (AOSP) תוספי SEPolicy. מידע נוסף על אופן השמירה של המדיניות של SELinux שתואמים למחיצות ולגרסאות Android שונות. תאימות.

מיקום המדיניות

ב-Android 7.0 ובגרסאות קודמות, יצרני מכשירים יכולים להוסיף מדיניות BOARD_SEPOLICY_DIRS, כולל מדיניות שנועדה להרחיב את מדיניות AOSP בסוגים שונים של מכשירים. ב-Android מגרסה 8.0 ואילך, הוספת מדיניות ל BOARD_SEPOLICY_DIRS מציבה את המדיניות רק אצל הספק תמונה.

ב-Android מגרסה 8.0 ואילך, המדיניות חלה במיקומים הבאים ב-AOSP:

  • system/sepolicy/public. כולל מדיניות שמיוצאת לשימוש במדיניות הספציפית לספק. הכול מגיע אל Android 8.0 תשתית תאימות. המדיניות הציבורית צריכה להיות קבועה בגרסאות שונות, לכן אפשר לכלול את כל /public במדיניות המותאמת אישית. לכן, סוג המדיניות שניתן להציב ב/public הוא יותר מוגבלת. כדאי לקחת בחשבון את ה-API הזה של מדיניות הייצוא של הפלטפורמה: כל מתייחסת לממשק בין /system /vendor שייך לכאן.
  • system/sepolicy/private. כולל מדיניות שנדרשת כדי התפקוד של תמונת המערכת, אבל המדיניות של הספק לגבי תמונות אין כל ידע עליהם.
  • system/sepolicy/ספק. כוללת מדיניות בנושא רכיבים עוברים ב-/vendor אבל נמצאים בעץ הפלטפורמה המרכזית (לא ספריות ספציפיות למכשיר). זהו פריט מידע שנוצר בתהליך הפיתוח (Artifact) של מערכת ה-build הבחנה בין מכשירים ורכיבים גלובליים; מבחינה רעיונית, חלק מהמדיניות הספציפית למכשיר שמתוארת בהמשך.
  • device/manufacturer/device-name/sepolicy. כולל מדיניות ספציפית למכשיר. כולל גם התאמות אישיות של מכשירים עבור , אשר ב-Android 8.0 ואילך תואמת למדיניות בנושא רכיבים בתמונת הספק.

ב-Android מגרסה 11 ואילך, מחיצות system_ext ומחיצות מוצרים יכולות לכלול גם כללי מדיניות ספציפיים למחיצות. System_ext, וכללי מדיניות מוצרים מתחלקים גם הם ציבורי ופרטי, וספקים יכולים להשתמש ברכיבים הציבוריים של system_ext ושל product כללי מדיניות, למשל מדיניות המערכת.

  • SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS כולל מדיניות שיוצאו עבור לשימוש במדיניות ספציפית לספק. הותקן במחיצת system_ext.
  • SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS כולל מדיניות הנדרשת לתפקוד של תמונת system_ext, אבל איזו תמונה של ספק ולא אמורים להיות מודעים למדיניות. הותקן במחיצת system_ext.
  • PRODUCT_PUBLIC_SEPOLICY_DIRS כולל מדיניות שיוצאו עבור לשימוש במדיניות ספציפית לספק. מותקן בקטגוריית המוצרים.
  • PRODUCT_PRIVATE_SEPOLICY_DIRS כולל מדיניות שנדרשת כדי התפקוד של תמונת המוצר, אבל לגבי המדיניות בנושא תמונות של הספק לא אמור להיות ידע כלל. מותקן בקטגוריית המוצרים.
הערה: כשמשתמשים ב-GSI, מחיצות ה-system_ext ומחיצות המוצרים של ה-OEM לא יעשו את זה שצריך לטעון. הכללים במדיניות בנושא ספקים שמשתמשים במאפיינים system_ext של ה-OEM המדיניות הציבורית של המוצר הופכת ל-NOP כי הגדרות הסוג הספציפיות ל-OEM (יצרן הציוד המקורי) חסר.
הערה: מומלץ להיזהר מאוד כשמשתמשים במדיניות system_ext ובמדיניות ציבורית של מוצרים. כללי המדיניות הציבוריים פועלים כ-API מיוצא בין system_ext/product לספק. השותפים אמורים לנהל את בעיות התאימות בעצמם.

תרחישים נתמכים במדיניות

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

תוספי תמונות בלבד של ספקים

לדוגמה: הוספת שירות חדש אל vndservicemanager מתמונת הספק שתומכת בתהליכים בתמונת הספק.

כמו במכשירים שמושקים עם גרסאות Android קודמות, מוסיפים גרסאות ספציפיות למכשיר התאמה אישית של device/manufacturer/device-name/sepolicy מדיניות חדשה שקובעת את האינטראקציות של רכיבים של ספקים עם ספק אחר (רק) חייבים לכלול סוגים שקיימים רק device/manufacturer/device-name/sepolicy המדיניות שכתובה כאן מאפשרת לקוד של הספק לעבוד, אבל היא לא תעודכן כחלק מהמדיניות של OTA רק ל-framework, והוא יופיע במדיניות המשולבת במכשיר עם קובץ האימג' של מערכת ה-AOSP.

תמיכה בתמונות של ספקים עם AOSP

דוגמה: הוספת תהליך חדש (נרשמת באמצעות hwservicemanager מתמונת הספק) שמטמיע HAL בהגדרת AOSP.

בדומה למכשירים שמושקים עם גרסאות Android קודמות, מבצעים התאמה אישית ספציפית למכשיר device/manufacturer/device-name/sepolicy המדיניות שמיוצאת כחלק מ-system/sepolicy/public/ זמינה לשימוש והוא נשלח כחלק ממדיניות הספק. סוגים ומאפיינים מ- אפשר להשתמש במדיניות הציבורית בכללים חדשים שמכתיבים את האינטראקציות עם ביטים ספציפיים לספק, בכפוף ל-neverallow שצוין ההגבלות. בדומה למקרה של ספק בלבד, המדיניות החדשה כאן לא תעודכן כחלק ממדיניות OTA של מסגרת בלבד, והם יופיעו במדיניות המשולבת מכשיר עם תמונת מערכת AOSP.

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

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

צריך להוסיף את המדיניות הזו אל 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 מוסיפה את המורכבות שלו באמצעות חשיפת אחריות תאימות חדשה שצריך לעקוב אחריה של מפות Google, ושכפוף להגבלות נוספות. רק סוגים חדשים אפשר להוסיף כללי הרשאה תואמים ב-system/sepolicy/public; אין תמיכה במאפיינים ובהצהרות אחרות של המדיניות. בנוסף, חדשות לא ניתן להשתמש בסוגים ציבוריים כדי לתייג אובייקטים באופן ישיר המדיניות בנושא /vendor.

תרחישים של מדיניות שלא נתמכים

מכשירים שמושקים עם Android 8.0 ואילך לא תומכים ודוגמאות.

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

דוגמה: תהליך מערכת חדש שאינו AOSP, שדורש נוסף בגרסה הבאה של Android וזקוק לגישה ללא AOSP HAL.

דומה ל- חדש (שאינם AOSP) ורכיבי ספק, מלבד המערכת החדשה מוכנס OTA רק ב-framework. למרות שניתן להוסיף את הסוג החדש למדיניות בנושאים system/sepolicy/public, מדיניות הספק הקיימת לא מבוססת על ידע מהסוג החדש, כי הוא עוקב רק אחרי המדיניות הציבורית של מערכת Android 8.0. שירות AOSP מטפל בכך באמצעות מאפיין (למשל, את המשאבים שסופקו על ידי הספק), hal_foo), אבל מכיוון שתוספי שותף לא נחשבים כמאפיינים, נתמכת ב-system/sepolicy/public, השיטה הזו לא זמינה ל- מדיניות הספק. צריכה להיות גישה מסוג ציבורי שכבר היה קיים.

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

המדיניות על תמונת המערכת חייבת להיכתב ללא ידע והתאמות אישיות לספקים. לכן, המדיניות בנוגע לממשקים ספציפיים ב-AOSP נחשפות דרך מאפיינים במערכת/במדיניות Sepolicy/ציבורית, כדי שמדיניות הספק להביע הסכמה למדיניות מערכת עתידית שמשתמשת במאפיינים האלה. אבל, לפעמים תוספי מאפיינים ב-system/sepolicy/public לא יש תמיכה, לכן כל כללי המדיניות שקובעים את האינטראקציה בין רכיבי המערכת ברכיבי ספק חדשים (ושלא מטופלות באמצעות מאפיינים שכבר מטופלים שנמצאים ב-AOSP system/sepolicy/public) חייבים להיות device/manufacturer/device-name/sepolicy המשמעות היא שלא ניתן לשנות את סוגי המערכות הרשאת הגישה שמותרת לסוגי ספקים כחלק מ-OTA של מסגרת בלבד.