דורון אופק

יצירה זו מופצת תחת רישיון ייחוס-שיתוף זהה 2.5 ישראל של Creative Commons

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

לפיכך נעסוק בנושאים הבאים:
סיסמאות – כיצד קובעים, היכן הן נשמרות וכיוצ”ב.
ניהול משתמשים – יצירת משתמשים, כיצד משתמש נוצר
PAM- מהו ? ( Pluggable Authentication Modules )

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

כאשר אנו יוצרים משתמש במערכת אנו משתמשים בכלי ניהול משתמשים שקיים בהפצה שלנו, כדוגמת YaST ב – SuSE או system-config-users בהפצות מבוססות Red Hat . כלים אלו מפעילים ברקע של הדברים את הפקודות adduser או useradd (תלוי בהפצה) כך שאנו יכולים להוסיף משתמשים גם בעזרת הפקודות הללו.
ישנן הפצות בהן קיימות 2 הפקודות ואילו באחרות קיימת אחת מהפקודות.
פרמטרים לפקודות הללו ניתן לקבל מעמוד ה man של הפקודה, אולם בכך לא תם התהליך.
כאשר אנו עובדים עם כלי ניהול משתמשים בדר”כ דרך הכלי נוכל נצטרך לקבוע סיסמה למשתמש, לא כך הוא המצב כאשר אנו עוסקים בממשק הפקודה.
כאשר אנו עוסקים בממשק הפקודה אנו נצטרך להשתמש לאחר פקודת הוספת המשתמש בפקודה passwd על מנת לספק סיסמה לאותו משתמש.

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

כאשר אנו מוסיפים משתמש (או למעשה מפעילים את הפקודה useradd ) המערכת לוקחת הגדרות ברירת מחדל שקיימות בתוכה ומשתמשת בהן כפרמטרים לאותה פקודה, את הפרמטרים של הפקודה useradd נוכל למצוא בקובץ useradd שנמצא תחת etc/default , הנה דוגמה לתוכן של קובץ שכזה תוך מערכת מבוססת Red Hat :

 Start
 
 cat /etc/default/useradd 
 # useradd defaults file 
 GROUP=100 
 HOME=/home 
 INACTIVE=-1 
 EXPIRE= 
 SHELL=/bin/bash 
 SKEL=/etc/skel 
 CREATE_MAIL_SPOOL=yes
 
 End

כמו שאנו רואים הקובץ מחזיק מספר פרמטרים בסיסיים אשר נדרשים כאשר אנו מוסיפים משתמש למערכת.
לדוגמה, כל משתמש שנוסיף אמור להיות עם מספר קבוצה 100 (GID ), ה shell שלו אמור להיות bash וכן הלאה.
אך אם נוסיף משתמש למערכת נראה כי לא כך הוא המצב.
למעשה המערכת ממשיכה לקובץ הבא אשר מגדיר הגדרות נוספות כפרמטרים בסיסיים להוספת המשתמש, הקובץ הבא בשרשרת הינו login.defs אשר מצוי ב etc . הנה דוגמה לקובץ כזה:

 Start
 
 cat /etc/login.defs 
 
 MAIL_DIR        /var/spool/mail 
 
 PASS_MAX_DAYS   99999 
 PASS_MIN_DAYS   0 
 PASS_MIN_LEN    5 
 PASS_WARN_AGE   7 
 
 UID_MIN                   500 
 UID_MAX                 60000 
 
 GID_MIN                   500 
 GID_MAX                 60000 
 
 CREATE_HOME     yes 
 
 End

כהגדרה, המערכת תשתמש בכל נתוני ברירת המחדל הללו, אולם כאשר יש הגדרה “צולבת” או חופפת המערכת תשתמש בהגדרה האחרונה.
מכוון שהקובץ login.defs הוא אחרון מבין השניים, המערכת תיקח את הגדרת ה GID ממנו ולא מקובץ ברירת המחדל, בכל מקרה קובץ ברירת המחדל ישמש אותנו כאשר הקבצים האחרים ייפגעו.

עכשיו נכנסים לפעילות הקבצים הבאים שאליהם נרשמים הנתונים, הקבצים השותפים לרישום הם :
passwd
shadow
group
gshadow

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

הפצות הלינוקס השונות , ונוכל להשתמש בדוגמה ב Red Hat ו- SuSE משתמשות במודל שונה בברירת המחדל לטיפול בקבוצה שאליה שייך המשתמש.
בעיקרון, זוהי רק התנהגות ברירת מחדל וניתן לעבוד במודל של UPG ב- SLES או Global Group ב- RHEL .
כאשר אנו מוסיפים משתמשים ב SLES נוכל לראות שבברירת המחדל כולם שייכים לאותה קבוצה.
הדבר נובע תצורת עבודה שהשתרשה בעולם ה Unix/Linux לאורך שנים. אולם בתצורה שכזו עשויה להתקיים בעיה מסויימת, והיא , כאשר משתמש שאינו מכיר מספיק את המערכת משחק עם ההרשאות של הקבוצה שאליה הוא שייך על הקבצים שלו, הוא יכול לתתת הרשאה לקבוצה שלו (בטעות או במכוון).
כאשר כל המשתמשים במערכת שייכים לאותה קבוצה, הרי שיש מצב שבו משתמש מספק בצורה שכזו הרשאה לכל המשתמשים במערכת לקבצים שלו בלי שהוא התכוון לכך (יכול להיות שהוא רצה לתת הרשאה רק למשתמש אחד אך מכוון שהוא עשה זאת דרך מנגנון הרשאת הקבוצה כולם במערכת קיבלו הרשאה זו כי כולם שייכים לאותה קבוצה).
טוב, אני מקווה שהבעיה ברורה.
ב Red Hat רצו לפתור את נקודת החולשה הזו ומימשו זאת דרך מודל שנקרא User Privet group או UPG , למעשה כאשר אני יוצר משתמש בסביבת RHEL מייד נוצרת קבוצה באותו השם המשתמש שיצרתי הוא החבר היחיד בה והיא מהווה את קבוצת “ברירת המחדל” לאותו משתמש.
כלומר אם יש לי מערכת עם 5 משתמשים, כאשר יצרתי אותם נוצרו גם 5 קבוצות שונות וכל אחד מהמשתמשים שלי שייך לקבוצה משלו, כך גם אם הוא יעשה טעות ויספק גישה לקבוצה שלו, מכוון שהוא החבר היחיד בה אף אחד לא יוכל להגיע אל המידע.
נדרשות מהמשתמש 2 פעולות על מנת לאפשר למישהו אחר גישה למידע שלו , האחת לספק הרשאה לקבוצה והשניה לשנות את הקבוצה מקבוצת ברירת המחדל לקבוצה הרלוונטית.
בכל מקרה, ניהול הקבוצות והשיוך של המשתמשים אליהם צריך להיות במודל שכזה תהליך יזום ולא תהליך שנשען על קבוצת ברירת מחדל גנרית שקיימת במערכת.

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

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

  doron:x:1000:1000:doron:/home/doron:/bin/bash

• השדה הראשון (השמאלי ביותר) מכיל את שם המשתמש שאיתו המשתמש צריך לעשות login .
• השדה השני (מכיל x ), הינו השדה של הסיסמה, מכוון שבברירת המחדל מערכות לינוקס פועלות על shadow יש x בשדה הנ”ל.
• השדה השלישי (עם המספר 1000 ) הינו שדה ה UID מספר מזהה ייחודי למשתמש.
• השדה הרביעי (עם המספר 1000 ) היננו שדה ה GID המכיל מספר המזהה את קבוצת ברירת המחדל של המשתמש.
• השדה החמישי (עם הערך doron) הוא שדה של הערה, במרבית המקרים הוא יהיה ריק.
• השדה השישי ( עם הערך /home/doron ) הוא למעשה התיקיה בה המשתמש יהיה מייד לאחר ביצוע תהליך של login – אצל מרבית המשתמשים מדובר ב”תיקיית הבית” , למעשה כאשר משתמש מבצע login למערכת הוא הופך להיות process, ולכל תהליך במערכת יש תייקה בה הוא פעיל (משתנה הסביבה PWD ) , כאמור לגביי משתמש מדובר בתקיית הבית.
• השדה האחרון (ראשון מימין ) הוא השדה שמכיל את התוכנה שתיכנס לפעילות כאשר המשתמש יבצע login , אצל מרבית המשתמשים הסטנדרטיים מדובר ב shell כזה או אחר (במקרה הזה זה bash ) ובמקרים של “משתמשי מערכת” ייתכן ויהיה כאן shell מדומה או לא אמיתי (משתמשים שנוספים למערכת בגלל התקנת אפליקציות) , בכל מקרה, התוכנה הזו תיכנס לפעילות כאשר המשתמש יסיים את תהליך ה login .

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

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

 doron:$1$FerGfByn$q5Wh39rO0ts8T.6hkDGSN1:13751:0:99999:7:::

השדות המופעים בקובץ זה:

• שדה שמאלי ( מכיל את הערך doron ) , שם ה login של המשתמש.
• שדה שני (מכיל את הג'יבריש) , זהו השדה שמכיל את הסיסמה בצורת ה hash שלה.
• שדה שלישי ( מכיל את הערך 13751 ), מדובר בתאריך שבו שונתה הסיסמה, תשאלו ,… איזה תאריך? טוב אז מערכות הפעלה מסמנות תאריכים כמספר הימים שעברו מ 1 לינואר 1970 … למה דווקא מאז .. סתם כי ככה החליטו)
• שדה רביעי (מכיל את הערך 0 ), מספר הימים שבהם המשתמש רשאי לשנות את סיסמתו מהרגע שהוא שינה אותה .
• שדה חמישי (מכיל את הערך 999999), מספר הימים בהם המשתמש חייב לשנות את הסיסמה.
• שדה רביעי (מכיל את הערך 7 ), מספר הימים בהם המשתמש יקבל התראה לפני תפוגת סיסמה.
• שדה חמישי (שדה ריק), מספר הימים שבהם החשבון יפוג לאחר שתוקף הסיסמה פג.
• שדה שישי (שדה ריק) , תאריך (מהראשון לינואר 1970 , זוכרים? ) שבהם יפוג החשבון.
• שדה שביעי (ריק) , שדה שמור.

  scanner:x:111:cupsys,hplip,doron

השדות בקובץ זה:

• שדה ראשון , שם הקבוצה.
• שדה שני (עם הערך x), שדה של סיסמה , כמובן שאין סיסמה לקבוצה אולם שדה זה קיים לשם תאימות.
• שדה שלישי (עם הערך 111 ), מספר הקבוצה – GID
• שדה רביעי, (עם מספר ערכים) , מכיל את שמות החברים בקבוצה.

לכאורה קובץ הסיסמאות של הקבוצות – אולם מכוון שאין לקבוצות שלנו סיסמאות , לא ממש נעסוק בו.
ניתן לקרוא את עמוד ה man שלו על מנת לקבל מידע נוסף.

id – מספקת מידע על משתמש ועל הקבוצות אליהן הוא שייך.
groups – מספקת מידע על הקבוצות אליהם שייך המשתמש.
useradd – מוסיפה משתמש למערכת
usemod – משנה נתונים על משתמש (משנה את הקובץ passwd )
chage – משנה נתונים על סיסמה (תפוגה וכיוצ”ב) – משנה את הקובץ shadow .

pwck – בודקת שלמות נתונים בקובץ passwd . הפקודה בודקת את תאימות הנתונים בקובץ passwd כלומר אם מופיע שם משתמש אך לאותו משתמש לדוגמה אין home directory הפקודה תדווח על כך .
יש לטפל בכל הבעיות עליהם הפקודה מדווחת (יצרת home directory או לחילופין מחיקת המשתמש בדוגמה שהשתמשנו בה). הנה פלט של הפקודה :

 start
 
 pwck 
 user pcap: directory /var/arpwatch does not exist 
 user webalizer: directory /var/www/html/usage does not exist 
 user xfs: directory /etc/X11/fs does not exist 
pwck: no changes 
 
 End

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

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

 Start
 
 #last |less 
 doron    pts/1        10.50.0.67       Wed Dec 26 08:20   still logged in   
 doron    pts/1        10.50.0.67       Tue Dec 25 19:36 - 19:57  (00:20)    
 doron    pts/1        10.50.0.67       Tue Dec 25 14:51 - 15:18  (00:27)    
 doron    pts/1        10.50.0.67       Tue Dec 25 13:18 - 13:33  (00:14) 
 
 end

lastb – מספק מידע על נסיונות login למערכת שלא צלחו. מדובר או שמשתמשים רגילים ששכחו את הסיסמה, או בנסיונות לנחש סיסמה של משתמשים רגילים (ע”מ לפרוץ להם לחשבון) או בנסיונות לנחש גם את שם המשתמש וגם את סיסמתו. בעיקרון, בחלק מהפצות הלינוקס הפקודה לא פעילה מכוון שהיא צריכה קובץ שישמש לה בסיס נתונים. יש צורך ליצור ידנית את הקובץ הזה. הקובץ צריך להיות בשם btmp ולהיות ממוקם תחת /var/log . מצ”ב פלט לדוג':

 start
 
 root     ssh:notty    59.40.182.182    Tue Dec 25 16:54 - 16:54  (00:00)     
 oracle   ssh:notty    59.40.182.182    Tue Dec 25 16:52 - 16:52  (00:00)      
 alezio   ssh:notty    sd-1948.dedibox. Mon Dec 24 11:51 - 11:51  (00:00)    
 doron    ssh:notty    10.50.0.67       Sat Dec 22 22:41 - 22:41  (00:00)    
 root     ssh:notty    216.240.130.199  Sat Dec 22 00:53 - 00:53  (00:00) 
 lab      ssh:notty    216.240.130.199  Sat Dec 22 00:52 - 00:52  (00:00)      
 apache   ssh:notty    216.240.130.199  Sat Dec 22 00:52 - 00:52  (00:00)  
 test     ssh:notty    216.240.130.199  Sat Dec 22 00:50 - 00:50  (00:00)    
 guest    ssh:notty    216.240.130.199  Sat Dec 22 00:50 - 00:50  (00:00)    
 root     ssh:notty    216.240.130.199  Sat Dec 22 00:50 - 00:50  (00:00)    
 gary     ssh:notty    216.240.130.199  Sat Dec 22 00:50 - 00:50  (00:00)      
 stephani ssh:notty    216.240.130.199  Sat Dec 22 00:49 - 00:49  (00:00)    
 william  ssh:notty    216.240.130.199  Sat Dec 22 00:49 - 00:49  (00:00)    
 gt05     ssh:notty    216.240.130.199  Sat Dec 22 00:49 - 00:49  (00:00)    
 aaron    ssh:notty    216.240.130.199  Sat Dec 22 00:49 - 00:49  (00:00)    
 trash    ssh:notty    216.240.130.199  Sat Dec 22 00:49 - 00:49  (00:00)    
 stud     ssh:notty    216.240.130.199  Sat Dec 22 00:49 - 00:49  (00:00)
 
 end

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

lastlog – פקודה נוספת המראה מתי נכנסו המשתמשים הקיימים למערכת .
who – פקדוה המראה מי כרגע נמצא במצב של login .
w – כנ”ל.

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

מערכת חשובה בהיבטים של authentication ו- Authorization היא מערכת ה PAM שהינה מערכת בסיסית בכל הפצת לינוקס.
המערכת עובדת במספר שלבים:

1. תוכנה שבוצעה לה קומפילציה עם PAM נכנסת לפעילות.
2. רכיב הספריה של PAM נכנס לפעילות בתחילת פעילותה של האפליקציה ( lib/pam ).
3. הרכיב מפעיל את PAM אשר קורא לקובץ הקונפיגורציה הרלווטי (בדרך כלל על פי שם האפליקציה) , במידה וקובץ כזה לא קיים, הוא מפעיל קובץ ברירת מחדל.
4. קובץ הקונפיגורציה נטען לתוך ה PAM , ועל פי נטענים שורה של מודולים אשר נכנסים לפעילות (המודולים מצויים ב /lib/security ) .
5. המודולים מבצעים בדיקות, כל מודול את הבדיקות שלו, במידה והבדיקות עוברות כשורה, PAM מחזיר לאפליקציה אישור להמשיך לעבוד. במידה והמודולים נכשלים בבדיקה PAM מחזיר לאפליקציה אישור שלילי והאפליקציה נכשלת בפעילות שלה.

בעיקרון, כמו שניתן לראות מעצם התהליך, אנו נוכל להשתמש בתהליך זה על מנת לבצע authentication למשתמשים ע”י שימוש ב PAM בתוכנות אשר מכניסות את המשתמש למערכת (תהליכי login ותהליכי הזדהות באופן כללי) , בצורה זו נוכל להעביר את המשתמש תהליך של זיהוי – מחד.
ומאידך, נוכל להשתמש ב PAM על מנת לבצע Authorization למשתמשים שרוצים להפעיל אפליקציה מסויימת, לדוג' משתמש שכבר נמצא במערכת , כאשר הוא ירצה להפעיל תוכנה מסויימת, הוא עשוי להידרש לעבור דרך תהליך האימות של PAM על מנת לאפשר לו להפעיל את התוכנה (הדבר נדרש בדרך כלל ע”י תוכנות ניהול שונות).

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

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

• הפעלה של תוכנית (כגון תוכנית login ) מפעילה קריאת הפעלה (initial call ) ל – linux-pam .
• linux-pam מבצע הפעלה של הקונפיגורציה שלו, למעשה הוא מפעיל את התיקיה pam.d שנמצאת תחת etc , במידה והתיקיה לא קיימת הוא יפנה לקובץ הקונפיגורציה pam.conf שנמצא תחת etc אם התיקייה קיימת (מה שאמור להיות) התהליך יתעלם מ pam.conf .
• בתוך התיקיה pam.d תהליך ה pam מחפש את קובץ הקונפיגורציה של האפליקציה שהפעילה אותו וטוען אותו. במידה ולא קיים קובץ שכזה התהליך יטען קובץ ברירת מחדל הקרוי other . בדרך כלל אמור להיות קובץ הנושא את שמה של האפליקציה שהפעילה את linux-pam והוא יהיה זה שייטען, במקרה כזה (מצב נורמאלי) ה PAM יתעלם מהקובץ other .
• מרגע שקובץ הקונפיגורציה נטען ל PAM ה PAM מתחיל לטעון את המודולים שמופיעים בו על פי סדר מסויים. כל המודולים נמצאים בתיקיה security שתחת התיקיה lib . מודולים אלו הינם קבצים בינארים שבדרך כלל יש להם תיפקודיות מוגבלת של בדיקה קצרה. בדרך כלל הבדיקה הקצרה שלהם תחזיר אחד מ 2 ערכים “עובר” או “לא עובר” (או truth או false ; או 1 או 0 ).
• התוצאה של הבדיקות של המודולים עוברת ל PAM ועל בסיס הקונפיגורציה (נניח אם יש false על בדיקה הכרחית ) PAM מגיע לשיקלול של תוצאה כללית של Truth או False , את התוצאה הזו הוא מעביר לאפליקציה ומכוון שהיא תומכת ב PAM (אם היא לא היתה היא לא היתה מפעילה אותו מלכתחילה) הדבר קובע את המשך פעולתה או אי פעולתה של האפליקציה.

ניקח כדוגמה 2 קובצי קונפיגורציה ממערכת Red Hat על מנת להמחיש את הפעילות (יש סיבה שדווקא מ Red Hat ויש סיבה לכך שנשתמש ב 2 קבצים וזה יוסבר בהמשך), הקבצים login ו- system-auth בהתאמה:

# cat /etc/pam.d/login 
#%PAM-1.0 
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so 
auth       include      system-auth 
account    required     pam_nologin.so 
account    include      system-auth 
password   include      system-auth 
# pam_selinux.so close should be the first session rule 
session    required     pam_selinux.so close 
session    optional     pam_keyinit.so force revoke 
session    include      system-auth 
session    required     pam_loginuid.so 
session    optional     pam_console.so 
# pam_selinux.so open should only be followed by sessions to be executed in the user context 
session    required     pam_selinux.so open 
session    optional     pam_ck_connector.so 
[root@localhost ~]# cat /etc/pam.d/system-auth 
#%PAM-1.0 
# This file is auto-generated. 
# User changes will be destroyed the next time authconfig is run. 
auth        required      pam_env.so 
auth        sufficient    pam_unix.so nullok try_first_pass 
auth        requisite     pam_succeed_if.so uid >= 500 quiet 
auth        required      pam_deny.so 
account     required      pam_unix.so 
account     sufficient    pam_succeed_if.so uid < 500 quiet 
account     required      pam_permit.so 
password    requisite     pam_cracklib.so retry=3 type= 
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok 
password    required      pam_deny.so 
session     required      pam_limits.so 
session     required      pam_unix.so 

מבנה הקובץ:
הקובץ מחולק לשורות , כל מודול מצוי בשורה נפרדת.
כל שורה מורכבת מ 4 עמודות בסיסיות:

• module type – התייחסות לסוג הבדיקה.
• control flag – התייחסות לדרישה מהמודול.
• path – ניתוב אל המודול (ספריית הבסיס היא כאמור /lib/security ).
• options – אופציות ופרמטרים המועברים אל המודול.

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

בדיקות אלו (בצורתן הכללית) בודקות דברים כגון קיום החשבון, נתונים על סיסמה, המיקום ממנו מגיע המשתמש (רשתי או מקומי) וכו' . ה module type מאפיין בצורה כללית את הסעיפים הללו , או במילים אחרות “מה אני בעצם בודק? “ האופציות הקיימות הינן :

• auth – דברים כללים השייכים לתהליך ה authentication
• account – נתונים ובדיקות השייכים לקיומו, ולוואלידיות של החשבון.
• passwd – נתונים ובדיקות השייכים לסיסמה.
• session – נתונים ובדיקות השייכים למיקום ממנו מתחבר המשתמש או לצורה ממנה מתחבר המשתמש ( מטפלים ברמת ה session ).

יש לציין כי המודולים לא רק שהם מבצעים בדיקות הם גם יכולים “לכפות מדיניות” .
כמו כן כדאי לדעת שלמרות שמרבית המודולים מבצעים בדיקה אחת קטנה, קיימים מודולים גנריים שיכולים לבדוק מספר דברים, מודולים אלו יכול להופיע במספר הגדרות של module type , לדוגמה, ניתן לראות בקובץ system-auth כי המודול הקרוי pam_unix מופיע בכל הסוגים של הבדיקות, הוא נמצא ב: auth, account, passwd ו- session .

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

• required – הבדיקה חייבת לעבור ולהחזיר תוצאת truth . אם בדיקה שכזו נכשלת , תהליך הבדיקה אמנם יימשך אבל בסופו של דבר ייכשל (צריכה להישאל השאלה למה בכלל להמשיך אותו, והתשובה לכך היא פשוטה, אם הוא ייכשל בצורה מיידית, אני כמישהו שמנסה לפרוץ אוכל “לתזמן” את הכישלון ועל בסיס זה להעריך מה “הפיל” אותי. מכוון שהבדיקה תימשך עד סופה אני לא אוכל “לתזמן את הכישלון”).

• sufficient – בדיקה זו “מקפיצה” את תהליך הבדיקה, כלומר אם אני מקבל ממנה תוצאת truth אזי שכל בדיקת אותו סעיף (כוונתי היא ל type )הסתיימה ואני מוקפץ ל type הבא . אם הבדיקה מחזירה תוצאה של false אני לא מוקפץ ואני עובר לבדיקה הבאה, כאשר הבדיקה הבאה היא בדך כלל בדיקה שתמיד מחזירה fales , לדוגמה pam_deny .

למעשה, ניתן לדבר על בנייה של ACL אשר במסגרתו אם נניח שיש לי ב type שאני עובר כרגע 4 בדיקות, כאשר השניה היא במצב של sufficient והשלישית היא pam_deny (שתפקידה הוא להחזיר false תמיד) , את הבדיקה הראשונה אני יעבור, אם אני עובר את השניה אני “מדלג” מעל ה pam_deny ואם אני לא עובר אותה אני “נופל” עם pam_deny .

• requisite – בדיקה שאם אני נכשל בה תהליך ה PAM מפסיק מיידית. בדרך כלל לא נראה יותר מידי הגדרות שכאלו מכוון שלא נרצה שפורץ יוכל “לתזמן את הכישלון” .

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

• include (לא קיים בכל ההפצות) – קיים בגרסאות חדשות יותר של PAM , מאפשר למעשה לטעון קובץ נוסף לתוך הקונפיגורציה.

אם נסתכל על הפצה כגון SLES 9 קובצי הקונפיגורציה של PAM הם די ארוכים ומורכבים (דבר שהיה טריוויאלי במרבית ההפצות) , Red Hat מאידך פתרו את זה ע”י בניה של מודול שנקרא pam_stack (שהפרמטר שלו היה שם של קובץ), כך שבמקום לבנות לכל תוכנית קובץ קונפיגורציה מפלצתי, היו יכולים לבנות קובץ מרכזי אחד שהכיל את הגדרות הבסיס לכל קובצי הקונפיגורציה (בגלל זה השתמשתי בדוגמה ב 2 קבצים) , במקרה של Red Hat מדובר בקובץ הקרוי system-auth . כך שכל קובץ קונפיגורציה הכיל בפועל את הדברים שייחודיים לו והוראות לטעון את system-auth .
מצד שני, אם הייתי רוצה לכוונן משהו שישפיע על כל קובצי הקונפיגורציה של PAM , לא הייתי נדרש לכוון כל קובץ וקובץ בנפרד אלא הייתי יכול לכוון את הקובץ הגנרי (מכוון שכולם טוענים אות הוא היה משפיע על כולם).
הטעינה אינה טעינה כללית אלא טעינה סידרתית, כלומר אם ב type שקרוי auth אני מבצע טעינה לקובץ חיצוני רק החלק של ה auth מהקובץ החיצוני ייטען , לאחר מכן אם אם טוען ב type של ה passwd לקובץ חיצוני רק הסעיף של passwd מהקובץ החיצוני ייטען.

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

 auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so

ולאחריה טעינה של קובץ שקרוי system-auth . הוא יבצע 4 בדיקות :

 auth        required      pam_env.so 
 auth        sufficient    pam_unix.so nullok try_first_pass 
  auth        requisite     pam_succeed_if.so uid >= 500 quiet 
 auth        required      pam_deny.so 

עכשיו יחזור תהליך הבדיקה לקובץ login וימשיך ל type של account , תתבצע בדיקה אחת:

 account    required     pam_nologin.so

ולאחר מכן שוב קריאה לטעינה של system-auth . הוא יבצע כ 3 בדיקות:

 account     required      pam_unix.so 
 account     sufficient    pam_succeed_if.so uid < 500 quiet 
  account     required      pam_permit.so

ושוב יחזור התהליך אל הקובץ login , ב type של passwd לא תתבצע בדיקה אלא טעינה של 3 בדיקות מהקובץ system-auth :

 password    requisite     pam_cracklib.so retry=3 type= 
 password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok 
 password    required      pam_deny.so 

נחזור ל login הוא יבצע 2 בדיקות :

 session    required     pam_selinux.so close 
  session    optional     pam_keyinit.so force revoke 

לאחר מכן ייטען שוב system-auth ויבצע 2 בדיקות:

  session     required      pam_limits.so 
  session     required      pam_unix.so 

התהליך יחזור אל הקובץ login ויתבצעו עוד 4 בדיקות שרלוונטיות ל type של session .

 session    required     pam_loginuid.so 
  session    optional     pam_console.so 
  # pam_selinux.so open should only be followed by sessions to be executed in the user context 
  session    required     pam_selinux.so open 
  session    optional     pam_ck_connector.so

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

שני העמודות האחרונות הינן path ו- option .
ה path מציין למעשה אם שם המודול (נקודת הייחוס היא התיקייה /lib/security ), הפרמרים או האופציות הינן ייחודיות לכל מודול.
ניתן הסבר קצר על המודולים הסטנדרטיים:

pam_securetty – תפקידו לבדוק אם מי שמנסה הוא root ואם כן האם הוא מנסה ממקום שרשום בקובץ securetty שנמצא ב etc (מה שאומר שאם אני ירשום מיקומים בקובץ securetty או ימחק כאלו, אני ישפיע על המיקום ממנו root יכול לעשות login לדוג' …. במערכת שרוצים להקשיח אותה ניתן למחוק את כל המידע מהקובץ ולהשאיר רק את tty1 מה שאומר ש root יוכל להיכנס למערכת רק מ tty1 ).

pan_nologin – תפקידו לבדוק אם קיים הקובץ nologin תחת התיקיה etc , אם הקובץ קיים, שום משתמש לא יוכל להיכנס (הבדיקה תחזיר false ) ורק root יוכל להיכנס למערכת.

pam_unix – סטנדרטי במערכות unix לטובת הליך הזיהוי (ניתן לכיוונון דרך הקובץ /etc/security/pam_unix.conf ) , בגרסאות הנוכחיות יכול להקרא גם unix2

pam_env – יכול לכוון משתני סביבה למשתמש.

pam_cracklib – בודק את האיכות (החוזק) של הסיסמה, על בסיס נקודות קרדיט.

pam_listfile – מאשר או שולל משתמש על בסיס קובץ טקסט בו הוא רשום (כפרמטר צריך להיות גם קובץ הטקסט) .

pam_time – מאשר או שולל גישה על בסיס זמן (ניתן לכיוון דרך קובץ הקונפיגורציה /etc/security/time.conf )

pam_limits – מגביל או מאשר שימוש במשאבי זיכרון ו- CPU למשתמשים או לאפליקציות, למעשה מיישם את הפקודה ulimit באופן אוטו' (ניתן לכיוונון דרך /etc/security/limits.conf ) .

pam_tally – יחסום כניסת משתמש לאחר X נסיונות כניסה שגויים (טוב לשימוש כנגד נסיונות לניחוש סיסמאות).

pam_mail – יודיע לטרמינל בו עובד המשתמש על כל הגעה של מייל חדש .

כמו שראינו בדוגמאות, קיימים מספר מודולים שניתנים לכיוונון באמצעות קובצי קונפיגורציה, ריכוז הקבצים בברירת המחדל הוא /etc/security . מדובר בעיקר במודולים ה”גדולים” עם זאת כמעט כל מודול יכול לקבל קונפיגורציות דרך יישום של פרמטרים בעמודה האחרונה (העמודה של ה option ) .

נשתמש לצורך הדוגמה באפשרות לחסום או לאפשר כניסה של משתמשים למערכת ע”י בניית קובץ טקסט שמכיל את שמות המשתמשים (אגב ניתן ליישם את הדוגמה הזו על הפעלה של כל אפילקציה שעוברת דרך PAM ) , לשם כך הדבר הטבעי בעבורנו יהיה להשתמש ב pam_listfile , נוסיף אותו לקובץ תצורה של ה PAM השייך לתוכנית ה login בצורה הבאה:

 auth required /lib/security/pam_listfile.so onerr=fail  item=user sense=allow
  file=/etc/users-allow.txt

הסבר קצר:
כאמור אנו מפעילים את המודול listfile על מנת לאפשר קריאת נתונים מקובץ.
onerr – מגדיר מה תיהיה התנהגות המודול כאשר תקרא טעות (לדוג' קובץ לא קיים או שלא קריא) , בדוגמה שלנו אם תתקיים טעות בפעילות המודול המודול יחזיר הודעת שגיאה.
item – מהו הגורם הרשום בקובץ, במקרה שלנו אלו משתמשים (יכול להיות גם tty, קבוצות , shell וכיוצ”ב)
sense – מהי התנהגות ברירת המחדל ל item שרשום בקובץ, כלומר האם המשתמשים בקובץ נאפשר להם או לא .
file- ניתוב אל קובץ הטקסט.

בצורה שכזו אנו יכולים להגדיר פעילות של מודול דרך הגדרת פרמטרים שלו.
על מנת לקבל מידע נוסף על מודולים , הפרמטרים האפשריים לגביהם, ה type שבהם הם עובדים וכו', יש בתיקיית /usr/shar/doc/pam-xxx הסברים לכך (בהפצות SuSE זה יהיה תחת /usr/share/doc/packages ) .