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

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

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

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

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

וזכור לא:

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

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

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

  1. השתמש הקרנל אנדרואיד האחרון .
  2. אמץ לעצמך את העיקרון של לפחות פריבילגיה .
  3. התייחס רק לתוספות שלך לאנדרואיד. העבודות מדיניות ברירת המחדל עם פרויקט הקוד הפתוח אנדרואיד codebase אוטומטי.
  4. חלק את רכיבי התוכנה למודולים המבצעים משימות יחידות.
  5. צור מדיניות SELinux המבודדת משימות אלו מפונקציות שאינן קשורות.
  6. שים מדיניות אלה *.te קבצים (סיומת עבור קבצים ממקור מדיניות SELinux) בתוך /device/ manufacturer / device-name /sepolicy ספרייה ושימוש BOARD_SEPOLICY משתנים לכלול אותם לבנות שלך.
  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 };

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

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

הצבת מדיניות

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

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

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

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

הערה: כאשר GSI משמש, מחיצות system_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 (כגון system_server מורחבת).

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

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