דף זה תורגם על ידי Cloud Translation API.

הטמעת SELinux

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

קבצי מפתח

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

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

קבצי מדיניות

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

קבצי הקשר

קובצי הקשר הם המקום שבו אתה מציין תוויות עבור האובייקטים שלך.

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

קובץ makeup BoardConfig.mk

לאחר עריכה או הוספת קובצי מדיניות והקשר, עדכן את הקובץ /device/ manufacturer / device-name /BoardConfig.mk makefile שלך כדי להפנות את ספריית המשנה של 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 שלך כדי להתאים את התוספות שלך למערכת ההפעלה אנדרואיד כמתואר בהתאמה אישית או לאמת את ההגדרה הקיימת שלך כפי שמכוסה באימות .

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

יישום

כדי להתחיל עם SELinux:

הפעל SELinux בקרנל: CONFIG_SECURITY_SELINUX=y
שנה את הפרמטר kernel_cmdline או bootconfig כך:
```
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
```
או
```
BOARD_BOOTCONFIG := androidboot.selinux=permissive
```
זה מיועד רק לפיתוח ראשוני של מדיניות עבור המכשיר. לאחר שתהיה לך מדיניות אתחול ראשונית, הסר את הפרמטר הזה כדי שהמכשיר שלך אוכף או שהוא ייכשל ב-CTS.

הפעל את המערכת באופן מתירני וראה אילו הכחשות נתקלות באתחול:
באובונטו 14.04 ומעלה:

adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy

באובונטו 12.04:

adb pull /sys/fs/selinux/policy
adb logcat -b all | audit2allow -p policy

הערך את הפלט עבור אזהרות הדומות ל- init: Warning! Service name needs a SELinux domain defined; please fix! ראה אימות להוראות וכלים.
זהה התקנים וקבצים חדשים אחרים שצריכים תיוג.
השתמש בתוויות קיימות או חדשות עבור האובייקטים שלך. עיין *_contexts כדי לראות כיצד דברים סומנו בעבר והשתמש בידע של משמעויות התווית כדי להקצות מילה חדשה. באופן אידיאלי, זו תהיה תווית קיימת שתתאים למדיניות, אך לפעמים יהיה צורך בתווית חדשה, ויהיה צורך בכללים לגישה לתווית זו. הוסף את התוויות שלך לקובצי ההקשר המתאימים.
זהה תחומים/תהליכים שצריכים להיות להם תחומי אבטחה משלהם. סביר להניח שתצטרך לכתוב מדיניות חדשה לחלוטין עבור כל אחד מהם. לכל השירותים שנוצרו מ- init , למשל, צריכים להיות משלהם. הפקודות הבאות עוזרות לחשוף את אלו שנותרו לפעול (אך כל השירותים זקוקים לטיפול כזה):
```
adb shell su -c ps -Z | grep init
```
```
adb shell su -c dmesg | grep 'avc: '
```
בדוק init. device .rc כדי לזהות דומיינים שאין להם סוג דומיין. תן להם דומיין מוקדם בתהליך הפיתוח שלך כדי להימנע מהוספת כללים ל- init או מבלבול אחר של גישה ל- init עם אלה שנמצאות במדיניות שלהם.
הגדר את BOARD_CONFIG.mk לשימוש BOARD_SEPOLICY_* . עיין ב- README ב- system/sepolicy לפרטים על הגדרת זה.
בדוק את ה-init. device rc ו-fstab. קובץ device וודא שכל שימוש ב- mount תואם למערכת קבצים מסומנת כהלכה או שצוינה אפשרות context= mount .
עברו על כל הכחשה וצרו מדיניות SELinux כדי לטפל כראוי בכל אחת מהן. ראה את הדוגמאות בהתאמה אישית .

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

מקרי שימוש

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

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

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

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

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

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

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