שימוש ב-QubesOS לעבודה עם Windows 7

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

למה קובס?

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

• להבטיח את השימוש ב-Windows 7 המופעל במלואו עם יכולת למשתמש להתקין עדכונים ויישומים שונים (כולל דרך האינטרנט);
• ליישם אי הכללה מלאה או סלקטיבית של אינטראקציות רשת המבוססות על תנאים (פעולה אוטונומית ומצבי סינון תעבורה);
• לספק את היכולת לחבר באופן סלקטיבי מדיה נשלפת והתקנים.

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

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

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

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

סוגי וירטואליזציה של Xen

Qubes מבוסס על ה-Xen hypervisor, אשר ממזער את הפונקציות של ניהול משאבי מעבד, זיכרון ומכונות וירטואליות. כל שאר העבודה עם מכשירים מרוכזת ב-dom0 המבוססת על ליבת לינוקס (Qubes עבור dom0 משתמש בהפצה של Fedora).

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

• paravirtualization (PV) - מצב וירטואליזציה ללא שימוש בתמיכת חומרה, המזכיר וירטואליזציה של קונטיינר, יכול לשמש למערכות עם ליבה מותאמת (dom0 פועל במצב זה);
• וירטואליזציה מלאה (HVM) - במצב זה, תמיכת חומרה משמשת למשאבי מעבד, וכל שאר הציוד מחוקה באמצעות QEMU. זוהי הדרך האוניברסלית ביותר להפעיל מערכות הפעלה שונות;
• פאראווירטואליזציה של חומרה (PVH - ParaVirtualized Hardware) - מצב וירטואליזציה המשתמש בתמיכת חומרה כאשר, כדי לעבוד עם חומרה, ליבת המערכת האורחת משתמשת בדרייברים המותאמים ליכולות ה-Hypervisor (לדוגמה, זיכרון משותף), ומבטלת את הצורך באמולציית QEMU והגברת ביצועי I/O. ליבת לינוקס החל מ-4.11 יכולה לעבוד במצב זה.

החל מ-Qubes 4.0, מטעמי אבטחה, השימוש במצב פאראווירטואליזציה נזנח (כולל עקב פגיעויות ידועות בארכיטקטורת אינטל, אשר מופחתות חלקית על ידי שימוש בווירטואליזציה מלאה); מצב PVH משמש כברירת מחדל.

בעת שימוש באמולציה (מצב HVM), QEMU מושק ב-VM מבודד הנקרא stubdomain, ובכך מפחית את הסיכונים של ניצול שגיאות פוטנציאליות ביישום (פרויקט QEMU מכיל הרבה קוד, כולל עבור תאימות).
במקרה שלנו, יש להשתמש במצב זה עבור Windows.

שירות מכונות וירטואליות

בארכיטקטורת האבטחה של Qubes, אחת מיכולות המפתח של ה-Hypervisor היא העברת התקני PCI לסביבת האורחים. אי הכללת חומרה מאפשרת לך לבודד את החלק המארח של המערכת מפני התקפות חיצוניות. Xen תומך בכך עבור מצבי PV ו-HVM, במקרה השני הוא דורש תמיכה ב-IOMMU (Intel VT-d) - ניהול זיכרון חומרה עבור מכשירים וירטואליים.

זה יוצר מספר מכונות וירטואליות למערכת:

• sys-net, שאליו מועברים התקני רשת ואשר משמשת כגשר ל-VMs אחרים, למשל, כאלו המיישמים את הפונקציות של חומת אש או לקוח VPN;
• sys-usb, שאליו מועברים בקרי USB ובקרי התקנים היקפיים אחרים;
• sys-firewall, שאינה משתמשת במכשירים, אך פועלת כחומת אש עבור מחשבי VM מחוברים.

כדי לעבוד עם התקני USB, נעשה שימוש בשירותי פרוקסי, המספקים, בין היתר:

• עבור מחלקת התקן HID (התקן ממשק אנושי), שליחת פקודות ל-dom0;
• עבור מדיה נשלפת, ניתוב מחדש של אמצעי אחסון במכשיר למכשירי VM אחרים (למעט dom0);
• הפנייה ישירות להתקן USB (באמצעות USBIP וכלי אינטגרציה).

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

כלי אינטגרציה של VM

ישנן מספר דרכים ליצור אינטראקציה עם שולחן העבודה של מכונה וירטואלית - התקנת אפליקציות במערכת האורחת או הדמיית וידאו באמצעות כלי וירטואליזציה. יישומי אורח יכולים להיות כלי גישה מרחוק אוניברסליים שונים (RDP, VNC, Spice וכו') או מותאמים להיפרוויזר ספציפי (כלים כאלה נקראים בדרך כלל כלי עזר אורחים). ניתן להשתמש גם באפשרות מעורבת, כאשר ה-Hypervisor מחקה I/O עבור מערכת האורח, ומספק חיצונית את היכולת להשתמש בפרוטוקול המשלב I/O, למשל, כמו Spice. יחד עם זאת, כלי גישה מרחוק מבצעים לרוב אופטימיזציה של התמונה, שכן מדובר בעבודה דרך רשת, מה שלא משפיע לטובה על איכות התמונה.

Qubes מספקת כלים משלה לשילוב VM. קודם כל, זו תת-מערכת גרפית - חלונות מ-VMs שונים מוצגים על שולחן עבודה יחיד עם מסגרת צבע משלהם. ככלל, כלי האינטגרציה מבוססים על היכולות של ה-Hypervisor - זיכרון משותף (טבלת מענק Xen), כלי הודעות (ערוץ אירוע Xen), אחסון משותף xenstore ופרוטוקול התקשורת vchan. בעזרתם מיושמים הרכיבים הבסיסיים qrexec ו-qubes-rpc, ושירותי יישומים - הפניית אודיו או USB, העברת קבצים או תוכן לוח, ביצוע פקודות והפעלת יישומים. אפשר להגדיר מדיניות המאפשרת לך להגביל את השירותים הזמינים ב-VM. האיור שלהלן הוא דוגמה להליך לאתחול האינטראקציה של שני VMs.

כך, העבודה ב-VM מתבצעת ללא שימוש ברשת, מה שמאפשר שימוש מלא ב-VMs אוטונומיים כדי למנוע דליפת מידע. כך למשל מיושמת הפרדת פעולות קריפטוגרפיות (PGP/SSH), כאשר משתמשים במפתחות פרטיים ב-VM מבודדים ואינם חורגים מהם.

תבניות, אפליקציות ו-VM חד פעמי

כל עבודת המשתמש ב-Qubes נעשית במכונות וירטואליות. המערכת המארחת הראשית משמשת כדי לשלוט בהם ולהמחיש אותם. מערכת ההפעלה מותקנת יחד עם סט בסיסי של מכונות וירטואליות מבוססות תבניות (TemplateVM). תבנית זו היא VM Linux המבוסס על הפצת פדורה או דביאן, עם כלי אינטגרציה מותקנים ומוגדרים, ומחיצות מערכת ומשתמש ייעודיות. התקנה ועדכון של תוכנה מבוצעים על ידי מנהל חבילות רגיל (dnf או apt) ממאגרים מוגדרים עם אימות חתימה דיגיטלית חובה (GnuPG). המטרה של VMs כאלה היא להבטיח אמון ב-VMs של יישומים שהושקו על בסיסם.

בעת ההפעלה, יישום VM (AppVM) משתמש בתמונת מצב של מחיצת המערכת של תבנית ה-VM המתאימה, ועם השלמתו מוחק תמונת מצב זו מבלי לשמור שינויים. הנתונים הנדרשים על ידי המשתמש מאוחסנים במחיצת משתמש ייחודית לכל יישום VM, אשר מותקן בספריית הבית.

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

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

להילחם על ווינדוס

התכונות שתוארו לעיל הן הבסיס של Qubes ועובדות בצורה די יציבה; הקשיים מתחילים עם Windows. כדי לשלב את Windows, עליך להשתמש בערכת כלי אורח Qubes Windows Tools (QWT), הכוללת מנהלי התקנים לעבודה עם Xen, מנהל התקן qvideo וערכת כלי עזר להחלפת מידע (העברת קבצים, לוח). תהליך ההתקנה וההגדרה מתועד בפירוט באתר הפרויקט, כך שנחלוק את חווית היישום שלנו.

הקושי העיקרי הוא בעצם חוסר התמיכה בכלים שפותחו. נראה כי מפתחי מפתח (QWT) אינם זמינים ופרויקט האינטגרציה של Windows ממתין למפתח מוביל. לכן, קודם כל, היה צורך להעריך את ביצועיו ולגבש הבנה של האפשרות לתמוך בו באופן עצמאי, במידת הצורך. הקשה ביותר לפיתוח וניפוי באגים הוא מנהל ההתקן הגרפי, המחקה את מתאם הווידאו והתצוגה כדי ליצור תמונה בזיכרון משותף, המאפשר לך להציג את כל שולחן העבודה או את חלון היישום ישירות בחלון המערכת המארחת. במהלך ניתוח פעולת הדרייבר התאמנו את הקוד להרכבה בסביבת לינוקס ופיתחנו סכמת איתור באגים בין שתי מערכות אורחות של Windows. בשלב ה-Crossbuild, ביצענו מספר שינויים שפשטו לנו את הדברים, בעיקר במונחים של התקנה "שקטה" של כלי עזר, וגם ביטלו את הפגיעה המעצבנת בביצועים בעבודה ב-VM במשך זמן רב. הצגנו את תוצאות העבודה בנפרד מאגרים, ולכן לא לאורך זמן מעורר השראה מפתח Qubes מוביל.

השלב הקריטי ביותר מבחינת יציבות מערכת האורח הוא ההפעלה של Windows, כאן תוכלו לראות את המסך הכחול המוכר (או אפילו לא לראות אותו). עבור רוב השגיאות שזוהו, היו דרכים שונות לעקיפת הבעיה - ביטול מנהלי התקנים של חסימת Xen, השבתת איזון זיכרון VM, תיקון הגדרות רשת וצמצום מספר הליבות. כלי האורח שלנו מתקינים ומופעלים על Windows 7 ו-Windows 10 המעודכנים במלואם (למעט qvideo).

בעת מעבר מסביבה אמיתית לסביבה וירטואלית, מתעוררת בעיה בהפעלת Windows אם נעשה שימוש בגרסאות OEM מותקנות מראש. מערכות כאלה משתמשות בהפעלה על סמך רישיונות המצוינים ב-UEFI של המכשיר. כדי לעבד נכון את ההפעלה, יש צורך לתרגם את אחד מקטעי ה-ACPI שלמים של המערכת המארחת (טבלת SLIC) למערכת האורחת ולערוך מעט את האחרים, תוך רישום היצרן. Xen מאפשר לך להתאים אישית את תוכן ה-ACPI של טבלאות נוספות, אך מבלי לשנות את העיקריות שבהן. תיקון מפרויקט OpenXT דומה, שהותאם ל-Qubes, עזר בפתרון. התיקונים נראו שימושיים לא רק לנו ותורגמו למאגר Qubes הראשי ולספריית Libvirt.

החסרונות הברורים של כלי האינטגרציה של Windows כוללים את היעדר תמיכה באודיו, התקני USB ומורכבות העבודה עם מדיה, מכיוון שאין תמיכת חומרה ב-GPU. אך האמור לעיל אינו מונע את השימוש ב-VM לעבודה עם מסמכי אופיס, וגם אינו מונע השקה של יישומים ארגוניים ספציפיים.

הדרישה לעבור למצב הפעלה ללא רשת או עם רשת מוגבלת לאחר יצירת תבנית Windows VM התמלאה על ידי יצירת התצורות המתאימות של VMs יישומים, והאפשרות של חיבור סלקטיבי של מדיה נשלפת נפתרה גם על ידי כלי מערכת הפעלה סטנדרטיים - כאשר הם מחוברים , הם זמינים במערכת VM sys-usb, משם ניתן "להעביר" אותם ל-VM הנדרש. שולחן העבודה של המשתמש נראה בערך כך.

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

במקום מסקנה

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

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

נכון לעכשיו, הדגש העיקרי בפיתוח הוא על הרחבת הפונקציונליות של סביבות לינוקס. גרסה 4.1 מתכוננת לשחרור, שתתבסס על Fedora 31 ותכלול גרסאות עדכניות של רכיבי המפתח Xen ו-Libvirt. ראוי לציין ש-Qubes נוצר על ידי מקצועני אבטחת מידע שתמיד משחררים עדכונים מיידית אם מזוהים איומים או שגיאות חדשים.

אחרית דבר

אחת היכולות הניסיוניות שאנו מפתחים מאפשרת לנו ליצור VMs עם תמיכה בגישה לאורחים ל-GPU המבוססת על טכנולוגיית Intel GVT-g, המאפשרת לנו להשתמש ביכולות של המתאם הגרפי ולהרחיב משמעותית את היקף המערכת. בזמן כתיבת שורות אלה, פונקציונליות זו פועלת עבור בניית מבחן של Qubes 4.1, וזמינה ב- GitHub.

מקור: www.habr.com