פקודת ה-VPN שלך רצה ללא הרשאות; השירות לא

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

הממשק, המנגנון והבדיקה

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

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

האצלה היא התכנון הרגיל

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

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

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

קראו את הגבול, לא את הבקשה

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

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

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

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

תקנו הרשאות בדרך הנתמכת

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

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

איך נראית חלוקה טובה

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

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