На Хабре не так багато статей, присвячених операційній системі Qubes, а ті, що я бачив мало описують досвід застосування. Під катом сподіваюся це виправити на прикладі використання Qubes як засіб захисту (від) середовища Windows і, принагідно, оцінити кількість російськомовних користувачів системи.
Чому Qubes?
Історія з закінченням техпідтримки Windows 7 і тривожність користувачів, що підвищується, призвела до необхідності організувати роботу цієї ОС, враховуючи наступні вимоги:
- забезпечити застосування повноцінної активованої Windows 7 з можливістю встановлення користувачем оновлень та різних програм (у тому числі через Інтернет);
- реалізувати повне або вибіркове виключення мережевих взаємодій за умовою (режими автономної роботи та фільтрації трафіку);
- надати можливість вибіркового підключення знімних носіїв та пристроїв.
Такий набір обмежень передбачає явно підготовленого користувача, оскільки дозволяється самостійне адміністрування, та обмеження пов'язані не з блокуванням його потенційних дій, а з виключенням можливих помилок чи програмного деструктивного впливу. Тобто. внутрішнього порушника у моделі немає.
У пошуку рішення ми швидко відмовилися від ідеї реалізовувати обмеження вбудованим або додатковим засобом Windows, оскільки досить складно ефективно обмежити користувача з повноваженнями адміністратора, залишаючи йому можливість встановлювати програми.
Наступним варіантом рішення була ізоляція за допомогою віртуалізації. Широковідомі інструменти для настільної віртуалізації (наприклад, такі як virtualbox) погано пристосовані для вирішення задач безпеки і перелічені обмеження доведеться робити користувачеві постійно перемикаючи або налаштовуючи властивості гостьової віртуальної машини (далі ВМ), що підвищує ризики помилок.
У той же час у нас був досвід застосування Qubes як настільна система користувача, але були сумніви в стабільності роботи з гостьовою Windows. Вирішили перевірити актуальну версію Qubes, оскільки поставлені обмеження дуже добре вкладаються в парадигму цієї системи, особливо реалізація шаблонів віртуальних машин і візуальна інтеграція. Далі спробую по можливості коротко розповісти про ідеї та інструментарії Qubes, на прикладі вирішення поставленого завдання.
Типи віртуалізації Xen
В основі Qubes лежить гіпервізор Xen, який мінімізує в собі функції управління ресурсами процесора, пам'яттю та віртуальними машинами. Решта роботи з пристроями зосереджена в dom0 на основі ядра Linux (у Qubes для dom0 використовується дистрибутив Fedora).
Xen підтримує кілька типів віртуалізації (я наводитиму приклади для Intel архітектури, хоча Xen підтримує й інші):
- паравіртуалізація (PV) - режим віртуалізації без використання апаратної підтримки, нагадує контейнерну віртуалізацію, може використовуватися для систем з адаптованим ядром (у такому режимі функціонує dom0);
- повна віртуалізація (HVM) - в такому режимі для ресурсів процесора використовується апаратна підтримка, а все інше обладнання емулюється засобами QEMU. Це найуніверсальніший спосіб запуску різних ОС;
- паравіртуалізація обладнання (PVH - ParaVirtualized Hardware) - режим віртуалізації з використанням апаратної підтримки коли для роботи з обладнанням ядро гостьової системи використовує драйвери, адаптовані до можливостей гіпервізора (наприклад, пам'яті, що розділяється), знімаючи необхідність в емуляції QEMU і підвищуючи продуктивність введення-ви. Ядро Linux, починаючи з 4.11, може працювати в такому режимі.
Починаючи з версії Qubes 4.0 з міркувань безпеки, йде відмова від використання режиму паравіртуалізації (у тому числі у зв'язку з відомими вразливістю архітектури Intel, які частково знімаються використанням повноцінної віртуалізації), за умовчанням використовується режим PVH.
При використанні емуляції (режим HVM) запуск QEMU здійснюється в ізольованій ВМ, яка називається stubdomain, тим самим знижуючи ризики експлуатації потенційних помилок у реалізації (проект QEMU містить багато коду, у тому числі для сумісності).
Такий режим слід використовувати в нашому випадку для Windows.
Службові віртуальні машини
В архітектурі безпеки Qubes однією з ключових можливостей гіпервізора є передача PCI пристроїв у гостьове оточення. Виключення обладнання дозволяє ізолювати хостову частину системи від зовнішніх атак. Xen підтримує це для PV і HVM режимів, у другому випадку для цього потрібна підтримка IOMMU (Intel VT-d) - апаратного управління пам'яттю для пристроїв, що віртуалізуються.
Таким чином, створюються кілька системних віртуальних машин:
- sys-net, якій передаються мережеві пристрої та яка використовується як мост для інших ВМ, наприклад, що реалізують функції міжмережевого екрану або клієнта мережі VPN;
- sys-usb, якою передаються USB та інші контролери периферійних пристроїв;
- sys-firewall, яка не використовує пристрою, а працює як міжмережевий екран для ВМ, що підключаються.
Для роботи з пристроями USB використовуються проксі-сервіси, які забезпечують у тому числі:
- для класу пристроїв HID (human interface device) передачу команд dom0;
- для знімних носіїв перенаправлення томів пристроїв до інших ВМ (за винятком dom0);
- перенаправлення безпосередньо USB пристрою (використовується USBIP та засоби інтеграції).
У такій конфігурації успішна атака через мережевий стек або пристрої, що підключаються, може призводити до компрометації тільки запущеної службової ВМ, а не всієї системи в цілому. А після перезапуску службової ВМ її буде завантажено у вихідному стані.
Інструменти інтеграції ВМ
Є кілька способів взаємодії з робочим столом віртуальної машини – встановлення додатків у гостьову систему або емуляція відео засобами віртуалізації. Як гостьові програми можуть виступати різні універсальні засоби віддаленого доступу (RDP, VNC, Spice і т.п.) або адаптовані до конкретного гіпервізора (такий інструментацій зазвичай називають гостьовими утилітами). Може застосовуватися і змішаний варіант, коли гіпервізор емулює введення-виведення для гостьової системи, а зовні надає можливість використовувати протокол, що комбінує введення-виведення, наприклад, як у Spice. При цьому кошти віддаленого доступу зазвичай оптимізують зображення, оскільки припускають роботу через мережу, що не на краще впливає на якість картинки.
Qubes надає власні кошти на інтеграцію ВМ. Насамперед це графічна підсистема - вікна з різних ВМ відображаються на єдиному робочому столі з власним колірним обрамленням. В цілому засоби інтеграції засновані на можливостях гіпервізора - пам'яті (Xen grant table), що засобу сповіщення (Xen event channel), що розділяється сховище xenstore і протоколі комунікації vchan. З їх допомогою реалізуються базові компоненти qrexec і qubes-rpc, і прикладні сервіси - перенаправлення звуку або USB, передача файлів або буфера обміну, виконання команд і запуск додатків. Існує можливість встановлювати політики, що дозволяє обмежити доступні на ВМ послуги. На малюнку нижче приклад процедури ініціалізації взаємодії двох ВМ.
Таким чином робота у ВМ проводиться без використання мережі, що дозволяє повноцінно використовувати автономні ВМ для уникнення витоку інформації. Наприклад, так реалізується поділ криптографічних операцій (PGP/SSH), коли закриті ключі використовуються в ізольованих ВМ і не виходять за межі.
Шаблони, прикладні та одноразові ВМ
Вся робота користувача в Qubes виконується у віртуальних машинах. Основна хостова система використовується для управління їх роботою та візуалізації. ОС встановлюється разом із базовим набором віртуальних машин з урахуванням шаблонів (TemplateVM). Такий шаблон є Linux ВМ на основі дистрибутива Fedora або Debian, із встановленими та налаштованими засобами інтеграції, виділеними системними та користувальницькими розділами. Встановлення та оновлення програмного забезпечення здійснюється штатним менеджером пакетів (dnf або apt) з налаштованих репозиторіїв з обов'язковою перевіркою цифрового підпису (GnuPG). Призначення таких ВМ - це забезпечення довіри до прикладних ВМ, що запускаються на їх основі.
Прикладна ВМ (AppVM) під час старту використовує знімок системного розділу відповідного шаблону ВМ, а після завершення видаляє цей знімок без збереження змін. Необхідні користувачеві дані зберігаються в унікальному для кожної прикладної ВМ розділі користувача, який монтується в домашній каталог.
Корисним з погляду безпеки може бути використання одноразових ВМ (disposibleVM). Така ВМ створюється на основі шаблону в момент старту і запускається з однією метою виконання однієї програми, завершуючи роботу після його закриття. Одноразові ВМ можуть використовуватись для відкриття підозрілих файлів, вміст яких може призводити до експлуатації вразливостей конкретних програм. Можливість запуску одноразової ВМ інтегрована у файловий менеджер (Nautilus) та поштовий клієнт (Thunderbird).
Windows ВМ також може бути використана для створення шаблону та одноразового ВМ, для цього профіль користувача переноситься в окремий розділ. У нашому варіанті такий шаблон використовуватиметься користувачем для завдань адміністрування та встановлення програм. На основі шаблону буде створено кілька прикладних ВМ - з обмеженим доступом до мережі (штатні можливості sys-firewall) і без доступу до мережі взагалі (не створюється віртуальний мережний пристрій). Для роботи в цих ВМ будуть доступні всі зміни та програми, що встановлюються в шаблоні і навіть у разі впровадження програм-закладок, їм буде недоступний доступ до мережі для компрометації.
Боротьба за Windows
Описані вище можливості є основою Qubes та працюють цілком стабільно, складнощі починаються з Windows. Для інтеграції Windows необхідно використовувати набір гостьових інструментів Qubes Windows Tools (QWT), що включає драйвери для роботи з Xen, драйвер qvideo і набір утиліт для інформаційного обміну (файловий прийом-передача, буфер обміну). Процес встановлення та налаштування детально документований на сайті проекту, тому поділимося нашим досвідом застосування.
Основну складність становить насправді відсутність підтримки розробленого інструментарію. Ключові розробники (QWT), мабуть, недоступні і проект інтеграції з Windows перебуває в очікуванні провідного розробника. Тому в першу чергу необхідно було оцінити працездатність і скласти розуміння можливості його підтримки при необхідності самостійно. Найбільш складним для розробки та налагодження є графічний драйвер, який емулює відеоадаптер і дисплей для формування зображення в пам'яті, що розділяється, дозволяючи відображати весь робочий стіл або безпосередньо вікно програми у вікні хостової системи. У ході аналізу роботи драйвера ми адаптували код для складання в оточенні Linux і відпрацювали схему налагодження між двома гостьовими системами Windows. На етапі кросбілда провели кілька спрощують для нас змін в основному в частині "тихої" установки утиліт, а також усунули настирливу деградацію продуктивності при тривалій роботі у ВМ. Результати роботи ми оформили окремо тим самим ненадовго провідного розробника Qubes.
Найбільш критичним етапом щодо стабільності гостьової системи є запуск Windows, тут можна побачити знайомий синій екран (або навіть не побачити). Більшість виявлених помилок знаходилися різні варіанти обходу — відмова від Xen драйверів блокових пристроїв, виключення балансування пам'яті ВМ, фіксація мережевих налаштувань і мінімізація кількості ядер. Наше складання гостьових коштів встановлюється і працює на повністю оновленій Windows 7 та Windows 10 (за винятком qvideo).
При переході з реального середовища до віртуального виникає проблема з активацією Windows у разі використання встановлених OEM версій. Такі системи використовують активацію на основі ліцензій, прописаних у пристрої UEFI. Для коректного відпрацювання активації необхідно транслювати в гостьову систему один із розділів ACPI хостової системи повністю (SLIC table) і трохи правити інші, прописуючи виробника. Xen дозволяє настроювати вміст ACPI додаткових таблиць, але без модифікації основних. З рішенням допоміг патч від схожого проекту OpenXT, адаптованого для Qubes. Виправлення здалися корисними не тільки нам і були трансльовані в основний репозиторій Qubes та бібліотеку Libvirt.
Очевидними недоліками засобів інтеграції Windows слід назвати відсутність підтримки звуку, USB-пристроїв та складність роботи з медіа, оскільки немає апаратної підтримки GPU. Але це не заважає використанню ВМ для роботи з офісними документами, не перешкоджає запуску специфічних корпоративних додатків.
Вимога переключення в режим роботи без мережі або з обмеженою мережею після створення шаблону Windows ВМ виконувалося створенням відповідних конфігурацій прикладних ВМ, а можливість вибіркового підключення знімних носіїв також вирішувалася штатними засобами ОС - при підключенні вони доступні в системній ВМ sys-usb, звідки можуть бути " прокинуті" до необхідної ВМ. Робочий стіл користувача виглядає приблизно так.
Підсумковий варіант системи позитивно (наскільки дозволяє таке комплексне рішення) прийнято користувачами, а штатні засоби системи дозволили розширити застосування до мобільного робочого місця користувача з доступом через VPN.
Замість висновку
Віртуалізація в цілому дозволяє знижувати ризики використання Windows систем, залишених без підтримки - не примушує до сумісності з новими апаратними засобами, дозволяє виключати або контролювати доступ до системи через мережу або за допомогою пристроїв, що підключаються, дозволяє реалізувати середовище для одноразового запуску.
ОС Qubes, що базується на ідеї ізоляції через віртуалізацію, допомагає використовувати ці та інші механізми для забезпечення безпеки. З боку багато хто бачать у Qubes насамперед прагнення до анонімності, але це корисна система як для інженерів, які часто поєднують проекти, інфраструктури та секрети доступу до них, так і для дослідників безпеки. Поділ додатків, даних та формалізація їхньої взаємодії це початкові кроки аналізу загроз та проектування системи захисту. Такий поділ допомагає структурувати інформацію та знизити ймовірність помилки через людський чинник — поспіху, втому тощо.
В даний час основний наголос у розробці йде на розширення функціональності середовищ Linux. Готується до релізу версія 4.1, яка буде заснована на Fedora 31 і включатиме актуальні версії ключових компонентів Xen і Libvirt. Варто зазначити, що Qubes створюється професіоналами в галузі інформаційної безпеки, які завжди оперативно випускають оновлення у разі виявлення нових загроз чи помилок.
Післямова
Одна з експериментальних можливостей, що ми розвиваємо, дозволяє створювати ВМ з підтримкою гостьового доступу до GPU на основі технології Intel GVT-g, що дозволяє використовувати можливості графічного адаптера і значно розширити область застосування системи. На момент написання статті цей функціонал працює для тестових складання Qubes 4.1, і доступний на .
Джерело: habr.com