root בטרמינל, נדחה תחת SELinux: מדוע ה-hook נכשל

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

אותה פקודה, שני דומיינים שונים של אבטחה

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

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

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

קראו את רשומת ה-AVC לצד שגיאת ה-hook

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

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

הקשר המקור אמור להתאים לדומיין שבו השירות באמת רץ, והקשר היעד לתווית של הקובץ או התיקייה שהפעולה נגעה בהם. אם אחד מהשניים לא תואם לשגיאה שאתם רודפים אחריה, אתם קוראים אירוע אחר.

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

תווית, תצורה או מדיניות: שלושה תיקונים

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

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

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

מדוע מודול allow ישן אינו התשובה

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

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

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