לדלג לתוכן

Chapter 08: תהליכי רקע ומערכת Launchd - Facilitator Guide (Asset B)

הנחיית מדריך: מסמך זה משמש כתוכנית שיעור ותסריט הדרכה (Script) לפרק 8, "תהליכי רקע ומערכת Launchd". עקוב אחר התסריט המוצע והשתמש בבלוקים של ההרחבה (Deep-Dive) כדי לענות על שאלות עומק טכניות. יש לשמור על תאימות 1:1 של כותרות מול Asset A. הדרכה זו מתמקדת בכלים ויזואליים וגרפיים לזיהוי וטיפול בתהליכי רקע.

1. הלב של המערכת: תהליך launchd וההבדל בין LaunchDaemons ל-LaunchAgents

Objective: להבין את התהליך הראשון שעולה במערכת (PID 1) ואת ההבדל הקריטי בארכיטקטורה בין שירותים ברמת המערכת (LaunchDaemons) לשירותים ברמת המשתמש (LaunchAgents) בעזרת Activity Monitor ו-Finder.

Discussion - Script: "חברים, בואו נדבר על המנוע שמחזיק את כל macOS למעלה. אחרי שהמחשב מסיים את תהליך הבוט (Boot) והקרנל נטען, התהליך הראשון שרץ במערכת הוא תהליך שנקרא launchd. ה-PID שלו, כלומר ה-Process ID, הוא תמיד 1. התהליך הזה הוא האבא של כל שאר התהליכים במערכת.

עכשיו, בעולם התהליכי רקע, אנחנו צריכים להפריד בין שני מושגים קריטיים שנתקלים בהם המון: LaunchDaemons ו-LaunchAgents. ההבדל ביניהם הוא מאוד פשוט אבל מהותי להבנה. אם יש את המילה 'Launch', הכוונה היא שמשהו עולה אוטומטית. דימון (LaunchDaemon) זה משהו שתמיד רץ ברקע ברמת המחשב כולו. ברגע שהמחשב עשה בוט, הדימון עולה ומנסה לרוץ, גם אם אף משתמש לא עשה Login. לכן, אין להם גישה ל-GUI או למסך של המשתמש. לעומת זאת, סוכן (LaunchAgent) הוא Background Process (תהליך רקע) שעולה רק כאשר המשתמש (User) עושה Login למערכת. ה-Agent רץ תחת ההרשאות של אותו משתמש ויכול לתקשר עם חוויית המשתמש. לכן, אם נסתכל בתיקיית ~/Library של היוזר הספציפי שלנו, לעולם לא נמצא שם תיקיית LaunchDaemons, כי המשתמש לא יכול להריץ שירות ברמת הבוט של המחשב."

Demonstration:

  1. פתח את Activity Monitor (מתוך /Applications/Utilities).
  2. בתפריט העליון, בחר View -> All Processes, Hierarchically.
  3. הראה לכיתה את תהליך ה-launchd (בעל PID 1), שממנו מתפצלים שאר התהליכים.
  4. פתח Finder ונווט לתיקיית /Library.
  5. הראה לכיתה שיש שם גם תיקיית LaunchAgents וגם תיקיית LaunchDaemons.
  6. נווט אל תיקיית הבית של המשתמש: ~/Library (באמצעות Go -> Go to Folder).
  7. הראה שיש שם רק תיקיית LaunchAgents (ואין LaunchDaemons).
Instructor Deep-Dive (הרחבה למדריך) * **ההיסטוריה של launchd:** ה-`launchd` הוצג ב-Mac OS X Tiger (10.4) כתחליף למנגנוני ה-init הישנים של Linux/Unix כמו `init`, `rc`, `cron`, ו-`xinetd`. אפל ריכזה את כל ניהול תהליכי הרקע למערכת אחת חכמה המבוססת XML (Plists). * **היררכיית תיקיות מלאה:** * `/System/Library/LaunchDaemons` - שירותי ליבה של אפל ברמת המערכת (SSV, חסום לשינוי). * `/System/Library/LaunchAgents` - שירותי אפל ברמת המשתמש (SSV). * `/Library/LaunchDaemons` - שירותי צד-שלישי שעולים בבוט (אנטיוירוס, MDM). * `/Library/LaunchAgents` - שירותי צד-שלישי שעולים לכל משתמש במחשב (סנכרון דרייבים, תפריט עליון של כלי האבטחה). * `~/Library/LaunchAgents` - שירותי צד-שלישי שעולים אך ורק למשתמש הספציפי שמותקנים בפרופיל שלו (כמו Spotify או תוכנות אישיות). * **בדיקה בטרמינל (למדריך בלבד):** פקודת `ps -p 1` ב-Terminal תראה שהתהליך הראשון הוא `launchd`. * **שירות מול תהליך:** ה-`launchd` מנהל Job. אם ה-Job קורס (Crash), ה-`launchd` יזהה זאת וידליק אותו מחדש באופן מיידי בהתאם להגדרות `KeepAlive` שלו בקובץ ה-Plist. לכן שימוש ב-Force Quit על הליך כזה לא יעזור, כי הוא יחזור לפעול תחת PID חדש.

2. Activity Monitor עמוק: קריאת זיכרון (Memory Pressure) ומציאת זוללי משאבים (CPU)

Objective: ללמד את התלמידים כיצד לאבחן איטיות ותקלות באמצעות קריאה נכונה של מדדי המעבד והזיכרון ב-Activity Monitor.

Discussion - Script: "כשיש תקלה של מחשב איטי, האינסטינקט של רובנו הוא לפתוח את ה-Activity Monitor (או Task Manager בווינדוס). אבל איך אנחנו קוראים את הנתונים שם נכון ב-macOS? בואו נתחיל מהמעבד (CPU). למטה במסך, תראו את ה-System, ה-User, וה-Idle. ה-Idle הוא המספר הכי חשוב לנו - הוא מראה כמה מהמעבד פנוי. אם ה-Idle שלכם קרוב לאפס, סימן שהמחשב שלכם נחנק. אנחנו יכולים למיין את התהליכים לפי % CPU כדי לזהות מי התהליך הסורר ולבצע לו Force Quit (יציאה מאולצת) (Force Quit). החלק המעניין באמת הוא הזיכרון (Memory). משתמשים המון פעמים נבהלים שכתוב ש-14GB מתוך 16GB נמצאים בשימוש, וחושבים שהם צריכים עוד זיכרון (RAM). ב-macOS המודרנית, זיכרון פנוי הוא זיכרון מבוזבז. המערכת שומרת קבצים במטמון (Cache) כדי שהמחשב יהיה מהיר יותר. אז איך נדע אם באמת חסר לנו זיכרון? אנחנו מסתכלים רק על ה-Memory Pressure (לחץ הזיכרון). זהו גרף צבעוני בתחתית המסך. ירוק אומר שהכל תקין, צהוב אומר שהמערכת התחילה לדחוס זיכרון ולפעול בצורה אגרסיבית, ואדום אומר שנגמר לנו לחלוטין ה-RAM והמערכת התחילה להשתמש בדיסק הקשיח (Swap Memory), מה שגורם להאטה קשה מאוד בביצועים."

Demonstration:

  1. פתח את האפליקציה Activity Monitor.
  2. נווט ללשונית CPU והצבע על נתוני ה-Idle בתחתית המסך.
  3. הצג את ההיררכיה של התהליכים (בחר בתפריט View -> All Processes, Hierarchically) כדי להראות מי תהליך האב ומי תהליכי הבן.
  4. עבור ללשונית Memory.
  5. הסב את תשומת הלב לגרף ה-Memory Pressure.
  6. הצבע על השדות "App Memory", "Wired Memory", ו-"Compressed".
Instructor Deep-Dive (הרחבה למדריך) * **Wired Memory:** זיכרון שמערכת ההפעלה והקרנל נעלו. זה זיכרון שחייב להיות זמין פיזית ב-RAM ואי אפשר לדחוס אותו או להעביר אותו ל-Swap (דיסק). * **Compressed Memory:** כאשר המערכת מזהה שה-RAM מתחיל להתמלא (לקראת לחץ צהוב), היא דוחסת אקטיבית את הזיכרון של אפליקציות שלא נמצאות בשימוש מיידי, ומשחררת נפח במקום לכתוב לדיסק הקשיח. בארכיטקטורת Apple Silicon (עם Unified Memory), הדחיסה מתבצעת ברמת החומרה על גבי ה-SoC והיא מהירה להפליא, לכן מחשבי מק עכשוויים יודעים להתמודד עם 8GB או 16GB זיכרון בצורה יעילה בהרבה מ-PC מקביל. * **Swap Used:** כאשר אפילו הדחיסה לא עוזרת וה-Memory Pressure הופך לאדום, המערכת כותבת עמודי זיכרון לכונן ה-SSD (קובץ swapfile בנתיב `/private/var/vm/`). כתיבה וקריאה מ-SSD (גם אם הוא מהיר מאוד) תמיד תהיה משמעותית איטית יותר מ-RAM, ולכן המשתמש ירגיש איטיות משמעותית. * **פרוססים כפולים ב-Activity Monitor:** אל תופתעו לראות מספר פרוססים עם אותו שם, למשל באפליקציות כמו Chrome שמשתמשות בארכיטקטורת Multi-Process כדי לאבטח ולהפריד טאבים ל-Sandboxing משלהם.

3. קבצי Plist: קריאה ואבחון של קבצי XML וניהול פריטי התחברות (Login Items)

Objective: הכרת המבנה של קבצי Property List (Plist) ואיך הם מגדירים את חוקי הריצה, ושימוש ב-System Settings כדי לנהל תהליכי רקע בצורה חזותית.

Discussion - Script: "הבנו מה זה LaunchDaemons ו-LaunchAgents. אבל איך launchd יודע מתי להריץ אותם? איך הוא יודע האם לעשות להם ריסטארט כשהם קורסים או כל כמה זמן להפעיל אותם? התשובה נמצאת בקבצי Plist (Property List). קובץ Plist הוא בעצם קובץ תצורה במבנה של XML (לרוב, לפעמים הוא בינארי). הקבצים האלו יושבים בתוך תיקיות ה-LaunchDaemons או LaunchAgents שראינו קודם. אם נפתח אחד כזה, נראה מפתחות (Keys) שמסבירים למערכת בדיוק מה לעשות. למשל, מפתח בשם RunAtLoad עם ערך True אומר ל-launchd: 'הפעל את התהליך הזה ברגע שהקובץ נטען'. מפתח בשם KeepAlive הוא החשוב מכולם לתמיכה. הוא קובע שאם התהליך נסגר או קורס - המערכת מיד תעלה אותו מחדש, מה שמסביר למה לפעמים אנחנו לא מצליחים להרוג אפליקציית רקע. בנוסף, החל מ-macOS Ventura, יש לנו דרך גרפית מצוינת לראות ולנהל את כל סוכני הרקע ותהליכי ההפעלה - תחת Login Items & Extensions ב-System Settings. שם נוכל לראות בדיוק אילו אפליקציות מורשות לרוץ ברקע ולכבות אותן במקרה הצורך."

Demonstration:

  1. פתח Finder ונווט שוב ל-/Library/LaunchDaemons.
  2. בחר את אחד מקבצי ה-.plist של אפליקציה כלשהי המותקנת במערכת (למשל Microsoft, או של ה-MDM).
  3. לחץ על מקש הרווח (Spacebar) כדי לפתוח אותו ב-Quick Look, או פתח אותו עם TextEdit.
  4. הראה לכיתה את המבנה של ה-XML. הצבע על התגים <key> ומתחתיהם את הערך (למשל <true/> או <integer>7200</integer>).
  5. חפש יחד עם הכיתה את המפתח ProgramArguments המצביע על הנתיב האמיתי של תהליך ההפעלה ברקע.
  6. פתח את System Settings.
  7. נווט אל General -> Login Items & Extensions.
  8. הצבע על הרשימה של Allow in the Background - הראה כיצד המתגים כאן מייצגים את סוכני הרקע והשירותים המותקנים, והסבר שכיבוי מתג ימנע מה-Plist להיטען מחדש.
Instructor Deep-Dive (הרחבה למדריך) * **שליטה באמצעות `launchctl`:** הדרך הטכנית לטעינת ופריקת שירותים היא באמצעות מערך פקודות חדש כדי למנוע טעויות הקשר בין User ל-System: * הפקודה לפריקה (עצירת דימון/אייג'נט): `sudo launchctl bootout system /Library/LaunchDaemons/com.example.daemon.plist` * הפקודה לטעינה (הפעלת דימון/אייג'נט): `sudo launchctl bootstrap system /Library/LaunchDaemons/com.example.daemon.plist` * **המרת קבצים בינאריים:** לעיתים קרובות קבצי Plist יהיו בפורמט בינארי שאינו קריא ב-TextEdit. מערכת macOS מספקת את הכלי `plutil` בטרמינל כדי להמיר אותם למבנה XML קריא: `plutil -convert xml1 /path/to/file.plist`. * **Disabled Overrides - BTM:** כאשר משתמש מכבה שירות רקע ב-System Settings תחת Login Items, המערכת לא באמת מוחקת את קובץ ה-Plist, אלא רושמת 'Disabled Override' בדאטהבייס פנימי במערכת שנקרא Background Task Management (BTM). כך ה-`launchd` יודע להתעלם מקובץ ה-Plist בבוט הבא.

4. תיבול ארגוני: איתור ה-Agent של מערכת ה-MDM, הבנת ססטוס הסנכרון שלו ומה עושים כשהוא קורס

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

Discussion - Script: "בסביבה ארגונית, הדיבור על LaunchDaemons הוא לא תיאורטי - זה הלחם והחמאה שלנו. כשמחשב מצטרף למערכת ניהול (MDM) - בין אם זה Jamf, Intune, או Kandji - מערכת הניהול שותלת Background Process (תהליך רקע) מרכזי במחשב. זהו ה-MDM Agent. ה-Agent הזה בנוי משני חלקים:

  1. יש לו LaunchDaemon שרץ ברמת המערכת ודואג לתקשורת הקריטית והרציפה מול השרת, למשיכת Configuration Profiles (פרופילי תצורה), ולריצת פקודות אדמין (שאין ליוזר הרשאה להריץ).
  2. במקביל, כמעט תמיד יש לו גם LaunchAgent שרץ בסשן של המשתמש. למה? כי ה-MDM רוצה להקפיץ חלונות למשתמש. הוא רוצה להראות לו התראות, או לספק לו קטלוג Self-Service. הדימון עצמו לא יכול לצייר חלון על המסך כי אין לו גישה ל-GUI, לכן הוא מדבר עם ה-Agent שמריץ את הממשק הגרפי. כשמשתמש מדווח על איטיות מחרידה, לפעמים זה סוכן האבטחה (EDR) או ה-MDM שנתקעו. אם ה-Agent הזה לא מתקשר, הפקודות שלנו מרחוק פשוט לא יעבדו. נשתמש ב-Activity Monitor כדי לזהות אותו, ואם ננסה לעשות לו Force Quit - ה-launchd מיד יקפיץ אותו בחזרה בזכות המפתח KeepAlive שלו ב-Plist."

Demonstration:

  1. פתח שוב את תיקיית /Library/LaunchDaemons.
  2. הראה קובץ Plist ששייך לארגון (למשל, com.jamfsoftware.jamf.daemon.plist או המקביל של Microsoft/Kandji).
  3. פתח Activity Monitor, ועשה חיפוש בשורת החיפוש עבור התהליך (למשל חפש "jamf", "kandji" או "mdmclient").
  4. בצע Force Quit (כפתור ה-X למעלה) לתהליך של הסוכן.
  5. הראה לכיתה כיצד כעבור שניה אחת בדיוק, התהליך חוזר לרשימה עם מזהה תהליך (PID) חדש, תוצר של הגדרת ה-KeepAlive.
  6. הדגם פתיחת תוכנת Self Service או הפעלת סנכרון באופן גרפי מתוך שורת התפריטים (Menu Bar) כדי להראות איך התהליך מגיב ב-Activity Monitor ויוצר עומס רגעי.
Instructor Deep-Dive (הרחבה למדריך) * **APNs מול ביצוע Polling:** מערכות MDM ב-macOS מסתמכות על שני ערוצים מקבילים: 1. **APNs - Apple Push Notification service:** שירות שקט השומר על חיבור TCP (פורט 5223) פתוח מול שרתי אפל. כאשר הארגון שולח פקודה, שרת ה-MDM מדבר עם אפל, ואפל מעירה את המחשב המקומי (אפילו מתוך מצב שינה) ומורה לסוכן ה-MDM למשוך את הפקודה. 2. **Polling:** לוגיקה שמקודדת בתוך קובץ ה-Plist של הסוכן (באמצעות `StartInterval`) הגורמת לדימון להתעורר כל X דקות (לרוב 15-30 דקות) ולשאול את השרת יזומה "האם יש מדיניות חדשה עבורי?". * **תצפית על לוגים בעזרת Console/Terminal:** כדי לראות תעבורה חיה של סוכן ה-MDM, ניתן להשתמש בפקודת `log stream --predicate 'process == "mdmclient"' --info` ב-Terminal, המספקת אבחון מהיר במקרה של בעיות סנכרון. * **תקלות Trust:** אחת הבעיות הנפוצות בסוכני MDM היא כאשר תעודת ה-Device Certificate (שבזכותה השרת מאמין לדימון) פגה תוקף או נפגמת ב-Keychain (מסוג System). הפתרון הוא הרצת פקודות שיקום Trust של ה-MDM הרלוונטי או הרשמה מחדש (Re-enrollment). * **שליטה באנטיוירוס / EDR:** מרבית כלי ה-EDR הארגוניים מכילים LaunchDaemons חזקים במיוחד שמוגנים בטכנולוגיית Anti-Tampering. אפילו ה-`sudo launchctl bootout` לא יצליח להרוג אותם, אלא אם המחשב נמצא ב-Safe Mode או שסיפקנו קוד שחרור (Uninstall Password) ייעודי.

(סיום פרק 8 - מדריך למנחה)