1. מבוא.2 מאז יצירתה של מערכת ההפעלה Linux ב- 1991, היא התפתחה למערכת הפעלה פופולרית ורב- תכליתית. בין הפצות Linux נמנות גרסאות מסחריות, כגון,Red Hat Enterprise Linux גרסאות חינמיות, כגון,Ubuntu וכן גרסאות מיוחדות למערכות משובצות מחשב, כגון.uClinux תרגול זה סוקר את מודל בקרת הגישה המשותף לכלל מערכות Linux ולמערכות דמויות Unix אחרות, על יתרונותיו וחסרונותיו. כמו-כן, נתייחס לחולשות טיפוסיות של מערכות Linux ודרכים להתמודד איתן. מודל בקרת גישה DAC בלינוקס ניתן לתמצת את מודל בקרת הגישה של לינוקס באופן הבא: משתמשים ותהליכים עם הרשאות root יכולים לעשות הכל; חשבונות אחרים יכולים לעשות הרבה פחות. לפיכך, מנקודות מבטו של תוקף, פריצת למערכת לינוקס מתמצת בהשגת הרשאות.root בהינתן הרשאות אלה, תוקף יכול לעשות הכל, כולל עריכה ומחיקת לוגים והחבאת תהליכים, קבצים ומדריכים.(directories) מודל בקרת הגישה של לינוקס מבוסס על בקרת גישה מבוססת שיקול דעת ) Access Discretionary.(Control, DAC עפ"י שיטה זו, הגישה לעצמים במערכת מבוססת על זהות המשתמשים או הקבוצות להן הם שייכים. בקרת הגישה היא מבוססת שיקול דעת במובן שמשתמש בעל הרשאות מתאימות על משאב, רשאי לקבוע הרשאות על אותו משאב עבור משתמשים אחרים עפ"י שיקול דעתו. הרשאות קבצים בסיסיות במערכת ישנם משתמשים, המשתייכים לקבוצה אחת או יותר. לכל משתמש מוגדרת קבוצה ראשית, אך הוא יכול להשתייך גם לקבוצות נוספות. הפקודות useradd, usermod ו- userdel מאפשרות לנהל את חשבונות המשתמש. הפקודות groupadd, groupmod ו- groupdel מאפשרות לנהל קבוצות. כמו-כן, ישנם עצמים: קבצים ומדריכים. משתמשים קוראים, כותבים ומריצים את עצמים אלה, עפ"י הרשאות העצמים. יש לציין שמכיוון שלינוקס מתייחסת כמעט לכל עצם כקובץ, גם משאבי מערכת אחרת, כמו זכרון, מנהלי התקנים,,named pipes וכן הלאה, מנוהלים באופן דומה. לכל עצם יש שני בעלים: משתמש וקבוצה. בהתאם לכך נגזרים שלושה סוגי הרשאות: הרשאות הבעלים (owner) תקפות עבור המשתמש שהוא הבעלים של הקובץ הרשאות קבוצה (group) תקפות עבור הקבוצה שהיא הבעלים של הקובץ (לרוב זו תהיה הקבוצה הראשית המוגדרת עבור המשתמש בעל הקובץ) הרשאות אחרות (other) תקפות עבור שאר הנתינים (משתמשים או תהליכים) במערכת עבור כל אחד מסוגי ההרשאות, ניתן לקבוע הרשאות קריאה,(read) כתיבה (write) והרצה.(execute) עבור עצמים שהם מדריכים, הרשאות קריאה משמעותן לאפשר הצגת תוכן המדריך והרשאות כתיבה משמעותן ליצור או למחוק קבצים במדריך. הרשאת הרצה משנה את משמעותה בהקשר של מדריכים והופכת לסיבית חיפוש bit) :(search הרשאה זו דרושה לביצוע כל פעולה שהיא בתוך המדריך. לדוגמה, אם למשתמש אין הרשאת read אבל יש לו הרשאת execute למדריך מסוים, הוא לא יוכל לראות את תוכן המדריך, אך במידה והוא יודע את שמו של קובץ הנמצא במדריך, הוא יוכל לגשת אליו. כיוון שתהליך הוא למעשה קובץ המועתק לזכרון לצורך הרצתו, ההרשאות באות לידי ביטוי פעמיים בהקשר של תהליכים: פעם אחת כאשר ניגשים לקובץ ההרצה, ובהמשך כאשר התהליך "רץ בשם" (זהות) המשתמש והקבוצה של המשתמש או התהליך שהפעיל אותו. 120
המשתמש שהוא בעל העצם יכול לקבוע או לשנות את הרשאות העצם. אולם גם למשתמש העל root יש את היכולת לקחת בעלות ולשנות בעלות על כל העצמים במערכת, דבר ההופך אותו למטרה מושכת ביותר עבור תוקפים. להלן דוגמה להצגת הרשאות קובץ (מתקבל ע"י ביצוע :(ls l- -rw-r--r-- 1 arikf csd-users 3055 Jan 14 2008 index.html עבור הקובץ,index.html לבעלים של הקובץ (arikf) יש הרשאות קריאה וכתיבה, לקבוצה csd-) (users יש הרשאות קריאה, ולשאר הנתינים יש הרשאות קריאה. את ההרשאות ניתן לשנות באמצעות פקודת.(change mode) chmod לדוגמה, הפקודה הבאה: chmod g+w index.html תוסיף עבור הקובץ index.html הרשאת כתיבה לקבוצה. באופן דומה, ניתן לבחון הרשאות עבור קובץ מדריך. במקרה זה, ניתן לזהות כי מדובר במדריך עפ"י הסימון d המופיע באות הראשונה משמאל. drwxr-xr-x 3 arikf csd-users 2048 Jan 14 2008 hagana/ הרשאת ה- bit sticky נשים לב שאם נותנים לנתין כלשהו הרשאות כתיבה למדריך, זה מאפשר לנתין לא רק להוסיף ולעדכן קבצים במדריך, אלא גם למחוק קבצים קיימים. כדי למנוע אפשרות זו, ניתן לסמן את המדריך באמצעות.sticky bit לדוגמה, הפקודה הבאה: chmod +t hagana תוסיף את ה- bit sticky לספריה.hagana במקרה זה, נתין הרשאי לכתוב למדריך יוכל להוסיף קבצים חדשים, אך לא יוכל למחוק קבצים קיימים. נראה שהרשאות other-executable עבור המדריך מסומנות כעת באות t: drwxr-xr-t 3 arikf csd-users 2048 Jan 14 2008 hagana/ במידה ולפני השינוי לא הייתה הרשאת other-executable (כלומר היה מופיע התו במקום התו x), אזי לאחר הוספת ה- bit sticky היה נעשה הסימון באמצעות האות T. הרשאות setuid ו- setgid הקבוצה בעלת הקובץ המשתמש בעל הקובץ הרשאות other הרשאות קבוצה הרשאות משתמש הרשאת (set user id) setuid ו- setgid (set group id) פועלות באופן הבא: כאשר הן נקבעות על קובץ ההרצה, אז כאשר משתמש בעל הרשאות מתאימות מריץ את הקובץ, מערכת ההפעלה תקצה לתהליך באופן זמני את הרשאות הבעלים של הקובץ (הרשאות משתמש או קבוצה, עבור setuid ו- setgid בהתאמה). החלטות בקרת גישה יסתמכו על הרשאות אלה. תכונה זו מאפשרת יצירת תכניות המאפשרות גישה למשאבים שבדרך כלל אינם נגישים. לדוגמה, משתמש המשנה את סיסמתו נדרש לעדכן את קובץ הסיסמאות,/etc/passwd שבדרך כלל אין לו גישה אליו. כיוון שהתכנית passwd שייכת למשתמש root ומוגדרת עם הרשאת,setuid בעת הרצתה המשתמש מקבל באופן זמני הרשאות root לצורך עדכון קובץ הסיסמאות. הרשאות setuid ו- setgid הן מסוכנות ביותר כאשר קובעים אותן על קובץ בבעלותו של root או משתמש בעל הרשאות אחר, ולכן יש להשתמש בהן בזהירות רבה. הפקודה,sudo המתוארת בהמשך, מספקת כלי עדיף להאציל סמכויות.root 121
.3 ל- setuid אין השפעה על מדריכים, אך ל- setgid יש השפעה כזו. במקרה זה, כל קובץ שיווצר במדריך ירש את קבוצת הבעלים של המדריך. אפשרות כזו היא שימושית, למשל, כאשר משתמשים שייכים לקבוצות משניות, ובאופן שגרתי מעוניינים לשתף קבצים עם חברים אחרים בקבוצות המשניות שלהם. שימוש ב- sudo פקודה זו (קיצור של (superuser do נכללת ברוב ההפצות של לינוקס, והיא נועדה לאפשר למשתמשים להריץ פקודות ספציפיות בהרשאות,root ללא צורך לדעת את סיסמת המשתמש.root הפקודה visudo מאפשרת למנהל המערכת לערוך את הקובץ,/etc/sudoers ולקבוע באופן פרטני לאיזה משתמשים מותר להפעיל איזה תוכנות תחת הרשאות.root אחת מהתכונות של sudo היא רישום מדוקדק של הפקודות שהורצו באמצעותה, כך שקיים מעקב אחר השימוש בתוכנות הדורשות הרשאות מיוחדות. יש לציין, כי קיימת אפשרות להגדיר את sudo כך שתדרוש את סיסמת root כאשר משתמש מנסה להריץ קובץ הדורש הרשאות.root ניתן לשאול מדוע למעשה sudo נחוצה במקרה שבו סיסמת root ידועה למשתמש. התשובה היא שבמקרה זה הרשאות root ניתנות למשימה קצובה, והסיכוי שייגרם נזק למערכת קטן יותר מזה כאשר מתחברים ממש לחשבון.root הרשאות מיוחדות עם chattr פקודה שייחודית למערכות הקבצים ext2 ו- ext3 של Linux היא פקודת,chattr שמאפשרת לקבוע הרשאות מיוחדות לקבצים. בין הרשאות אלה ניתן למנות את: הרשאת (i+) immutable הרשאה זו מונעת כל שינוי אפשרי לקובץ (אפילו למשתמש.(root פקודה זו שימושית, למשל, להגנה על תוכניות מערכת חיוניות כמו passwd,ps,ls וכן הלאה. קיימים וירוסים המנסים לשנות את תוכניות אלה במטרה להסתיר את קיומם,rootkits) ראו בהמשך), והרשאה זו יכולה להקשות עליהם. הרשאת (a+) append only הרשאה זו מאפשרת לכתוב לקבצים רק בסופם. היא מתאימה במיוחד לקבצי לוג, בהם מעוניינים רק להוסיף רשומות חדשות, תוך מניעת מחיקה או שינוי של רשומות קיימות. כדי לצפות באוסף ההרשאות שנקבעו עבור קובץ ניתן להשתמש בפקודה.lsattr כאמצעי הגנה נוסף, לאחר קביעת ההרשאות המיוחדות, ניתן להסיר מהמערכת את תוכנית,chattr כדי להקשות על תוקף לבטל את ההרשאות. למרות שתוקף מיומן עשוי להתגבר על מכשול מסוג זה, שיטת הגנה כזו יכולה לעכב ואף לעצור תוקפים פחות מיומנים. פגיעויות בלינוקס כמו הרבה מערכות הפעלה אחרות, גם מערכות לינוקס חשופות להתקפות מסוג Buffer overflow ו-,Denial of service עליהן נדון במסגרת הרצאות ותרגולים אחרים בקורס. בסעיף זה נתמקד בנקודות תורפה הייחודיות למערכות לינוקס (ומערכות אחרות דמויות :(unix ניצול תכניות הרצות בהרשאות,setuid root והתקפות rootkit ייחודיות ללינוקס. 3.1. ניצול תכניות הרצות בהרשאות setuid root תכנית setuid root היא תוכנית הנמצאת בבעלות המשתמש root שסיבית ה- setuid שלה דלוקה. תכנית כזו תרוץ תחת הרשאות,root לא משנה מי הריץ אותה. תכניות מסוג זה הן הכרחיות עבור משימות שצריכים להריץ משתמשים ללא הרשאות, אך הדורשות הרשאות גישה מיוחדות. דוגמה למשימה כזו היא פעולת שינוי סיסמה שתוארה לעיל, המבוצעת ע"י התכנית.passwd אם ניתן לנצל לרעה תכנית,setuid root לדוגמה ע"י ניצול,buffer overflow אזי משתמש ללא הרשאות יכול לנצל את התכנית על מנת להשיג הרשאות,root כולל פתיחת shell בהרשאות.root עקב כך, תוכניות מסוג זה דורשות תכנון זהיר ביותר, בדיקה יסודית של קלט מהמשתמש, ניהול 122
זכרון קפדני וכן הלאה. נספח א' מכיל מספר דוגמאות קוד המתארות חורי אבטחה אפשריים העשויים להיווצר עקב כתיבה לא זהירה של תוכניות.setuid root 3.2. התקפות רוטקיט (Rootkit) רוטקיט הינה אוסף של כלי תוכנה המיועדים להסתיר תהליכים, קבצים או מידע מערכת מפני מערכת ההפעלה. הרוטקיט בפני עצמו אינו בהכרח זדוני, אולם התוכנה אליה הוא נלווה (המרכיבים אותם הוא מיועד להסתיר) עשויה להיות בעלת מטרה זדונית. למשל רוטקיט יכול לשמש כדי להסתיר את קיומם של סוס טרויאני או דלת סתרים במערכת. התקפת רוטקיט מאפשרת לתוקף להסתיר את עקבות הפעילות שלו, ומבוצעת לרוב לאחר שהתוקף כבר השיג הרשאות.root מונח הרוטקיט התפרסם ברבים באוקטובר 2005, בעקבות סדרת כתבות בבלוגים באינטרנט, ובהמשך באמצעי תקשורת אחרים. נחשף כי חברת Sony BMG צירפה לתקליטורי המוסיקה שלה תוכנה המתקינה עצמה אוטומטית על מחשב המשתמש, ללא ידיעתו, כאשר הוא מנסה לנגן את הדיסק. מטרת התוכנה לספק הגנה על זכויות יוצרים Management),(DRM Digital Rights אך התוכנה מסתירה את קיומה על המערכת ו"מתחבאת" מפני המשתמש. התגלה כי התוכנה צורכת משאבי מערכת גם כאשר אינה בשימוש, וכי התקנתה והסרתה פוגעים ביציבות המערכת. בעקבות המחאה הציבורית שהתעוררה, סוני משכה מהמדפים את כל התקליטורים שהכילו את התוכנה. התקפות Rootkit במערכות דמויות unix החלו כאוסף של תוכניות חלופיות לפקודות unix טיפוסיות (כגון ls, ps וכן הלאה). תכניות אלה פעלו בצורה דומה לפקודות המקוריות, למעט העובדה שהסתירו את הקבצים, המדריכים והתהליכים של התוקף. דרך אחת לשינוי פעולתן של פקודות בסיסיות, הוא ע"י עטיפתן.(wrap) לדוגמה, ניתן לעטוף תוכנית כגון ps בסקריפט המבצע: ps grep v."maliciouscode" קל יחסית לזהות עטיפות כאלה (השתמש ב- usr/bin/ps / באופן ישיר, ודא ש- /usr/bin/ps הוא קובץ הרצה ולא סקריפט). אפשרות אחרת היא ממש להחליף תוכנית אחת באחרת, כלומר, להדר מחדש את התוכנית. כדי לזהות ולמנוע שינויים מסוג זה נדרש, למשל, לשמור ערכי hash של התוכניות, ולפני הרצתן לוודא שהערך הוא נכון. באופן כללי, ניתן לסווג תוכנות רוטקיט על-פי האמצעים שהן נוקטות על מנת להסתיר רכיבי מערכת: רמה וירטואלית שינוי תהליך טעינת המחשב (boot) כך שהרוטקיט ייטען לפני מערכת ההפעלה, ולמעשה ישמש כ"מכונה וירטואלית" על גביה רצה מערכת ההפעלה. באופן זה הרוטקיט חוצץ בין מערכת ההפעלה לבין חומרת המחשב. רמת גרעין הוספה או שינוי קוד גרעין של מערכת ההפעלה, לרוב באמצעות טעינת מנהל התקן driver).(device רמת ספריות מערכת שינוי מימוש של פונקציות מעטפת או פונקציות ספריה הרצות ב- user mode ומפעילות קריאות מערכת, והחלפתן בגרסאות המחביאות מידע אודות התוקף. רמת אפליקציה החלפת תוכנות (כגון ps,ls ו- netstat במערכות (unix בגרסאות אחרות, באופן שישנה את התנהגותן. לדוגמה, בלינוקס קיימת אפשרות להרחיב את גרעין מערכת ההפעלה (לדוגמה כדי להוסיף תמיכה בחומרה חדשה או מערכת קבצים) באמצעות טעינה דינמית של קטעי קוד (מודולים) לגרעין. מנגנון זה מכונה.(LKM) Loadable Kernel Module התקפה המנצלת מודולים כאלה הינה חמורה יותר מהחלפת פקודות.unix בעוד פקודות unix מוחלפות בדרך כלל ע"י תוכניות הרצות ב- mode,user מודולים הנטענים לגרעין רצים בהרשאות,kernel mode ולכן מספקים לתוקף הרבה יותר אפשרויות ומקשים על גילוי ה- rootkit. במקרה כזה, הקבצים, המדריכים והתהליכים שבבעלות התוקף ניתנים להסתרה מפני מערכת ההפעלה עצמה, ולא רק מפני המשתמשים. מעצם הגדרתן של תוכנות רוטקיט, זיהוי נוכחותן במערכת אינו פשוט, והבעיה העיקרית היא שלא ניתן לסמוך על שירותי מערכת ההפעלה בה רץ הרוטקיט. במקרים מסוימים ניתן לזהות את קיום 123
הרוטקיט ע"י ביצוע פעולה דומה בדרכים שונות, והשוואת התוצאות. למשל, בדיקת תוכן מדריך במחשב על-ידי שימוש בשירות של מערכת ההפעלה, והשוואה לתוצאה המתקבלת על-ידי בדיקת תוכן המדריך באמצעות פעולות ברמת החומרה. דרך אמינה יותר לזיהוי רוטקיט תהיה לכבות את המחשב החשוד בהדבקה, ולסרוק את הדיסק הקשיח ע"י אתחול מהתקן אחר שהינו בטוח (כונן CD או התקן.(USB גם לאחר שהתגלה רוטקיט במערכת, הסרתו לא תהיה בהכרח פשוטה. ברוב המקרים התקנה מחדש של המחשב נחשבת לפתרון המהיר והיעיל ביותר להסרת הרוטקיט. 4. שיפור אבטחת מערכות לינוקס לינוקס מספקת מנגנונים מגוונים על מנת להשיג רמת אבטחה גבוהה יותר ולהגן טוב יותר על האפליקציות הרצות במערכת. בין מנגנונים אלה ניתן למנות שירותים להתקנה אוטומטית של עדכוני אבטחה, מנגנוני בקרת גישה לרשת Wrappers),(Libwrappers and TCP מנגנון Firewall,(iptables) מנגנוני ניטור ועוד. דיון במנגנונים אלה חורג מהיקף התרגול. אנו נתמקד בשתי דרכים פשוטות יחסית בהן ניתן לשפר את אבטחת המערכת והאפליקציות שרצות בה. 4.1. הקשחת מערכות לינוקס אחד המכשולים העומדים בפני משתמשים המתקינים מערכת לינוקס בפעם הראשונה, הוא הצורך להתמודד עם תהליך התקנה מורכב. בעוד שישנן הפצות לינוקס המקבלות החלטות עבור המשתמש, ישנן גם הפצות בהן המתקין נדרש לבחור את התכניות אותן הוא מעוניין להתקין, או לבצע התקנה מלאה. בחירה מושכלת של התוכניות להתקנה דורשת ידע מתאים. לא רק שהמשתמש נדרש לדעת מה משמעותה של כל תכנית, אלא קיימות גם תלויות בין שירותים, כאשר התקנה של שירות אחד דורשת לעיתים התקנה של שירותים אחרים. הבחירה באוסף התכניות להתקנה היא מהותית לאבטחת המערכת. לדוגמה, אין טעם להתקין שירות כמו httpd אם לא מעוניינים להשתמש במחשב כשרת.web אם השירות מותקן כברירת מחדל של תהליך ההתקנה, אזי קיים פתח נוסף שתוקף יכול לנצל על מנת לחדור למערכת. הקשחת מערכת ההפעלה מאפשרת לצמצם את שטח פני ההתקפה החשופים של המערכת. כאשר מסירים (או נמנעים מלהתקין) שירותים לא נחוצים, מוודאים כי רצות במערכות פחות תכניות שתוקף יכול לנצל. לחלופין, גם אם מתקינים את השירותים, ניתן לצמצם את שטח פני ההתקפה ע"י המנעות מטעינתם בעת עליית המערכת. Chroot jail.4.2 קריאת המערכת chroot (אותה רק המשתמש root יכול להריץ), גורמת לתהליך להתייחס למדריך המתקבל כארגומנט כאילו זהו המדריך הראשי. כלומר, מחליפים את מדריך השורש directory) (root של התהליך במדריך אחר. לדוגמה, chroot( /usr/arikf ) תהפוך את המדריך /usr/arikf למדריך השורש של התהליך המריץ את הפקודה. המשמעות היא שהתהליך יוכל לגשת אך ורק למדריך זה ולתתי-המדריכים שתחתיו, אך לא למדריכים אחרים במערכת. לדוגמה, ביצוע הפקודה.. cd ישאיר את המשתמש במדריך,/usr/arikf ולא יעביר אותו למדריך./usr לכן, אומרים כי תהליך כזה רץ ב-.chroot jail במובן זה, יוצרים עבור המשתמש מעין ארגז חול (sandbox) אזור תחום במערכת הקבצים שרק אליו יש למשתמש גישה. היתרון של השימוש ב- chroot הוא שגם אם תוקף הצליח להשתלט על תהליך מסוים, הגישה שלו למערכת הקבצים מוגבלת. במידה וירצה לגשת למדריכים אחרים, יצטרך גם לפרוץ את.chroot בפרט, ניתן בדרך זו למנוע מהמשתמש גישה לקבצים רגישים במערכת, כגון קבצי סיסמה, קבצים בשימוש הגרעין וכן הלאה. 124
השימוש ב- chroot נפוץ במימושים של אפליקציות החשופות לאינטרנט. למשל, במימוש שרת ftp ניתן להשתמש ב- chroot כדי להגביל את מה שהמשתמש רואה. בתוכנת השרת httpd המספקת דפי,web נדרשת גישה בעיקר לתוכן שתחת מדריך.www הרצת האפליקציה ב- jail chroot תגביל את השרת לחלק קטן ממערכת הקבצים, ובמידה ותוקף יצליח להשתלט על התוכנה (לדוגמה, ע"י התקפת,(buffer overflow זה לא יאפשר לו גישה לשאר מערכת הקבצים. מודל אבטחת MAC בלינוקס SELinux.5 כפי שצויין לעיל, מודל האבטחה בלינוקס מבוסס על גישה מבוססת שיקול דעת.(DAC) SELinux Linux) (Security-Enhanced היא אוסף של התאמות שפותחו ע"י ה- NSA (הסוכנות הבטחון הלאומי של ארה"ב). בגרסת לינוקס 2.6, SELinux שולבה בגרעין הרשמי של לינוקס. מטרת ההתאמות של SELinux לספק מודל אבטחה המבוסס על בקרת גישה מחויבת ) Mandatory.(MAC,Access Control בגישה זו, קיימת מדיניות אבטחה כללית המחייבת את כל המשתמשים במערכת. לדוגמה, משתמש לא יכול לשנות הרשאות של קובץ כך שיהיו נמוכות מאלה המחויבות ע"י המדיניות הכללית. בשל מורכבות המודל לא נתאר אותו לפרטים, אלא נציג רק את העקרונות הכלליים שבבסיסו. ב- SELinux, הרשאות הקבצים נבדקות תחילה עפ"י גישת.DAC במידה וההרשאות מונעות גישה לקובץ, אז הגישה תיחסם. אחרת, SELinux תבחן את הפעולה המבוקשת מול מדיניות האבטחה הגלובלית שנקבעה. מודל ההרשאות של SELinux מפורט בהרבה מהמודל הבסיסי. הנתינים ב- SELinux הם תמיד תהליכים. העצמים, לעומת זאת, כוללים לא רק קבצים ומדריכים, אלא גם תהליכים אחרים ומשאבי מערכת שונים גם במרחב הגרעין וגם במרחב המשתמש, לדוגמה: מדריך,,tcp_socket,socket מערכת קבצים, xserver,node וכן הלאה. לכל סוג עצם יש קבוצת הרשאות (פעולות) אפשריות ייחודית. לדוגמה, למחלקה מדריך,(dir) חלק מההרשאות הייחודיות הן: getattr, search, rmdir, ו- reparent. remove_name לכל תהליך מוגדר "מרחב",domain) מכונה גם טיפוס.(type המרחב מתפקד כעין ארגז חול, ומגדיר אוסף של נתינים ועצמים שיכולים לפעול זה על זה. בגישה זו, לכל תהליך (נתין) מוקצה טיפוס המגדיר את הפעולות שהוא מורשה לעשות. גישה זו מכונה אכיפת טיפוס Enforcement),(Type והיא הלב של.SELinux מערכת בקרת הגישה נדרשת לקבל החלטות גישה (לדוגמה, איזה פעולות יכול לבצע נתין על עצם) והחלטות מעבר (כאשר תהליך צריך לעבור מטיפוס לטיפוס). בנוסף ל- Enhancement SELinux,Type תומכת במודל נוסף, גישת בקרה מבוססת תפקידים Control),(RBAC Role Based Access בה לכל משתמש יש תפקיד (role) שהוא יכול למלא, וישנם כללים לגבי מעבר של משתמש מתפקיד אחד לאחר. 6. מקורות חומר התרגול מבוסס על: Computer Security, Principles and Practice, by William Stallings and Lawrie Brown Chapter 23: (by Mick Bauer, Security Editor, Linux Journal). Setuid Demystified, by Hao Chen, David Wagner and Drew Dean, Usenix 2002. How to write a Setuid program, by Matt Bishop. רשומת הבלוג של מארק רוסינוביץ', בה נחשף לראשונה הרוטקיט של :Sony BMG Sony, Rootkits, and Digital Rights Management Gone Too Far, Mark Russinovich 125
http://blogs.technet.com/markrussinovich/archive/2005/10/31/sony-rootkits-anddigital-rights-management-gone-too-far.aspx 126
נספח א':דוגמאות לבעיות קוד הנוגעות להרשאות בלינוקס מה הבעיה המסתתרת בקטעי הקוד הבאים? כתוב קטע קוד המוודא שהתכנית מורצת ע"י משתמש.root אם כן, הפעל קריאת מערכת כלשהי, אחרת מתקבלת הודעת שגיאה. if (uid=0) // uid = 0 means root { ioctl(); } else { error("not root"); }.1 char *user; user = getenv("user"); // Returns the user name if (strncmp(user,"root",4)==0) { // do something } else printf(you are not root!\n); 2. מה הבעיה בקטע הקוד הבא? קטעי קוד כאלה הופיעו בעבר בתכניות,setuid root ולכן עם הרשאות גישה שמאפשרות להן לבצע בקטע הקוד הרלוונטי פעולות "רבות עוצמה". 3. מה הבעיה במימוש הבא לתכנית שינוי הסיסמה? // Passwd implementation int main() { setuid(geteuid()); // become setuid fprintf(stdout,enter username:\n) fgets(user,12,stdin); fprintf(stdout,enter password:\n) fgets(password,12,stdin); if (check_password(user,password)!=succeed) { fprintf(stderr,"wrong username/password\n"); exit(1); } 4. מה הבעיה בקטע הקוד הבא? FILE where=fopen("/tmp/progname.pid","rw"); //allow read and write only to the process fwrite(where,information);.. fread(where,information); process(information); 127
הערה: הבעיה מחריפה כשהתכנית רצה בהרשאות,root פוטנציאלי גדול יותר. ולא רק בגלל נזק קטע הקוד הבא מייצג תוכנית הרצה בהרשאות.setuid כחלק מתפקידיה היא קוראת נתונים מקובץ גדול המאוחסן בצורה מכווצת (באמצעות,(zip שרק ל- root יש גישה אליו..5 int main() { setuid(geteuid()); // become setuid FILE *fp; int status; fp = fopen("gunzip /etc/zippeduserdb", "r"); // gunzip output is piped to fp if (fp == NULL) /* Handle error and quit */; /* process data from the unzipped file */ status = pclose(fp); 128