מושגי SELinux

עיין בדף זה כדי להכיר את המושגים של SELinux.

בקרת כניסה חובה

Security Enhanced Linux (SELinux), היא מערכת בקרת גישה חובה (MAC) עבור מערכת ההפעלה לינוקס. כמערכת MAC, היא שונה ממערכת בקרת הגישה לפי שיקול דעת (DAC) המוכרת של לינוקס. במערכת DAC, קיים מושג של בעלות, לפיו בעלים של משאב מסוים שולט בהרשאות הגישה הקשורות אליו. זה בדרך כלל גס ונתון להסלמה בלתי מכוונת של זכויות יתר. מערכת MAC, לעומת זאת, מתייעצת עם רשות מרכזית לקבלת החלטה על כל ניסיונות הגישה.

SELinux הוטמע כחלק ממסגרת Linux Security Module (LSM), המזהה אובייקטי ליבה שונים, ופעולות רגישות המבוצעות עליהם. בנקודה שבה כל אחת מהפעולות הללו תתבצע, נקראת פונקציית Hook LSM כדי לקבוע אם יש לאפשר את הפעולה או לא בהתבסס על המידע עבורה המאוחסן באובייקט אבטחה אטום. SELinux מספקת יישום ל-hooks וניהול של אובייקטי אבטחה אלה, המשולבים עם מדיניות משלה, כדי לקבוע את החלטות הגישה.

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

באנדרואיד 4.3 ומעלה, SELinux מספקת מטריית בקרת גישה חובה (MAC) על פני סביבות בקרת גישה לפי שיקול דעת (DAC). לדוגמה, תוכנה חייבת לפעול בדרך כלל כחשבון המשתמש הבסיסי כדי לכתוב למכשירי בלוק גולמי. בסביבת לינוקס מסורתית מבוססת DAC, אם משתמש השורש נפגע, המשתמש יכול לכתוב לכל מכשיר בלוק גולמי. עם זאת, ניתן להשתמש ב-SELinux כדי לתייג מכשירים אלו כך שהתהליך שהוקצה לו הרשאת השורש יכול לכתוב רק לאלה שצוינו במדיניות המשויכת. בדרך זו, התהליך אינו יכול לדרוס נתונים והגדרות מערכת מחוץ להתקן ה-raw block הספציפי.

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

רמות אכיפה

ניתן ליישם את SELinux במצבים שונים:

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

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

סוגים, תכונות וחוקים

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

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

כלל מדיניות מגיע בצורה: allow source target : class permissions ; איפה:

  • מקור - הסוג (או התכונה) של נושא הכלל. מי מבקש את הגישה?
  • יעד - הסוג (או התכונה) של האובייקט. למה מתבקשת הגישה?
  • Class - סוג האובייקט (למשל קובץ, שקע) אליו ניגשים.
  • הרשאות - הפעולה (או קבוצת הפעולות) (למשל קריאה, כתיבה) המתבצעת.

דוגמה לכלל היא:

allow untrusted_app app_data_file:file { read write };

זה אומר שלאפליקציות מותר לקרוא ולכתוב קבצים שכותרתם app_data_file . קיימים סוגים אחרים לאפליקציות. לדוגמה, isolated_app משמש לשירותי אפליקציות עם isolatedProcess=true במניפסט שלהם. במקום לחזור על הכלל עבור שני הסוגים, אנדרואיד משתמשת בתכונה בשם appdomain עבור כל הסוגים המכסה אפליקציות:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

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

  • domain - תכונה הקשורה לכל סוגי התהליך,
  • file_type - תכונה המשויכת לכל סוגי הקבצים.

מאקרו

עבור גישה לקבצים במיוחד, ישנם סוגים רבים של הרשאות שיש לקחת בחשבון. לדוגמא, הרשאת read אינה מספיקה כדי לפתוח את הקובץ או להתקשר stat עליו. כדי לפשט את הגדרת הכלל, אנדרואיד מספקת קבוצה של פקודות מאקרו לטיפול במקרים הנפוצים ביותר. לדוגמה, על מנת לכלול את ההרשאות החסרות כגון open , ניתן לשכתב את הכלל שלמעלה כך:

allow appdomain app_data_file:file rw_file_perms;

עיין global_macros ו-te_macros te_macros נוספות של פקודות מאקרו שימושיות. יש להשתמש בפקודות מאקרו במידת האפשר כדי לעזור להפחית את הסבירות לכשלים עקב דחיות בהרשאות קשורות.

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

הקשר וקטגוריות אבטחה

בעת ניפוי באגים במדיניות SELinux או תיוג קבצים (באמצעות file_contexts או בעת הפעלת ls -Z ), אתה עלול להיתקל בהקשר אבטחה (המכונה גם תווית ). לדוגמה: u:r:untrusted_app:s0:c15,c256,c513,c768 . להקשר אבטחה יש את הפורמט: user:role:type:sensitivity[:categories] . בדרך כלל אתה יכול להתעלם משדות user , role sensitivity של הקשר (ראה ספציפיות ). שדה type מוסבר בסעיף הקודם. categories הן חלק מהתמיכה ב- MLS (Multi-Level Security) ב-SELinux. מאז Android S, הקטגוריות משמשות ל:

  • לבודד את נתוני האפליקציה מגישה של אפליקציה אחרת,
  • בודד את נתוני האפליקציה ממשתמש פיזי אחד לאחר.

ספֵּצִיפִיוּת

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

  • רוב המדיניות ב-AOSP מוגדרת באמצעות שפת מדיניות הליבה. ישנם כמה חריגים לשימוש בשפת ביניים משותפת (CIL).
  • לא נעשה שימוש במשתמשי SELinux. המשתמש היחיד שהוגדר הוא u . בעת הצורך, משתמשים פיזיים מיוצגים באמצעות שדה הקטגוריות של הקשר אבטחה.
  • לא נעשה שימוש בתפקידי SELinux ובקרת גישה מבוססת תפקידים (RBAC). שני תפקידי ברירת מחדל מוגדרים ומשמשים: r עבור נושאים ו- object_r עבור אובייקטים.
  • לא נעשה שימוש ברגישויות SELinux. ברירת המחדל של רגישות s0 מוגדרת תמיד.
  • לא נעשה שימוש בבוליאנים של SELinux. ברגע שהמדיניות נבנית עבור מכשיר, היא לא תלויה במצב המכשיר. זה מפשט את הביקורת וניפוי הבאגים של מדיניות.