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

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

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

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

מה זה SELinux ואיזו בעיה הוא פותר?

לינוקס משופרת אבטחה (SELinux) היא מודול אבטחה של ליבת לינוקס המבוסס על LSM (מודולי אבטחה של לינוקס). היא פותחה במקור על ידי ה-NSA בשיתוף פעולה עם רד האט ושותפים אחרים, ומאז גרסת ליבה 2.6, היא חלק רשמי מהליבה. זו אינה אפליקציה נפרדת, אלא הרחבת ליבה שמוסיפה מערכת בקרת גישה חובה (MAC) ובקרת גישה מבוססת תפקידים (RBAC).

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

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

SELinux אומצה כברירת מחדל בהפצות כמו Fedora, Red Hat Enterprise Linux, CentOS ו-Scientific Linux, והיא משולבת עמוק גם במערכות כמו אנדרואיד, שם היא משמשת להגבלת תהליכי מערכת ואפליקציות לתחומים ספציפיים מאוד. בעולם BSD ו-GNU/Linux, ישנן חלופות כמו AppArmor, TOMOYO ו-TrustedBSD (ב-macOS/FreeBSD), אך SELinux בולטת ברמת הפירוט שהיא מציעה על פני כל אובייקטי המערכת.

מ-DAC ל-MAC: מדוע המודל הקלאסי כבר לא מספיק

במערכת יוניקס מסורתית, מודל Domain-Object מנוהל באמצעות DAC: לכל קובץ או משאב יש בעלים והרשאות, וכל תהליך הפועל תחת אותו משתמש יכול לעשות כרצונו עם המשאבים הללו . משמעות הדבר היא שאם daemon פועל כ-root, כל באג שניתן לנצל יכול לפתוח את הדלת לשליטה בחצי המערכת באמצעות הקשר ה-root שלה.

דוגמאות אופייניות כוללות מסדי נתונים שקבצי הנתונים שלהם אמורים להיות מטופלים רק דרך מערכת ניהול הנתונים (DBMS), אך למעשה ניתנים לקריאה ולשינוי על ידי תהליכים עם UID הבסיסי ; או דמונים קריטיים הפועלים עם הרשאות מוגזמות. שגיאת תכנות, גלישת מאגר או אימות קלט לקוי יכולים להפוך את השירות לכביש מהיר למערכת כולה.

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

הליבה, באמצעות ווים של LSM, מבצעת שאילתה ל-SELinux על כל קריאה רגישה למערכת (פתיחת קבצים, יצירת sockets, הרכבת מערכות קבצים, תקשורת דרך IPC וכו'). בכל נקודת החלטה, SELinux מעריכה את הפעולה על סמך המדיניות שנטענה והקשר האבטחה של הסובייקט והאובייקט . אם המדיניות אינה מעניקה הרשאה במפורש, הפעולה נדחית, ללא קשר לשאלה האם התהליך הוא root או לא.

מצבי הפעלה: אכיפה, מתיר ומושבת

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

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

לשינויים מהירים וזמניים בין מצבי אכיפה למצבים מתירים, נעשה שימוש בפקודה `setenforce` , כאשר המצב מצוין כ-0 (מתיר) או 1 (אכיפה). חשוב לדעת ששינוי זה הוא תנודתי: לאחר אתחול מחדש הבא, המצב יחזור למצב שהוגדר בתצורה.

אם אתה זקוק לשינוי קבוע, עליך לערוך את הקובץ. /etc/selinux/config (או /etc/sysconfig/selinux בחלק מההפצות) והתאימו את ערך ההנחיה SELINUX=disabled|permissive|enforcingהשינויים יוחלו באתחול הבא, ובמקרים רבים, יכללו שינוי תיוג של מערכת הקבצים.

כדי לבדוק את המצב הפעיל, ניתן להשתמש בפקודות כמו getenforce או sestatus . הראשונה פשוט מחזירה Enforcing, Permissive או Disabled; השנייה מספקת סיכום מלא יותר של מצב SELinux, מדיניות טעונה ומודולים פעילים.

הקשרים ביטחוניים ומערכת תיוג

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

הפורמט הכללי של הקשר הוא user_u:role_r:type_t:level , עם כמה ניואנסים בהתאם למדיניות (במיוחד אם משתמשים ב-MLS/MCS). לכל שדה יש ​​מטרה ספציפית: משתמש SELinux, התפקיד, הסוג (הנקרא גם תחום כאשר מתייחסים לתהליכים), ורמת הרגישות או הקטגוריה.

בפועל, האלמנט הקריטי ביותר הוא הסוג (השדה השלישי), מכיוון שרובם המכריע של כללי המדיניות מנוסחים כקשרי גומלין בין סוגים . לדוגמה, מתן אפשרות לתהליכים מסוג httpd_t גישה לקבצים המסומנים httpd_sys_content_t, או מתן אפשרות לדומיין ספציפי לתקשר עם שקעים המסומנים http_port_t.

הקשרים אלה מאוחסנים כ תכונות מערכת קבצים מורחבותלכן, חיוני להשתמש במערכות קבצים התומכות ב-xattrs (כגון ext4, XFS וכו'). במקרה של תהליכים, ההקשר הנוכחי והקשרים קשורים אחרים חשופים דרך מערכת הקבצים המדומה. /proc/<pid>/attr/ בקבצים כגון current, exec, fscreate, prev, sockcreate או keycreate.

דוגמאות אופייניות להקשרים במערכת עם מדיניות ממוקדת יהיו:

• system_u:object_r:httpd_sys_content_t:s0 עבור תוכן אינטרנט המוגש על ידי Apache או Nginx.
• system_u:object_r:home_user_t:s0 עבור ספריות הבית של המשתמשים.
• system_u:system_r:httpd_t:s0 עבור תחום הביצוע של שרת האינטרנט עצמו.

פירוט רכיבי ההקשר של SELinux

כאשר נתקלים בהקשר כמו unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , זה אולי נראה כמו הירוגליפים, אבל כל חלק מתאים למושג ספציפי בתוך SELinux ומדיניות ההפניה שלו.

El משתמש SELinux (לפי המוסכמה עם סיומת) _uזה לא אותו דבר כמו משתמש יוניקס ב-/etc/passwd. SELinux מתחזקת מסד נתונים משלה וממפה אותם למשתמשי לינוקס. משתמש SELinux יכול לקבץ מספר משתמשי יוניקס, כי הרעיון הוא ששכבת ה-MAC תהיה בלתי תלויה ב-DAC.

El תפקיד SELinux (עם סיומת _rתפקיד זה מגדיר אילו תפקידים משתמש או תחום יכולים לאמץ. אם משתמשים בו בצורה מדויקת, זה נקרא RBAC מלא. רוב אובייקטי הקבצים משתמשים בתפקיד object_r, בעוד שתפקידים כמו system_r, user_r, staff_r או sysadm_r מוחלים על תהליכים בהתאם להקשר האבטחה שהם חייבים לאמץ.

El סוג או דומיין SELinux (סִיוֹמֶת _tבפועל, הסוג הוא המרכיב המכריע. הסוג מתאר את מחלקת האובייקט או את תחום הביצוע של תהליך. המדיניות מציינת אילו אינטראקציות מותרות בין סוגים: אילו תחומים יכולים לקרוא, לכתוב, לבצע או לתקשר עם אילו סוגי אובייקטים אחרים.

רמות וקטגוריות משמשות כאשר מדיניות אבטחה רב-שכבתית (MLS) או אבטחה רב-קטגוריות (MCS) מופעלת. רגישויות הן היררכיות (למשל, s0, s1 וכו'), בעוד שקטגוריות אינן (c0, c1, c2, ...). בסביבות קריטיות ביותר - לדוגמה, ארגוני ממשלה מסוימים - הן משמשות כדי להבטיח שניתן יהיה לקרוא נתונים רק כלפי מטה ולכתוב אותם לאותה רמה או כלפי מעלה , ולבודד נתונים לפי מדורים ספציפיים מאוד.

מדיניות SELinux: ממוקדת, קפדנית, MLS/MCS ומודולריות

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

המדיניות הנפוצה ביותר נקראת targeted . במצב זה, רק תהליכים ספציפיים - בעיקר שירותי רשת ודמונים בעלי סיכון גבוה כמו Apache, Nginx, DNS, proxies, SNMP, syslog וכו' - פועלים בתוך דומיינים מוגבלים. כל שאר תהליכי המשתמש פועלים בתחומים "לא מוגבלים", שבהם מוחל למעשה אבטחת לינוקס סטנדרטית, יחד עם רישום של פעולות מסוימות.

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

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

מדיניות מודרנית מופצת בצורה מודולרית . במקום קובץ מדיניות מונוליטי יחיד, מודולים נפרדים משמשים עבור שירותים ספציפיים, מה שמפשט מאוד את הניהול והעדכונים. מודולים אלה מנוהלים באמצעות כלים כמו semodule ו- semanage module , המאפשרים לך להתקין, להסיר, להפעיל או להשבית חלקים מהמדיניות מבלי לקמפל מחדש את כל המדיניות בכל פעם.

כיצד SELinux מחליטה: נושאים, אובייקטים, מחלקות והרשאות

כאשר תהליך (הנושא) מנסה לגשת למשאב (האובייקט), SELinux מציגה באופן מושגי את השאלה: "האם תחום מסוג X יכול לבצע את פעולה Y על אובייקט מסוג Z השייך למחלקה C?" . לאחר מכן, התשובה מבוקשה במדיניות באמצעות הכללים המוגדרים.

במדיניות אכיפת סוגים (TE), בהן משתמשים ברוב ההפצות וב-Android, כל אובייקט שייך למחלקה ( file, dir, fifo_file, tcp_socket, process וכו') והמדיניות מגדירה אילו הרשאות אפשריות עבור כל מחלקה: קריאה, כתיבה, ביצוע, קשירה, התחברות, getattr, פתיחה, וקובץ ארוך וכו'.

כללי TE באים לידי ביטוי בצורה ישירה מאוד. דוגמה בסיסית תהיה:

אפשר httpd_t http_port_t:tcp_socket name_bind;

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

באנדרואיד, לדוגמה, מאפייני SELinux משמשים לקיבוץ סוגים תחת תוויות כלליות יותר כמו `appdomain` , כך שכלל יחיד יכול לחול על מספר דומיינים (`untrusted_app`, `isolated_app` וכו') מבלי לחזור על הגדרות. פקודות מאקרו כמו `rw_file_perms` משמשות גם לקיבוץ מספר הרשאות קבצים נפוצות ולהפחתת שגיאות הנגרמות עקב חוסר תשומת לב.

סטטוסים פנימיים, AVC ורישום דחייה

כאשר מתרחשת בקשת גישה, SELinux מתייעצת תחילה עם Access Vector Cache (AVC) , מטמון המאחסן החלטות גישה אחרונות כדי להאיץ את התהליך. אם ההחלטה כבר נמצאת במטמון, הוא משמש ישירות; אחרת, חומת האש (החלק הפנימי של SELinux בליבת השרשרת) נבדקת, אשר מעריכה את הפעולה על סמך המדיניות וההקשר של הנושא והאובייקט.

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

כאשר מתרחשת דחייה במצב אכיפה, הליבה רושמת הודעה מסוג avc: נדחה ביומני המערכת. בהתאם להפצה, זה עשוי להופיע ב /var/log/audit/audit.logב /var/log/messages או להיקלט על ידי הדמון auditd. הודעות אלו כוללות את הקשר התהליך (context), הקשר האובייקט (tcontext), המחלקה, הפעולה המבוקשת ונתונים אחרים שימושיים מאוד לאיתור שגיאות.

במצב מתיר, הפעולה מותרת אך עדיין נוצר האירוע avc: denied , המסומן ב- permissive=1. זהו זהב טהור לבנייה והתאמת מדיניות, משום שהוא מאפשר לראות מה היה מפריע למערכת אם אכיפה הייתה מיושמת מבלי להפריע לפעולה הרגילה.

שילוב SELinux בהפצות ובאנדרואיד

במערכת האקולוגית של שרתים ושולחנות עבודה של לינוקס, SELinux מופעל כברירת מחדל ב- פדורה, RHEL, CentOS ונגזרותיהדביאן ואובונטו מספקות תמיכה מלאה בליבות ובחבילות שלהן, אם כי ההפעלה היא בדרך כלל אופציונלית ודורשת התקנת חבילות כגון selinux-basics, selinux-policy-default ו-auditd, ולאחר מכן תיוג מחדש גלובלי עם fixfiles relabel.

אנדרואיד שילבה בתחילה את SELinux בגרסה 4.3 במצב מתיר, עברה לשימוש חלקי בגרסה 4.4 (רק עבור תחומים קריטיים כמו installd, netd, vold ו-zygote), והיא משולבת במלואה מאז אנדרואיד 5.0 . מדיניות אנדרואיד מתמקדת בבידוד אפליקציות, שירותי מערכת ותהליכים רגישים באמצעות סוגים ומאפיינים, במטרה למזער את ההשפעה של פגיעה על כל אחד מהרכיבים הללו.

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

חשוב: אנדרואיד מפשטת את מודל SELinux על ידי התעלמות ממשתמשים, תפקידים ורגישויות מתקדמות. יש רק משתמש SELinux אחד (u), שני תפקידים בסיסיים (r עבור נושאים ו-object_r עבור אובייקטים), והרגישות היא תמיד s0. קטגוריות הן מה שעושה את ההבדל בבידוד נתונים.

השוואה עם AppArmor ו-LSMs אחרים

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

SELinux מגדירה מדיניות המתמקדת באובייקטים ובסוגיהם: לכל אובייקט במערכת (קבצים, תהליכים, שקעים, פורטים, התקנים, IPC וכו') מוקצה תווית. החלטות גישה מתקבלות על סמך ההקשרים של נושא ואובייקט, מבלי להיות תלויים בנתיב הקובץ המדויק. זה הופך את המערכת ליציבה יותר לנוכח שינויים במבנה הספריות או תצוגות מערכת קבצים חלופיות (chroot, containers, bind mounts וכו').

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

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

כלים מעשיים לניהול SELinux

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

כדי להציג את הקשר האבטחה של קבצים ותהליכים, ניתן להשתמש באפשרות -Z בפקודות נפוצות כמו ls, ps או id. לדוגמה, ls -Z בנוסף להרשאות DAC, הוא יציג את ההקשר של SELinux של כל קובץ, מה שיאפשר לך לבדוק במהירות אם התיוג הוא כצפוי.

הפקודה `chcon` ("שינוי הקשר") מאפשרת לך לשנות ידנית את כל ההקשר של קובץ או רק חלקים ספציפיים (תפקיד, סוג, טווח) באמצעות אפשרויות כגון `-r`, `-to` ו-`-l`. היא שימושית לתיקונים חד-פעמיים, אך חשוב לזכור שהשינויים שלך עלולים ללכת לאיבוד אם התיוג מוחל מחדש בהתאם למדיניות באמצעות כלים כמו `restorecon` או `fixfiles`.

כלי semanage הוא אולר שוויצרי לניהול מדיניות בזמן ריצה. בעזרת פקודות משנה שונות, ניתן לנהל הקשרים של קבצים מתמשכים (fcontext), מיפויי כניסה בין משתמשי לינוקס ו-SELinux (login), משתמשי SELinux ותפקידיהם (user), פורטים מתויגים (port), ערכים בוליאניים ואפילו מודולי מדיניות. כל זאת מבלי שיהיה צורך לקמפל מחדש את כל המדיניות מהמקור.

כדי לבדוק ולשנות את מצב הבוליאנים - מתגים קטנים המאפשרים או מבטלים בלוקים של כללים בתוך המדיניות - משתמשים בפונקציות getsebool ו- setsebool , בנוסף לבוליאן setsebool עצמו . ערך בוליאני טיפוסי הוא httpd_enable_homedirs, שכאשר הוא פעיל, מאפשר לשרת האינטרנט גישה לתיקיות הבית של המשתמשים (שימושי עבור ~user/public_html/).

לבסוף, פקודות כמו fixfiles מאפשרות לך לכפות תיוג מחדש מלא של מערכת הקבצים בהתאם לכללים שהוגדרו, ו- semodule מטפל בהתקנה, רישום, הפעלה או השבתה של מודולי מדיניות (.pp) הארוזים והופצו על ידי מדיניות ההפניה או על ידי המנהל.

יצירה והתאמה של מדיניות מותאמת אישית

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

הצעד הראשון הוא לוודא שהאובייקטים הרלוונטיים (קבצי הרצה, ספריות נתונים, שקעים וכו') מסומנים בסוגים מתאימים. ניתן להשיג זאת על ידי הגדרת כללי הקשר קבצים באמצעות ` semanage fcontext` והחלתם באמצעות `restorecon`, תוך שימוש בביטויים רגולריים כדי לכלול עצי ספריות שלמים.

המערכת בדרך כלל עוברת למצב מתיר (permissive mode) עבור אותה מכונה (או, במקרים מסוימים, עבור דומיין ספציפי) והאפליקציה מורשית לפעול כרגיל בזמן ש-SELinux רושם את כל משפטי `avc: denied` שהיו מתרחשים. יומנים אלה, שבדרך כלל מנותחים באמצעות כלים כמו audit2allow , משמשים לחילוץ כללים מועמדים.

מדיניות ייחוס (Reference policies) בדרך כלל בנויות בשלושה קבצים לכל יישום: קובץ .te המכיל כללי TE (allow, type, domain_type וכו'), קובץ .fc המכיל כללי הקשר של הקובץ, וקובץ .if המכיל ממשקים ציבוריים שמודולים אחרים יכולים לעשות בהם שימוש חוזר. כל זה עובר קומפילציה למודולי .pp באמצעות make ונטען באמצעות semodule.

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

בסביבות כמו SUSE Linux Micro או Android, ניתנים כלים נוספים (לדוגמה, Udica ליצירת מדיניות קונטיינרים מתיאורי JSON) אשר הופכים חלק מהתהליך לאוטומטי על ידי התאמה מהירה של המדיניות לקונטיינרים ספציפיים מבלי ללמוד את כל שפת המדיניות מאפס.

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