הטמעת SELinux

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

קבצים של מפתחות

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

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

קובצי מדיניות

קבצים שמסתיימים ב-*.te הם קובצי מקור של מדיניות SELinux, להגדיר את הדומיינים ואת התוויות שלהם. יכול להיות שתצטרכו ליצור קובצי מדיניות חדשים ב- /device/manufacturer/device-name/sepolicy, אבל מומלץ לנסות לעדכן קבצים קיימים במידת האפשר.

קובצי הקשר

קובצי הקשר הם המקום שבו מציינים את התוויות לאובייקטים.

  • file_contexts מקצה תוויות לקבצים ומשתמשת בהם לרכיבים של מרחב המשתמש. כשיוצרים כללי מדיניות חדשים, צריך ליצור או לעדכן את הקובץ כדי להקצות תוויות חדשות לקבצים. כדי להחיל את file_contexts החדש, לבנות מחדש את קובץ האימג' של מערכת הקבצים או להריץ את הפקודה restorecon על הקובץ תתויג מחדש. בשדרוגים, השינויים ב-file_contexts חלים מיושמת באופן אוטומטי על המערכת ועל מחיצות נתוני המשתמש לשדרג. ניתן להחיל את השינויים גם באופן אוטומטי בעת השדרוג לקמפיינים אחרים מחיצות על ידי הוספת קריאות restorecon_recursive init.board.rc אחרי טעינת המחיצה קריאה-כתיבה.
  • genfs_contexts מקצה תוויות למערכות קבצים, כמו proc או vfat שלא תומכים בתכונה 'מורחבים' . ההגדרות האישיות האלה נטענות כחלק ממדיניות הליבה, אבל ייתכן שהשינויים לא ייכנסו לתוקף עבור צמתי inode בתוך ליבה, שמחייבים הפעלה מחדש או לנתק ולטעון מחדש את מערכת הקבצים כדי להחיל את השינוי באופן מלא. אפשר גם להקצות תוויות ספציפיות לטעינות ספציפיות, כמו vfat באמצעות האפשרות context=mount.
  • property_contexts מקצה תוויות למאפייני מערכת Android עבור כדי לקבוע אילו תהליכים יכולים להגדיר אותם. התצורה הזו קוראת על ידי תהליך init במהלך ההפעלה.
  • service_contexts מקצה תוויות לשירותי binder ב-Android עבור לקבוע אילו תהליכים יכולים להוסיף (לרשום) ולמצוא (חיפוש) binder לגבי השירות. התצורה הזו קוראת על ידי תהליך servicemanager במהלך ההפעלה.
  • seapp_contexts מקצה תוויות לתהליכי אפליקציות ו ספריות /data/data. התצורה הזו קוראת על ידי תהליך zygote בכל השקה של אפליקציה ועל ידי installd במהלך ההפעלה.
  • mac_permissions.xml מקצה תג seinfo לאפליקציות על סמך החתימה שלהם ואופציונלי, לפי שם החבילה שלהם. לאחר מכן אפשר יהיה להשתמש בתג seinfo כמפתח seapp_contexts להקצאת תווית ספציפית לכל האפליקציות שבהן את התג seinfo. התצורה הזו קוראת על ידי system_server במהלך ההפעלה.
  • keystore2_key_contexts מקצה תוויות למרחבי שמות של Keystore 2.0. מרחב השמות הזה נאכף על ידי הדימון (daemon) של keystore2. ב-Keystore תמיד יש מרחבי שמות שסופקו על ידי UID/AID. Keystore 2.0 אוכף גם מדיניות מדיניות מרחבי שמות מוגדרים. תיאור מפורט של הפורמט והמוסכמות בתהליך הזה כאן אפשר למצוא את הקובץ הזה.

BoardConfig.mk makefile

אחרי העריכה או ההוספה של קובצי מדיניות וקובצי הקשר, מעדכנים את /device/manufacturer/device-name/BoardConfig.mk getfile כדי להפנות לספריית המשנה sepolicy ולכל קובץ מדיניות חדש. מידע נוסף על המשתנים BOARD_SEPOLICY זמין בכתובת קובץ system/sepolicy/README.

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

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

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

הטמעה

כדי להתחיל להשתמש ב-SELinux:

  1. מפעילים את SELinux בליבה: CONFIG_SECURITY_SELINUX=y
  2. משנים את הפרמטר kernel_cmdline או startconfig כך: 
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    או 
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
    הבקשה הזו מיועדת רק לפיתוח ראשוני של מדיניות למכשיר. אחרי יש מדיניות אתחול ראשונית, יש להסיר את הפרמטר הזה כדי נאכף על ידי המכשיר, אחרת הוא ייכשל ב-CTS.
  3. יש להפעיל את המערכת באופן מתירני ולראות אילו דחיות של נתונים מתרחשות במהלך ההפעלה:
    ב-Ubuntu 14.04 ואילך: 
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
    ב-Ubuntu 12.04: 
    adb pull /sys/fs/selinux/policy
adb logcat -b all | audit2allow -p policy
  4. הערכת הפלט של אזהרות שדומות ל-init: Warning! Service name needs a SELinux domain defined; please fix!: אימות להוראות וכלים.
  5. מזהים מכשירים וקבצים חדשים אחרים שצריך להוסיף להם תוויות.
  6. שימוש בתוויות קיימות או חדשות לאובייקטים. אני רוצה לראות *_contexts קבצים כדי לראות איך דברים תויגו בעבר ולהשתמש בידע של משמעות התווית כדי להקצות תווית חדשה. במצב אידיאלי, זו תהיה תווית קיימת שתתאים למדיניות, אבל לפעמים תצטרכו תווית חדשה, וכללי גישה לתווית הזו יהיו. הדרושים. מוסיפים את התוויות לקובצי ההקשר המתאימים.
  7. לזהות דומיינים/תהליכים שצריכים להיות להם דומיינים מאובטחים משלהם. סביר להניח שתצטרכו לכתוב מדיניות חדשה לחלוטין לכל אחד מהם. הכול בשירותים שמקורם ב-init, למשל, צריכים להיות שלו. הפקודות הבאות עוזרות לחשוף את אלה שנשארות פעילות (אבל ALL שירותים שנדרשים להם טיפול כזה):
    adb shell su -c ps -Z | grep init

    adb shell su -c dmesg | grep 'avc: '
  8. צריך לבדוק את init.device.rc כדי לזהות דומיינים אין סוג דומיין. כדאי להקצות לו דומיין מוקדם תהליך פיתוח כדי להימנע מהוספת כללים ל-init או אחרת, הגישות של init מבלבלות עם אלו שנמצאים מדיניות של עצמו.
  9. הגדרה של BOARD_CONFIG.mk לשימוש בBOARD_SEPOLICY_* משתנים. לצפייה README בsystem/sepolicy לפרטים על תהליך ההגדרה.
  10. בודקים את הקובץ init.device.rc ו-fstab.device ו צריך לוודא שכל שימוש ב-mount תואם של מערכת קבצים מתויגת, או שהאפשרות context= mount היא שצוין.
  11. יש לעבור על כל דחייה וליצור מדיניות SELinux כדי לטפל בכל אחת מהן כראוי. צפייה את הדוגמאות בקטע התאמה אישית.

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

תרחישים לדוגמה

הנה כמה דוגמאות ספציפיות של ניצולים שכדאי לשקול כשיוצרים תוכנות SELinux וכללי מדיניות SELinux המשויכים:

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

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

קובצי מערכת – חשוב להביא בחשבון את הסוג של קובצי המערכת רק על ידי שרת המערכת לשנות. עדיין, מאז netd, האפליקציות init ו-vold פועלות ברמה הבסיסית (root), ויש להן גישה קובצי המערכת האלה. לכן, אם netd ייפרץ, הוא עלול לסכן את הקבצים האלה ואולי גם את שרת המערכת עצמו.

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

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

setattr – לפקודות כמו chmod ו- chown, יש לך אפשרות לזהות את קבוצת הקבצים שבה הדומיין יכול לערוך setattr. כל דבר מעבר לזה יכול להיות אסורים בעקבות שינויים כאלה, גם ברמת השורש. לכן אפליקציה עשויה לפעול chmod ו-chown לעומת אלה שתויגו app_data_files אבל לא shell_data_files או system_data_files.