גוגל מחויבת לקדם הון גזעי עבור קהילות שחורות. תראה איך.
דף זה תורגם על ידי Cloud Translation API.
Switch to English

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

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

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

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

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

וזכור לא:

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

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

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

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

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

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

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

התאמה אישית של SEPolicy באנדרואיד 8.0 ומעלה

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

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

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

באנדרואיד 8.0 ומעלה המדיניות קיימת במיקומים הבאים ב- AOSP:

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

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

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

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

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

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

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

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

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

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

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

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

תוספי תמונת יצרן המגישים רכיבי AOSP מורחבים

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

מדיניות לאינטראקציה בין מערכת device/ manufacturer / device-name /sepolicy בספריית 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 אחרים של system/sepolicy/private או לשנות (בכל דרך שהיא משפיעה על מדיניות) כתוצאה מעדכון למסגרת בלבד. המדיניות עשויה להשתנות ב- OTA למסגרת בלבד, אך לא תהיה נוכחת בעת שימוש בתמונת מערכת AOSP (שגם בה לא יהיה רכיב המערכת החדש).

תוספי תמונת יצרן המגישים רכיבי מערכת חדשים

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

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

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

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

מכשירים המשיקים באמצעות Android 8.0 ומעלה אינם תומכים בתרחיש המדיניות והדוגמאות שלהלן.

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

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

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

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

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