לדלג לתוכן

Asset B: Facilitator Guide – Chapter 13

1. שרשרת האתחול: מ-Boot ROM דרך LLB ועד הקרנל במחשבי Apple Silicon

Objective: להסביר את השלבים שמערכת Apple Silicon עוברת מרגע הלחיצה על כפתור ההדלקה ועד לעליית הקרנל, בדגש על שרשרת האמון (Chain of Trust).

Discussion - Script: "חברים, כשאתם לוחצים על כפתור ההדלקה במק מבוסס Apple Silicon, זה כבר לא ה-Boot הסטנדרטי שהכרנו פעם מאינטל. כל פעם שהמחשב עולה הוא נבדק מול שרשרת שלמה כדי לוודא שההפעלה מאובטחת וששום תוכנה זדונית לא השתלטה עליו לפני שהמערכת בכלל עלתה. התהליך מתחיל ברכיב שנקרא Boot ROM, שצרוב על גבי החומרה. הוא קורא את ה-LLB, ה-Low-Level Bootloader. ה-LLB עושה בדיקות בסיסיות לחומרה ואז מעביר את השרביט ל-iBoot. תפקידו של ה-iBoot הוא להעלות את הקרנל של macOS, והקרנל בסוף טוען את מערכת ההפעלה שיושבת ב-SSV. כל שלב מוודא את השלב הבא באמצעות חתימות קריפטוגרפיות. אם יש חוליה אחת בשרשרת שלא מתאימה – המק פשוט יעצור ולא יעלה."

Demonstration:

  1. הצג תרשים זרימה בסיסי (אפשר גם לצייר על הלוח) המראה את השלבים: Boot ROM -> LLB -> iBoot -> Kernel -> macOS.
  2. הסבר כיצד ב-Apple Silicon אין יותר SMC נפרד או NVRAM בצורה המסורתית; הכל מובנה בתוך ה-SoC.
  3. הצג ב-System Information את אזור ה-Hardware כדי להראות את ה-System Firmware Version.
Instructor Deep-Dive * **Boot ROM:** This is hardware-based, read-only memory inside the SoC. It holds the Apple Root Certificate Public Key and verifies the LLB. * **Low-Level Bootloader - LLB:** Initializes basic hardware (like Unified Memory) and verifies the iBoot stage. It also maintains basic security properties. * **iBoot:** This is the main bootloader. It verifies the kernel cache (collection of kernel and essential kexts) and parses the DeviceTree. iBoot is also responsible for showing the boot logo and progressing the loading bar. * **Local Policy:** In Apple Silicon, each Volume can have its own Local Policy (Full Security, Reduced Security, etc.). iBoot reads this policy to know whether it can load older macOS versions or third-party kexts.

2. Startup Security Utility: שינוי רמות האבטחה (Full Security מול Reduced Security) ולמה שנרצה להוריד אבטחה

Objective: להדגים כיצד פועל מנגנון ה-Startup Security Utility ב-Recovery Mode ואת המשמעויות של שינוי מדיניות האבטחה (Security Policy).

Discussion - Script: "זוכרים שאמרתי לכם שכל Volume (ווליום) ב-Apple Silicon נבדק בנפרד? אם ניכנס עכשיו ל-Recovery Mode, נוכל לפתוח כלי שנקרא Startup Security Utility. פה, בגלל שאני ב-Apple Silicon, יש לי בעצם Security Policy לכל אחד מהווליומים בנפרד. ברירת המחדל היא Full Security. זה מבטיח שרק מערכת הפעלה נוכחית, או כזו שנחתמה ונמצאה מהימנה על ידי אפל, יכולה לרוץ. התהליך הזה דורש אינטרנט כדי לוודא מול שרתי אפל שהגרסה עדיין לגיטימית. אבל מה קורה אם אנחנו מפתחים ורוצים להתקין מערכת הפעלה ישנה? או מה קורה אם אנחנו מוזיקאים וחייבים דרייבר לכרטיס קול? בשביל זה יש לנו את ה-Reduced Security. המצב הזה מאפשר לנו להריץ גרסאות ישנות יותר ולאפשר ניהול משתמש של הרחבות קרנל (Kernel Extensions). שימו לב ש-Reduced Security לא מבטל לחלוטין את האבטחה, הוא פשוט נותן למשתמש המקומי (מנהל המערכת) לקבל החלטות שאפל בדרך כלל חוסמת."

Demonstration:

  1. הפעל מחשב Apple Silicon לתוך ה-Recovery Mode (לחיצה ארוכה על כפתור ההפעלה עד להופעת Options).
  2. היכנס לתפריט Utilities ובחר ב-Startup Security Utility.
  3. בחר את ה-Volume הרלוונטי ולחץ על Security Policy.
  4. הצג לסטודנטים את ההבדל הוויזואלי והטקסטואלי בין Full Security ל-Reduced Security.
  5. הראה את שתי תיבות הסימון תחת Reduced Security (המאפשרות User Management של Kexts ו-Remote Management).
Instructor Deep-Dive * **Full Security:** Requires network connection to reach Apple’s TSS (Tatsu Signing Server) during installation/updates to get a personalized signature (APTicket) based on the Mac's ECID. This prevents rollback attacks (downgrading to a vulnerable OS version). * **Reduced Security:** Allows running any signed macOS version, even if Apple revoked it. Crucially, it disables the requirement for online TSS checks for older OS boots. It enables the checkboxes for `Allow user management of kernel extensions from identified developers` and `Allow remote management of kernel extensions and automatic software updates`. * **Permissive Security:** (Advanced/Hidden) Used by developers for running unauthenticated custom kernels (requires boot-args configuration via `csrutil`).

3. הרחבות קרנל (Kexts): למה אפל הורגת אותן ואיך מתקינים אותן בכל זאת במק מודרני

Objective: להסביר את המעבר מ-Kernel Extensions ל-System Extensions ואיך מאשרים Kext כשהמערכת דורשת זאת.

Discussion - Script: "בואו נדבר קצת היסטוריה ועל למה אפל הורגת את הדרייברים של הקרנל, ה-Kexts. בעבר, כדי שתוכנת אודיו או אנטי-וירוס ייעשו את העבודה שלהם, הם היו חייבים לרוץ ברמת הקרנל. הבעיה היא שהקרנל זה הלב של המערכת. אם דרייבר ברמת הקרנל קורס – כל המחשב קורס, וזה מה שגורם ל-Kernel Panic. בנוסף, דרייבר בקרנל אומר שיש לו גישה להכל, שזה סיוט אבטחתי. לכן, אפל הציגה את ה-System Extensions, שרצות ב-User Space ולא בקרנל. אם הן קורסות, המחשב ממשיך לעבוד. אבל עדיין יש יצרנים, במיוחד של חומרת אודיו או תוכנות וירטואליזציה ישנות, שלא עברו לשיטה החדשה ודורשים Kexts. כדי להתקין Kext במק מודרני, אנחנו צריכים לרדת ל-Reduced Security, לסמן את התיבה שמאפשרת ניהול של הרחבות קרנל, לאשר את המפתח של היצרן בהגדרות המערכת (System Settings > Privacy & Security), ואז לעשות אתחול כדי לאפשר ל-iBoot לבנות מחדש את ה-Auxiliary Kernel Collection (AKC). זה כאב ראש אמיתי, וזה תוכנן להיות ככה כדי שיצרנים יפסיקו להשתמש בהן!"

Demonstration:

  1. פתח את אפליקציית System Information (מידע מערכת), ונווט תחת קטגוריית Software ל-Extensions. הראה כיצד ניתן לראות אילו הרחבות נטענו בפועל (Loaded: Yes).
  2. פתח חלון Finder ונווט לספרייה /Library/Extensions כדי להראות היכן יושבים קבצי ה-Kext של צד שלישי בפועל.
  3. סמלץ את הופעת חלון ה-System Extension Blocked ב-System Settings > Privacy & Security והסבר למשתמשים שהם יצטרכו לאשר ולאתחל.
Instructor Deep-Dive * **Kernel Extensions - Kexts:** Run in ring 0 (kernel space). Have unrestricted access to memory and hardware. Can easily cause a Kernel Panic (KP). * **System Extensions:** Run in user space. Categorized into Network Extensions, Endpoint Security Extensions, and Driver Extensions (DriverKit). * **Auxiliary Kernel Collection - AKC:** In Apple Silicon, third-party Kexts are no longer injected directly into the kernel memory on the fly. They are pre-compiled and linked into an AKC file during boot. The OS verifies the signature of the AKC before loading it. * **kmutil:** The modern CLI tool that replaced `kextstat` and `kextutil` for managing and viewing the Kernel Collections. Instructors can demonstrate running `kmutil showloaded` in Terminal to view active extensions directly from the command line.

4. תיבול ארגוני: אבטחת ה-Firmware, ניהול מפתחות שחזור מוסדיים במצב Boot, והגבלת משתמשים מלשנות רמת אבטחה

Objective: להבין את הכלים שיש ל-IT כדי לנעול את תהליך האתחול, למנוע שינויי אבטחה ולנהל גישה ל-Recovery באמצעות מפתחות שחזור.

Discussion - Script: "אז ראינו שמשתמש עם הרשאות מנהל מקומי (Admin) יכול להיכנס ל-Recovery, להוריד את רמת האבטחה ל-Reduced Security, ולהתקין דרייברים מפוקפקים. בעולם הארגוני, זה בדיוק מה שאנחנו רוצים למנוע! איך מונעים ממשתמשים לשחק לנו ברמות האבטחה? פה נכנס ה-MDM. ברגע שמחשב מנוהל דרך ה-MDM, במיוחד אם הוא תחת ADE (Zero-Touch), אנחנו יכולים להפעיל Recovery Key (מפתח שחזור) מוסדי (IRK/PRK). כשהמפתח הזה מוגדר ומערכת ההצפנה FileVault פעילה, המשתמש לא יכול סתם ככה להיכנס ל-Recovery ולשנות הגדרות ב-Startup Security Utility מבלי שיהיה לו את המפתח, או מבלי שאיש IT יאשר זאת דרך ה-MDM. בנוסף, פרופילי MDM מסוימים יכולים לדרוס לחלוטין את היכולת של המשתמש לאשר Kexts בעצמו, ולחייב שכל Kext שיאושר יצטרך לקבל Payload (פיילוד) (Payload) מתאים דרך ה-MDM עם ה-Team ID המדויק של המפתח. כך הארגון מוודא שאף תוכנה לא מאושרת ברמת הקרנל מבלי שעברה בקרה."

Demonstration:

  1. הצג דוגמה של Payload מתוך מערכת MDM (למשל Jamf/Intune או אפילו בתרשים) של ה-Kernel Extension Policy. הראה היכן מזינים את ה-Team ID.
  2. הראה כיצד פרופיל System Extensions מתנהג באופן דומה ומאפשר הפעלה שקטה בלי לערב את המשתמש.
  3. הסבר כיצד ב-Apple Silicon אין יותר Firmware Password כמו שהייתה במחשבי אינטל, ובמקומה משתמשים במנגנון ה-FileVault וב-MDM Bootstrap Token לאבטחת הגישה ל-Recovery.
Instructor Deep-Dive * **Firmware Password:** Dead on Apple Silicon. The equivalent protection is FileVault. If FileVault is on, Recovery requires a volume owner's password or the Recovery Key (PRK/IRK) to access the Startup Security Utility. * **MDM Limitations on Security Level:** Even if an Admin user boots into Recovery, the MDM can restrict the machine to only boot Full Security, overriding the local policy. * **Kext Policy Payload:** Allows IT to silently approve Kexts based on the developer's Team ID. However, on Apple Silicon, even with an MDM profile, changing from Full to Reduced Security to actually *load* the Kext requires the user to reboot into Recovery manually (unless the device was pre-provisioned via ADE and MDM specifically triggers a remote downgrade to Reduced Security using the Bootstrap Token). * **CLI Validation:** Administrators can verify System Integrity Protection status by running `csrutil status` and the Kext consent status by running `spctl kext-consent status` via terminal or script.