На Хабре не так много статей, посвященных операционной системе 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) — режим виртуализации без использования аппаратной поддержки, напоминает контейнерную виртуализацию, может использоваться для систем c адаптированным ядром (в таком режиме функционирует 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, и доступен на github.
