Ні для кого не секрет, що по-справжньому захищених операційних систем не існує. Які б заходи щодо підвищення безпеки не робили розробники ОС, завжди залишається ймовірність того, що в їх коді буде знайдена помилка, яка дозволить обійти механізми захисту. Однак прогрес не зупиняється, і на противагу більш витонченим атакам з'являються більш досконалі методи захисту. Qubes OS - приклад того, як можуть виглядати ці методи в сучасному світі.
Навіщо винаходити велосипед?

Щоб зрозуміти, чому з'явилася на світ Qubes OS, і що вона може дати в плані безпеки, ми повинні заглибитися в історію питання і з'ясувати, чим же погані сучасні операційні системи.

Існує три найбільш ефективних методи забезпечення безпеки на рівні ОС:

    * Формальне доказ правильності і безпеки коду;
    * Швидке і своєчасне вирішення виявлених проблем безпеки;
    * Ізоляція виконуваного коду (на рівні процесів і ядра).

Перший метод має на увазі повну перевірку всього коду операційної системи (включаючи ядро і користувальницьке ПЗ) та математичне доказ того, що результат виконання програми за будь-яких умовах буде повністю відповідати очікуваному, а під час її виконання не відбудеться непередбачених ситуацій. Це - "святий грааль" для сучасних дослідників операційних систем (а також спецслужб усього світу). Проте, якщо брати в розрахунок неймовірну складність сьогоднішніх ОС і кількість обладнання, на якому вони можуть функціонувати (необхідно довести правильність роботи ПЗ на будь-якій апаратній конфігурації), можна сказати, що на ділі формальний доказ безпеки всього коду ОС неможливо. За весь час це вдалося зробити лише в плані дуже скромних за розміром мікроядер дослідних ОС.

Деякі розробники віддають перевагу більш просту перевірку, покладаючись на свій досвід і не дуже складні інструменти (Flawfinder, RATS, Skavenger, lint і т.д.). Наприклад, розробники OpenBSD домоглися високої безпеки ядра своєї ОС багато в чому завдяки тому, що піддають сумніву і ретельній перевірці будь-патч, пропонований до включення в ОС. Розробники Coverity використовують у своїй системі (Coverity Prevent) досить прості, але не дуже ефективні методи визначення помилок в коді. Треті використовують другий метод забезпечення безпеки і замість ретельної перевірки коду (яка вимагає значних витрат часу і коштів) вважають за краще вчасно і швидко випускати оновлення, вирішальні знайдені проблеми в стабільності і безпеки. Сьогодні ця практика поширена повсюдно і застосовується всіма, починаючи Microsoft і закінчуючи розробниками BSD-систем. Однак проблема методу в його запізнення. Найчастіше першими про баге дізнаються не розробники ОС, а особи, наближені до імпер ... людині, яка знайшла уразливість. Тому ще до виходу багфикс поламаними виявляються сотні і тисячі машин.

Щоб зменшити шкоду від злому, застосовується ізоляція коду. Сучасні процесори пропонують механізм апаратного захисту пам'яті, дозволяючи ядру і процесам користувача працювати у відокремлених ділянках пам'яті і оберігаючи їх один від одного. Якщо зламаним виявляється один з користувацьких процесів, ядро залишається в цілості, а завдяки механізму прав доступу зломщик не отримує контроль над усією ОС (якщо тільки зламаний сервіс не працював з правами root). Це досить ефективний метод ізоляції, але не варто повністю покладатися тільки на нього. Багато сервісів просто не можуть бути запущені з правами пересічних користувачів, тому їх злом спричинить за собою компрометацію всієї ОС, а помилки в самому ядрі ОС можуть бути використані для отримання прав адміністратора, навіть у тому випадку, якщо сервіс працював від користувача nobody і був ізольований за допомогою SELinux або BSD Jail. А якщо проникнення відбудеться через стандартне користувальницьке ПЗ (веб-браузер, наприклад), то під загрозою опиняться всі інші користувальницькі додатки і дані про них (проте цього можна уникнути, використовуючи різні облікові записи для різних цілей: купівлі здійснювати під одним користувачем, листування з друзями вести під іншим і т.п.).
Ізоляція більш низького рівня

Виходить, що найбільшу загрозу безпеці несе зовсім не ПЗ, що працює в просторі користувача, а ядро операційної системи. Складне, величезна за розмірами і кількістю підсистем і драйверів монолітне ядро сучасної ОС - просто криниця невідкритих вразливостей. Проникнення з використанням уразливості в ядрі дає зломщикові абсолютну свободу, а проста помилка - до падіння всього і вся. Про це всім нам довго і наполегливо повторював Ендрю Таненбаум, кажучи про перевагу мікроядерних ОС з їх поділом ядра на привілейоване мікроядро і винесенням всіх інших підсистем (таких як драйвера, ФС, мережевий стек і навіть менеджер пам'яті) в окремі процеси. Не послухалися, продуктивність виявилася дорожчою (мікроядра кілька пригальмовують), і сьогодні всі популярні ОС засновані на монолітному ядрі.

Проте можливості сучасних процесорів дозволяють перенести механізм ізоляції ще глибше, який має на увазі використання віртуальних машин, що працюють нижче ядра операційної системи. У цьому випадку можна використовувати будь-які класичні ОС і не турбуватися про те, що помилка в ядрі буде використана для проникнення у віртуальну машину. По-перше, ВМ може бути легко повернута в попередній стан, а по-друге, ніяк не вплине на інші віртуальні машини та їх операційні системи. Цей підхід вже давно використовується провайдерами хмарних обчислень. Але чи може той самий механізм бути застосований для створення безпечної ОС для повсякденного використання? Як виявилося - так.
Зустрічайте: Qubes OS

Qubes OS - це дистрибутив Linux (якщо в даному випадку таке поняття взагалі є), що розробляється під керівництвом відомої Джоана Рутковська, польського фахівця з безпеки. Основна ідея Qubes OS від повсюдної ізоляції на рівні віртуальних машин, за допомогою яких здійснюється відділення користувальницьких додатків від базової ОС.

    Хто вона?

    Джоана Рутковська відома завдяки двом речам. По-перше, вона є творцем відомого і дуже важкого в вилові руткіта Blue Pill, який використовує механізм апаратної віртуалізації для того, щоб помістити всю ОС у віртуальне середовище і крутити їй, як заманеться. За цей журнал eWeek помістив її в п'ятірку хакерів, що залишили слід у 2006 році (Five Hackers who Put a Mark on 2006). У 2009 році спільно з Rafal Wojtczuk вона розкрила спосіб атаки апаратних механізмів захисту процесорів Intel TXT і Intel System Management Mode (SMM). Сьогодні їй належить компанія Invisible Things Labs, яка займається дослідженнями в області безпеки операційних систем і систем віртуалізації.

Серце операційної системи - гіпервізор Xen, який використовується для запуску віртуальних машин, кожна з яких працює під управлінням ядра Linux і набору стандартних служб і додатків рівня користувача (їх набір і кількість може бути різним) і мультиплексування ресурсів компа між ВМ. На малюнку "Архітектура Qubes OS" показана базова архітектура ОС.

Кожна програма (або набір додатків) запускається всередині відокремлених віртуальних машин, чітко відокремлених один від одного за допомогою гіпервізора. Для підвищення безпеки весь мережевий код (включаючи мережні драйвери, стек TCP / IP, DHCP-клієнт і т.д.) працює в рамках окремої віртуальної машини, так само як і код драйверів накопичувачів. Це можливо завдяки технології віртуалізації пристроїв Intel VT-d. Так звана коренева віртуальна машина (Dom0 в термінології Xen) використовується для запуску всіх інших драйверів, системи X Window, графічного менеджера вікон і набору адміністративних утиліт для запуску додатків (віртуальних машин).

За рахунок Xen творцям Qubes OS вдалося відсунути механізм ізоляції виконуваного коду набагато нижче, ніж це зроблено в класичних операційних системах. У цій моделі вразливим місцем стає не ядро операційної системи, а гіпервізор, код якого в сотні разів менше і набагато простіше (а значить, надійніше) кодової бази ядра Linux. Механізми обміну інформацією між віртуальними машинами також набагато більш прості, ніж їхні численні аналоги для комунікації між стандартними процесами в ядрі ОС, а технологія Intel VT-d, що дозволяє винести код драйверів в окремі віртуальні машини, дозволяє ізолювати ненадійні, з точки зору безпеки, драйвера .
Домени додатків

Всі програми користувача Qubes OS запускає всередині виділених віртуальних машин, так званих доменів додатків. Кожен з них працює під управлінням повноцінного дистрибутива Linux і тому їсть ресурси досить наполегливо. Щоб звести до мінімуму загальне навантаження на систему, Qubes OS використовує кілька технік:

    * Qubes OS використовує апаратну підтримку віртуалізації сучасних процесорів (режим Xen HVM), а це означає, що продуктивність ОС, запущеної в рамках віртуальної машини, майже впритул наближається до продуктивності ОС, що працює на "голому" залозі.
    * Qubes OS спирається на семантичне розмежування прав додатків, а це означає, що замість того, щоб поміщати кожне застосування окрему віртуальну машину, ОС групує їх у рамках декількох віртуальних машин за призначенням і рівнем доступу до конфіденційної інформації. Наприклад, користувач може створити домен Entertainment і використовувати його для відпочинку: запускати в ньому аудіо та відеоплеєри, ходити по однокласниках і YouTube. Домен під назвою Shopping може бути використаний для покупок в інтернет-магазинах. Домен Banking - для інтернет-банкінгу та роботи з пластиковими картами. Сенс у тому, що навіть у тому випадку, якщо користувач підчепить якусь гидоту через одне з додатків домену Entertainment, його конфіденційні дані, що зберігаються в доменах Shopping і Banking, залишаться в цілості. Це розумний компроміс, який дозволяє істотно знизити споживання оперативної пам'яті (навіть сучасний комп не потягнув би Qubes OS, якби кожне її додаток працювало на окремій ВМ).
    * Для збереження дискового простору всі домени додатків використовують одну загальну файлову систему. Домен сховища, про який піде мова в однойменному розділі статті, зберігає доступний тільки для читання образ кореневої файлової системи Linux. На його основі для кожного домену додатків створюється пристрій copy-on-write (це можливо завдяки механізму Device Mapper). Домен додатків монтує файлові системи кореневого образу і COW-пристрої до кореневого каталогу. Додатково для кожного домену додатків всередині домену сховища створюється образ для зберігання приватних даних (каталоги / home, / usr / local, / var). Вміст COW-пристрої і способу приватних даних шифрується за допомогою LUKS (The Linux Unified Key Setup), а ключ передається відповідному домену додатків і адміністративному домену. Завдяки такій схемі вдається використовувати один образ кореневої ФС для всіх доменів додатків і в той же час забезпечити його збереження від модифікації. Шифрування дозволяє убезпечити дані доменів додатків на той випадок, якщо зломщик проникне в домен сховища.

Адміністративний домен

Адміністративний домен (Xen Dom0) - найбільш привілейований компонент Qubes OS. Він відповідає за управління доменами додатків, а його повноваження фактично рівні повноважень гіпервізора. З цієї причини адміністративний домен збережений максимально простим: користувач не може запускати додатки в його рамках, а весь низькорівневий код, який бере участь в обміні даних із зовнішньою стороною (мережні драйвери, стек TCP / IP, DHCP-клієнт, брандмауер, драйвера накопичувачів і т. д.), винесений у відокремлені домени: мережевий домен і домен сховища.

Усередині адміністративного домену працюють тільки два компоненти ОС: демон XenStore, використовуваний для зберігання інформації про домени, і GUI-підсистема, заснована на віконній системі X Window і оточенні робочого столу KDE (немає сенсу виносити її в окремий домен, тому що отримавши доступ до GUI , зломщик автоматично отримає доступ до всіх доменів додатків).

Графічна середовище - одне з головних досягнень розробників Qubes OS. Вона не тільки надає користувачам зручний і сучасне графічне оточення з застосуванням 3D-ефектів, але і створює ілюзію того, що всі додатки виконуються в рамках однієї (віртуальної) машини. Програми мають власні вікна, і єдине, що відрізняє графічний інтерфейс Qubes OS від стандартного робочого столу - це різнокольорові рамки, що обрамляють вікна. Так ОС зазначає віртуальні машини, в яких виконується додаток. Без них користувач міг би зробити помилку і ввести свої конфіденційні дані не в тому вікні (додаток, який призначено для ходіння по однокласниках, а не для роботи з кредитними картами, наприклад).

Секрет GUI криється у спеціальному демона і власному X-сервері (з "заглушкою" замість відеодрайвера), що працює всередині кожного домена додатків. Коли відбувається створення нового вікна (або зміна вмісту існуючого), демон отримує його вміст за допомогою стандартної функції XGetImage системи X Window і, використовуючи Xen Ring buffer protocol, відправляє його адміністративному домену. Отримавши зображення, додаток AppViewer, що працює усередині адміністративного домену, виробляє його отрисовку за допомогою функції XRenderComposite.

Графічний інтерфейс Qubes OS не тільки реалізує модель відокремлених вікон для додатків, але і дозволяє виробляти копіювання і вставку між вікнами додатків, а в майбутньому планується реалізація підтримки аудіо.
Мережевий домен

Мережевий код операційної системи представляє реальну небезпеку для її користувачів. У той час як можливий баг в стеку протоколів TCP / IP, який налагоджували роками, дуже малоймовірний, небезпечна помилка в драйвері для нової WiFi-картки - не така вже й рідкість, як це може здатися на перший погляд. Через експлуатацію дірки в мережевому драйвері зломщик зможе отримати повний контроль над ядром, а значить і над всією операційною системою.

З цієї причини код всіх мережевих драйверів в Qubes OS (Network Domain) винесено в окрему віртуальну машину, звану мережевим доменом. На відміну від доменів додатків, він не розділяє загальну кореневу файлову систему з іншими доменами, а замість цього використовує просте Linux-оточення, яке складається з брандмауера, декількох мережевих утиліт і бібліотек, потрібних для їх роботи.

Є тільки три речі, які зможе зробити зломщик, проникнувши в мережевій домен: прослуховувати трафік інших доменів, спробувати зробити ін'єкцію власних пакетів в цей трафік або ж просто обрушити домен. У будь-якому разі все це не призведе до катастрофічних наслідків, тому як трафік важливих доменів, що мають доступ до конфіденційної інформації, звичайно шифрується, а трафік непривілейованого домену додатків, такого як Entertainment, захищати просто не має сенсу. У разі ж зупинки мережевого домену його буде легко повернути до останнього несуперечливою стану (така функціональність вбудована в Qubes OS).

Кожен домен додатків отримує доступ до мережного обладнання через віртуальний мережевий інтерфейс, який Xen створює для кожної віртуальної машини. Усередині домену додатків він має стандартну ім'я eth0. На боці мережевого домену цей віртуальний інтерфейс відображається в інтерфейс vifX.Y, де X - це ідентифікатор домену, а Y - номер інтерфейсу. Зазвичай при створенні віртуальних оточень на основі Xen всі ці інтерфейси vifX, Y з'єднуються з фізичним інтерфейсом (наприклад, wlan0) в конфігурації bridge, так що кожна ВМ має доступ не тільки до фізичного інтерфейсу, але і до всіх інших ВМ. Для Qubes OS, що ставить на чільне столу безпеку, така схема неприйнятна. Тому під час свого запуску і запуску доменів додатків мережевий домен не просто підключає віртуальні інтерфейси до фізичного, але й налаштовує брандмауер так, щоб домени додатків не змогли отримати доступ один до одного.
Домен сховища

У сучасних ОС код, який відповідає за роботу з накопичувачами, не менш комплексний, ніж мережева частина. Він включає в себе код драйверів пристроїв, реалізацію протоколів ATA і SCSI, USB-стек, код демонів рівня користувача. Кожен з цих компонентів може дати збій або призвести до злому. Для запуску всього цього коду Qubes OS використовує виділену віртуальну машину, звану доменом сховища (Storage Domain).

У рамках домену сховища працює весь код драйверів пристроїв зберігання та всі необхідні для їх роботи підсистеми ядра і демони рівня користувача. Також він відповідає за зберігання образів кореневої файлової системи Linux, образів для зберігання приватних даних доменів додатків і файлів, необхідних для завантаження ОС (завантажувальний розділ). Щоб убезпечити ці дані від тих, хто зміг проникнути в домен сховища, використовуються різні техніки:

    * Образи приватних даних доменів додатків шифруються. При цьому ключ шифрування відомий тільки відповідного домену додатків і адміністративному домену.
    * Образ кореневої файлової системи захищається від модифікації за допомогою цифрового підпису, ключ якої відомий тільки адміністративному домену. Якщо цей образ буде модифікований, операційна система повідомить про це користувачеві.
    * Захист завантажувальних файлів ОС здійснюється за допомогою довіреної механізму завантаження, заснованого на технології Intel TXT. Це означає, що, якщо завантажувальні файли будуть модифіковані, операційна система просто не зможе завантажитися.

Єдине, що зможе зробити зломщик, заволодівши доменом сховища, це вивести його з ладу. Однак, як вже було сказано в попередньому розділі, що вийшов з ладу домен Xen досить легко повернути до попереднього стану.
Процес завантаження

Процес завантаження Qubes OS можна умовно розділити на сім етапів:

   1. Перший крок включає в себе перевірку автентичності файлів, необхідних для завантаження гіпервізора та адміністративного домену (чи не були вони пошкоджені або модифіковані). Вона здійснюється за допомогою технології Intel TXT (Trusted Execution Technology). Якщо перевірка пройшла успішно, то в наступних кроках ОС зможе отримати доступ до ключів шифрування дисків з апаратного модуля TPM (Trusted Platform Module).
   2. Далі відбувається завантаження і запуск гіпервізора, ядра адміністративного домену та скрипта ініціалізації initramfs. Це відбувається поза залежністю від результату перевірки на першому етапі, однак якщо перевірка дала помилковий результат, ОС не зможе зробити завантаження інших своїх частин, тому що не отримає від TPM ключів шифрування.
   3. Скрипт initramfs запитує у користувача пароль, який може бути введений вручну або зберігається на карті пам'яті. Цей крок необхідний для того, щоб тільки авторизований користувач зміг отримати доступ до системи. Якщо справжність завантажувальних файлів була підтверджена на першому кроці, і користувач ввів правильний пароль, система може розшифрувати файл keys.gpg, який містить ключі, необхідні для наступних етапів завантаження.
   4. Після розшифровки файлу keys.gpg скрипт initramfs може приступити до створення домену сховища.
   5. Qubes OS створює нову віртуальну машину для домену сховища і підключає до неї його кореневу ФС, зашифровану з використанням ключа, що зберігається у файлі keys.gpg.
   6. Домен сховища монтує інший розділ, який використовується для зберігання образів кореневих ФС і приватних даних доменів додатків. Тепер скрипт initramfs може змонтувати свою кореневу файлову систему, запустити мережевий домен, систему X Window, оточення робочого столу і таким чином завершити процес завантаження.
   7. Система завантажена і ініціалізований. Тепер користувач може запускати додатки.

Висновки

Qubes OS виявилася набагато простіше, ніж цього можна було очікувати від по-справжньому безпечної операційної системи. По суті, вона не приносить у світ ОС нічого кардинального нового, але показує, що жорстка ізоляція може застосовуватися не тільки по відношенню до серверів, для супроводу яких потрібен грамотний адміністратор, і дослідних ОС, таких як Singularity, але і відносно ОС для пересічних користувачів . І це дійсно великий крок вперед.