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

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

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

וזכור לא:

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

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

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

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

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

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

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

הצהרות מדיניות לדוגמה

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

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

בשורה הראשונה, הצהרת הסוג, הדמון 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 רשאי לקרוא ולכתוב רק משקעי ה-Datagram ושקעי זרם 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 במהלך התאמה אישית. מספרי הכללים המשמשים כאן תואמים לאנדרואיד 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 .

התאמה אישית של SEPoly ב-Android 8.0+

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

הצבת מדיניות

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

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

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

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

  • 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, מערכת_ext ומחיצות המוצר של OEM לא יותקנו. הכללים ב-sepolicy של הספק המשתמש ב-system_ext של OEM ובמדיניות הציבורית של המוצר הופכים ל-NOP מכיוון שחסרות הגדרות הסוג הספציפיות ל-OEM.
הערה: היזהר במיוחד בעת שימוש במדיניות ציבורית של system_ext ומוצר. מדיניות ציבורית פועלת כ-API מיוצא בין system_ext/product לבין הספק. שותפים אמורים לנהל בעצמם בעיות תאימות.

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

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

הרחבות לתמונת ספק בלבד

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

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

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

דוגמה : הוספת תהליך חדש (רשום ב- hwservicemanager הספק) שמיישם HAL המוגדר ב-AOSP.

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

הרחבות לתמונת מערכת בלבד

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

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

הרחבות תמונת ספק המשרתות רכיבי AOSP מורחבים

דוגמה: HAL חדש שאינו AOSP לשימוש על ידי לקוחות מורחבים הקיימים גם בתמונת מערכת AOSP (כגון שרת_מערכת מורחב).

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

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

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