שיעור 13: תהליך האתחול¶
חלק ב': מדריך העברה למרצה (vEXP)
1. שרשרת האתחול: מ-Boot ROM דרך LLB ועד הקרנל במחשבי Apple Silicon¶
מטרת השיעור (Objective): להסביר את השלבים שמערכת Apple Silicon עוברת מרגע הלחיצה על כפתור ההדלקה ועד לעליית הקרנל, בדגש על שרשרת האמון (Chain of Trust).
תסריט שיחה (Discussion - Script):
- "חברים, כשלוחצים על כפתור ההדלקה במק מבוסס Apple Silicon – זה כבר לא ה-Boot של אינטל."
- כל הפעלה נבדקת מול שרשרת אבטחה שלמה:
- המטרה: לוודא ששום תוכנה זדונית לא השתלטה לפני עליית המערכת.
- התהליך:
- Boot ROM: מתחיל את התהליך (צרוב על החומרה).
- LLB (Low-Level Bootloader): נקרא על ידי ה-Boot ROM, עושה בדיקות חומרה בסיסיות.
- iBoot: מקבל את השרביט מה-LLB, תפקידו להעלות את הקרנל.
- Kernel (קרנל): נטען על ידי iBoot וטוען את מערכת ההפעלה (SSV).
- כל שלב מוודא את הבא בתור באמצעות חתימות קריפטוגרפיות.
- חוליה אחת לא מתאימה? המק פשוט יעצור ולא יעלה.
הדגמה מעשית (Demonstration):
- הצג תרשים זרימה של השלבים (אפשר לצייר על הלוח):
Boot ROM -> LLB -> iBoot -> Kernel -> macOS. - הסבר על השינויים ב-Apple Silicon:
- אין SMC נפרד.
- אין NVRAM מסורתי.
- הכל מובנה בתוך ה-SoC.
- פתח System Information:
- נווט לאזור ה-Hardware.
- הצג את ה-System Firmware Version.
Instructor Deep-Dive
- Boot ROM:
- Hardware-based, read-only memory inside the SoC.
- Holds the Apple Root Certificate Public Key.
- Verifies the LLB.
- Low-Level Bootloader (LLB):
- Initializes basic hardware (e.g., Unified Memory).
- Verifies the iBoot stage.
- Maintains basic security properties.
- iBoot (Main Bootloader):
- Verifies the kernel cache (kernel + essential kexts).
- Parses the DeviceTree.
- Responsible for the boot logo and loading bar.
- Local Policy:
- Each Apple Silicon Volume has its own Local Policy (Full/Reduced Security).
- iBoot reads this to determine if older macOS versions or third-party kexts can be loaded.
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:
- מאפשר לנהל Security Policy נפרד לכל ווליום.
- (פרט טריוויה למדריך מתוך ה-DeepDive: בעשור הראשון של Mac OS X בכלל לא הייתה מחיצת Recovery! רק ב-2011 (Lion) היא הוצגה לראשונה. היום ב-Apple Silicon קיימת מערכת 1TR (One True Recovery) שעולה ישירות מהחומרה ומייתרת את אינספור קיצורי המקלדת של העבר).
- Full Security (ברירת מחדל):
- מבטיח הרצת מערכת הפעלה נוכחית/לגיטימית בלבד.
- דורש אינטרנט לאימות מול שרתי אפל.
- מתי נשתמש ב-Reduced Security?
- כמפתחים (להתקנת מערכת הפעלה ישנה).
- כמוזיקאים (לדרייבר של כרטיס קול).
- משמעות המצב:
- מאפשר הרצת גרסאות ישנות.
- מאפשר ניהול משתמש של הרחבות קרנל (Kernel Extensions).
- לא מבטל אבטחה לחלוטין – אלא מעביר את ההחלטה למשתמש המקומי (Admin).
הדגמה מעשית (Demonstration):
- הפעל מק ל-Recovery Mode (לחיצה ארוכה על כפתור ההפעלה עד ל-Options).
- פתח Startup Security Utility מתוך תפריט Utilities.
- בחר ווליום רלוונטי ולחץ על Security Policy.
- השווה ויזואלית וטקסטואלית בין Full Security ל-Reduced Security.
- הצג את שתי תיבות הסימון של Reduced Security:
- User Management של Kexts.
- Remote Management.
Instructor Deep-Dive
- Full Security:
- Requires network to reach Apple’s TSS (Tatsu Signing Server) during installation/updates.
- Retrieves a personalized signature (APTicket) based on the Mac's ECID.
- Prevents rollback attacks (downgrading to vulnerable OS).
- Reduced Security:
- Allows running any signed macOS version (even if revoked).
- Disables online TSS checks for older OS boots.
- Enables checkboxes for:
Allow user management of kernel extensions from identified developersAllow remote management of kernel extensions and automatic software updates
- Permissive Security (Advanced/Hidden):
- Used by developers for 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 ולא בקרנל.
- קורסות? המחשב ממשיך לעבוד.
- (אנלוגיה היסטורית למדריך: אפשר להשוות את זה למצב שלפני Mac OS X, בו לא היה קרנל מוגן וקריסה קטנה הייתה מקפיאה את כל המחשב. המעבר ל-System Extensions הוא אותו מהלך של 'בידוד תהליכים' (Sandboxing) שעשו פעם לאפליקציות, רק שעכשיו עושים אותו לדרייברים עצמם כדי למנוע Kernel Panics).
- למה עדיין צריכים Kexts?
- יצרני אודיו או וירטואליזציה ישנים שטרם עודכנו.
- איך מתקינים Kext במק מודרני? הכאב ראש המכוון של אפל:
- ירידה ל-Reduced Security.
- סימון ניהול הרחבות קרנל ב-Startup Security Utility.
- אישור מפתח היצרן ב-System Settings > Privacy & Security.
- אתחול המערכת (כדי ש-iBoot יבנה את ה-AKC מחדש).
הדגמה מעשית (Demonstration):
- פתח System Information -> Software -> Extensions:
- הצג הרחבות שנטענו בפועל (
Loaded: Yes). - פתח Finder:
- נווט לספרייה
/Library/Extensions. - הראה היכן קבצי ה-Kext (צד שלישי) יושבים פיזית.
- סימולציה של חסימה:
- הראה את החלון ב-
System Settings > Privacy & Security(System Extension Blocked). - הסבר שנדרש אישור ואתחול.
Instructor Deep-Dive
- Kernel Extensions (Kexts):
- Run in ring 0 (kernel space).
- Unrestricted access to memory and hardware.
- Easy cause for Kernel Panics (KP).
- System Extensions:
- Run in user space.
- Categories: Network Extensions, Endpoint Security Extensions, Driver Extensions (DriverKit).
- Auxiliary Kernel Collection (AKC):
- On Apple Silicon, third-party Kexts are NOT injected directly into memory.
- They are pre-compiled and linked into an AKC file during boot.
- OS verifies AKC signature before loading.
- kmutil:
- Modern CLI tool replacing
kextstatandkextutil. - Instructor tip: Run
kmutil showloadedin Terminal to show active extensions.
4. תיבול ארגוני: אבטחת ה-Firmware, ניהול מפתחות שחזור מוסדיים במצב Boot, והגבלת משתמשים מלשנות רמת אבטחה¶
מטרת השיעור (Objective): להבין את הכלים שיש ל-IT כדי לנעול את תהליך האתחול, למנוע שינויי אבטחה ולנהל גישה ל-Recovery באמצעות מפתחות שחזור.
תסריט שיחה (Discussion - Script):
- "בעולם הארגוני – המטרה שלנו היא למנוע מ-Admin מקומי לשחק ברמות האבטחה ולהתקין דרייברים."
- תפקיד ה-MDM:
- מחשב מנוהל (במיוחד ב-ADE/Zero-Touch) יכול להפעיל מפתח שחזור מוסדי (IRK/PRK).
- יחד עם FileVault, המשתמש לא יכול לשנות הגדרות ב-Recovery ללא המפתח.
- איש ה-IT חייב לאשר זאת.
- הגבלת אישור Kexts:
- פרופילי MDM יכולים לדרוס לחלוטין את יכולת המשתמש לאשר Kexts.
- נדרש Payload ייעודי ב-MDM עם ה-Team ID המדויק.
- מבטיח שאף תוכנה לא מאושרת ללא בקרת הארגון.
הדגמה מעשית (Demonstration):
- הצג תרשים/Payload מתוך מערכת MDM (Jamf/Intune):
- פוליסת Kernel Extension Policy.
- הראה איפה מזינים את ה-Team ID.
- פרופיל System Extensions:
- הסבר שהוא מתנהג דומה.
- מאפשר הפעלה שקטה בלי לערב משתמש.
- אבטחת Firmware ב-Apple Silicon:
- אין יותר Firmware Password (כמו באינטל).
- במקומה: משתמשים ב-FileVault וב-MDM Bootstrap Token לאבטחת הגישה ל-Recovery.
Instructor Deep-Dive
- Firmware Password:
- Dead on Apple Silicon.
- Protected by FileVault instead.
- סביבת השחזור (Recovery) requires volume owner password or Recovery Key (PRK/IRK) if FileVault is ON.
- MDM Limitations on Security Level:
- MDM can force Full Security boot.
- Overrides local Admin policy changes in Recovery.
- Kext Policy Payload:
- Silently approves Kexts using developer's Team ID.
- Changing to Reduced Security STILL requires manual user reboot into Recovery (unless pre-provisioned via ADE and downgraded remotely using Bootstrap Token).
- CLI Validation:
- Verify SIP status:
csrutil status. - Verify Kext consent status:
spctl kext-consent status.