למה תקלת CrowdStrike לא יכולה להתרחש בmacOS, ולמה מייקרוסופט לא יכולה לנקוט בצעדי התגוננות דומים
-
@A-I-V כתב בלמה תקלת CrowdStrike לא יכולה להתרחש בmacOS, ולמה מייקרוסופט לא יכולה לנקוט בצעדי התגוננות דומים:
ב. אם זה פוגע בתחרות, איך הEU נותן לאפל לעשות את זה?
אם הבנתי נכון הבעיה היא רק כי יש למייקרוסופט אנטי וירוס משלהם
הם התחייבו שהאנטי וירוס שלהם לא יקבל יותר גישה למערכת מאנטי וירוסים של צד שלישי
לכאורה תיאורטית הם יכולים לבנות ממשק API עבור מוצרי אבטחה שירוץ ב-userspace ויעבירו את האנטי וירוס שלהם גם כן לשם
צריך עיון אם ה-xprotect המובנה של אפל מקבל יותר גישה ממוצרי אבטחה אחרים. אבל אולי זה פחות בעיה כי xprotect הוא לא אנטי וירוס שלם וזה לא ממש מתחרה במוצרי אבטחה אחרים -
למעשה יש בהגנה על קבצי המערכת שני חלקים, שנוספו בהדרגה:
- SIP (System Integrity Protection), מגן בזמן ריצה משינויים של הקבצי מערכת (וגם מעוד דברים כמו הזרקת קוד לתהליך)
- מעל זה יש את SSV (Signed System Volume) שמאחסן חתימה קריפטוגרפית של כל קבצי המערכת וחוסם אתחול אם אין התאמה, בשילוב השבב אבטחה T2 שאוכף את זה (באינטל, במעבדי אפל סיליקון זה כבר משולב)
מראי מקומות:
https://gist.github.com/macshome/15f995a4e849acd75caf14f2e50e7e98
https://eclecticlight.co/2020/06/25/big-surs-signed-system-volume-added-security-protection/
https://eclecticlight.co/2024/03/15/apple-silicon-6-security/ -
נראה לי שיש עוד סיבה שקשה יותר ל-MS לאסור קוד צד שלישי בקרנל. כי הם חייבים לתמוך בחומרה מחברות שונות. הם לא שולטים על החומרה. וכדי לקבל ביצועים טובים, הדרייברים של ההתקנים חייב לרוץ במרחב הקרנל.
משא"כ אפל ששולטים לגמרי על החומרה ומאפשרים חיבור התקנים של צד שלישי רק דרך ממשקים מוגדרים כמו USB וכדו', הם יכולים לשלוט לגמרי על כל הקוד במרחב הקרנל.
מכיון שבכל מקרה MS לא יכולים להוציא לגמרי קוד של צד שלישי מהקרנל, יכול להיות שיש להם פחות מוטיבציה להוציא מוצרי אבטחה מהקרנל. -
גם אצל אפל זה לא לחלוטין, במקרים מיוחדים שאין להם פתרון הם כן יאפשרו kernal extention (עם תהליך התקנה מסורבל שעובר דרך הביוס)
אבל יש פריימוורק לדרייברים בuser space (DriverKit), ויש פריימוורק למוצרי אבטחה (Endpoint Security), ויש פריימוורק לסינוני תעבורה ואפליקציות VPN (Network Extention)
https://developer.apple.com/documentation/kernel/implementing_drivers_system_extensions_and_kexts
https://developer.apple.com/documentation/apple-silicon/installing-a-custom-kernel-extension -
https://github.com/microsoft/ebpf-for-windows
זו דרך להריץ קוד בטוח בקרנל
הקוד שכותבים עם טכנולוגיה זו, אפשר להוכיח מתמטית שהוא לא יכול לגרום חריגה או לשבש זכרון וכו' -
-
-
-
@חגי זה מסוכן מדי. לך תדע איפה יש שיבוש בזכרון. לדרייבר יש גישה לכל מרחב הזכרון של הקרנל. אין מספיק בידוד בין הדרייבר לשאר הקרנל. אם המערכת ממשיכה לרוץ אולי קבצים ישובשו. או היזק קבע אחר.
(זה מושכל ראשון שלי. אולי למומחים בפיתוח קרנל יש תשובה יותר טובה מזה) -
אגב, יש לנושא הזה היסטוריה ארוכה. היה פולמוס גדול כבר בשנות ה-1980 אם צריך ללכת על ארכיטקטורה של microkernel (קרנל מינימליסטי מאוד, כאשר כל שאר שירותי המערכת - כולל דרייברים - רצים בתהליכים מבודדים) בגלל הבטיחות והיציבות שזה נותן
אני רואה עכשיו שהקרנל של מאק וגם של ווינדוס מוגדרים כקרנל היברידי. משהו בין מיקרו למונולית'
