עיינו בדף הזה כדי להכיר את המושגים של SELinux.
בקרת גישה חיונית
אבטחה משופרת של Linux (SELinux), היא מערכת בקרת גישה (MAC) במערכת ההפעלה Linux. בתור מערכת MAC, היא שונה במערכת המוכרת לבקרת גישה לפי שיקול דעת (DAC). במערכת DAC, קונספט של בעלות, כאשר הבעלים של משאב מסוים שולט בגישה ההרשאות המשויכות אליו. בדרך כלל מדובר בפירוט גס להסלמת הרשאות (privilege escalation) ללא כוונה. עם זאת, מערכת MAC מעבירה ייעוץ לקבלת החלטה לגבי כל ניסיונות הגישה.
SELinux הוטמע כחלק ממודול האבטחה של Linux (LSM) framework, שמזהה אובייקטי ליבה שונים ופעולות רגישות לבצע בהם פעולות. בנקודה שבה כל אחת מהפעולות האלה מבוצעת, פונקציית הוק (hook) LSM מופעלת כדי לקבוע אם פעולה זו צריכה להתבצע על סמך המידע עבורו שמאוחסן באופן אטום אובייקט אבטחה זה. SELinux מספק הטמעה של ההוקים (hooks) האלה ניהול של יעדי האבטחה האלה, שמשתלבים עם המדיניות של החברה, כדי הן יקבעו את החלטות הגישה.
אמצעי האבטחה של Android נוספים, וגם בקרת הגישה של Android שמגבילה מאוד את הנזק הפוטנציאלי של מכונות שנפגעו חשבונות. שימוש בכלים כמו הרשאות הגישה הנדרשות והלפי שיקול הדעת של Android מספקות מבנה שיאפשר לכם לוודא שהתוכנה תפעל רק ברמת ההרשאה. כך מצמצמים את ההשפעות של מתקפות ומפחיתים את הסיכון שיש סבירות גבוהה שתהליכים שגויים יחליפו נתונים או אפילו ישדרו נתונים.
ב-Android מגרסה 4.3 ואילך, SELinux מספק בקרת גישה (MAC) מטרייה על סביבות מסורתיות של בקרת גישה לפי שיקול דעת (DAC). עבור מכונה, בדרך כלל התוכנה חייבת לרוץ כחשבון משתמש ברמה הבסיסית כדי לכתוב לקובץ RAW והתקני בלוקים. בסביבת Linux מסורתית המבוססת על DAC, אם משתמש השורש בסיכון שמשתמש יוכל לכתוב לכל מכשיר בלוקים גולמיים. אבל, לפעמים אפשר להשתמש ב-SELinux כדי להוסיף תוויות למכשירים האלה כך שהתהליך הוקצה לרמה הבסיסית (root) ההרשאה יכולה לכתוב רק למי שצוינו במדיניות המשויכת. כאן כן, התהליך לא יכול להחליף נתונים והגדרות מערכת מחוץ מכשיר RAW ספציפי.
תרחישים לדוגמה כדי לקבל דוגמאות נוספות לאיומים ודרכים לטפל בהם באמצעות SELinux.
רמות האכיפה
ניתן להטמיע SELinux במצבים שונים:
- מורשה - מדיניות האבטחה של SELinux לא נאכפת, היא רק רשומה ביומן.
- אכיפה – מדיניות האבטחה נאכפת ונרשמת ביומן. פעולות שנכשלו מופיעות כשגיאות EPERM.
בחירה זו היא בינארית והיא קובעת אם המדיניות נוקטת פעולה או רק מאפשרת לאסוף כשלים אפשריים. הענקת גישה שימושית במיוחד במהלך יישום בפועל.
סוגים, מאפיינים וכללים
מערכת Android מסתמכת על רכיב אכיפת הסוג (TE) של SELinux בשביל
המדיניות בנושא כלומר, לכל האובייקטים (כמו קובץ, תהליך או שקע) יש
type המשויך אליהם. לדוגמה, כברירת מחדל, אפליקציה
יהיה מסוג untrusted_app. עבור תהליך, הסוג שלו הוא גם
נקרא הדומיין שלו. אפשר להוסיף הערות לסוג
מאפיינים רבים. כדאי להשתמש במאפיינים כדי להתייחס לכמה סוגים
בו-זמנית.
האובייקטים ממופים למחלקות
(למשל קובץ, ספרייה, קישור סימבולי, socket) וסוגי הגישה השונים
של כל מחלקה מיוצגת על ידי הרשאות.
למשל, ההרשאה open קיימת בשביל המחלקה
file. אמנם הסוגים והמאפיינים מתעדכנים באופן קבוע כחלק
המדיניות של Android SELinux, ההרשאות והמחלקות מוגדרות באופן סטטי
מתעדכנת לעיתים רחוקות כחלק מגרסה חדשה של Linux.
כלל של מדיניות מופיע בפורמט:
allow source target:class permissions;
איפה:
- מקור – הסוג (או המאפיין) של נושא הכלל. מי מבקש את הגישה?
- Target (יעד) – הסוג (או המאפיין) של האובייקט. למה התבקשת הרשאת הגישה?
- Class – סוג האובייקט (למשל, קובץ או socket) שמתבצעת אליו גישה.
- הרשאות - הפעולה (או קבוצת הפעולות) (למשל, קריאה, כתיבה) שמבוצעת.
דוגמה לכלל:
allow untrusted_app app_data_file:file { read write };
מצוין שהאפליקציות מורשות לקרוא ולכתוב קבצים עם תוויות
app_data_file קיימים סוגים אחרים של אפליקציות. עבור
מכונות, isolated_app משמש לשירותי אפליקציות עם
isolatedProcess=true במניפסט שלהם. במקום לחזור על
כלל לשני הסוגים, Android משתמש במאפיין בשם 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. כדי לפשט את הגדרת הכלל, Android
מספקת סדרה של פקודות מאקרו לטיפול במקרים הנפוצים ביותר. לדוגמה, לפי הסדר
כדי לכלול את ההרשאות החסרות כמו open, הכלל שלמעלה
ניתן לשכתב כך:
allow appdomain app_data_file:file rw_file_perms;
פרטים נוספים זמינים בglobal_macros
ו-te_macros
לדוגמה של פקודות מאקרו שימושיות. מומלץ להשתמש בפקודות מאקרו כשאפשר
כדי לעזור בצמצום הסבירות לכשלונות עקב דחיות של
הרשאות.
אחרי שמגדירים סוג, צריך לשייך אותו לקובץ או לתהליך. שהיא מייצגת. למידע נוסף, ראו יישום של SELinux לפרטים נוספים על האופן שבו השיוך הזה מתבצע. לקבלת מידע נוסף על לפי הכללים, notebook של 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)
ב-SELinux. החל מ-Android S, קטגוריות משמשות כדי:
- מבודדים את נתוני האפליקציה מלגשת לאפליקציה אחרת,
- לבודד את נתוני האפליקציה ממשתמש פיזי אחד לאחר.
ספציפיות
מערכת Android לא משתמשת בכל התכונות שמסופקות על ידי SELinux. בזמן הקריאה בתיעוד חיצוני, חשוב לזכור את הנקודות הבאות:
- רוב כללי המדיניות ב-AOSP מוגדרים באמצעות שפת מדיניות הליבה. יש כמה חריגים לשימוש בשפת ביניים נפוצה (CIL).
- משתמשי SELinux לא בשימוש. המשתמש היחיד שהוגדר הוא
uבמקרה הצורך, משתמשים פיזיים מיוצגים באמצעות שדה הקטגוריות בהקשר אבטחה. - התפקידים של SELinux ובקרת גישה מבוססת-תפקיד (RBAC) לא בשימוש. מגדירים שני תפקידי ברירת מחדל ומשתמשים בהם:
rלנושאים ו-object_rלאובייקטים. - אין שימוש ברגישות של SELinux. רגישות ברירת המחדל
s0תמיד מוגדרת. - לא נעשה שימוש בבוליאני של SELinux. ברגע שהמדיניות נוצרת עבור מכשיר, לא תלויה במצב המכשיר. זה מפשט את ביצוע ביקורת וניפוי באגים במדיניות.