На Хабре не много статии, посветени на операционната система 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 (човешки интерфейсни устройства) предаване на команди в 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. На етапа на крос-билда проведохме няколко опростяващи промени основно в частта за "тиха" инсталация на утилити, а също така премахнахме досадната деградация на производителността при продължителна работа в VM. Резултатите от работата оформяхме в отделно , по този начин за кратко водещия разработчик на Qubes.
Най-критичният етап за стабилността на гост-основата е стартирането на Windows, тук можете да видите познатия син екран (или дори да не го видите). За повечето установени грешки се намериха различни обходни варианти — отказ от Xen драйвери за блокови устройства, деактивиране на балансирането на паметта на VM, фиксиране на мрежовите настройки и минимизиране на броя на ядрата. Нашият пакет с гост-утилити се инсталира и работи на напълно обновени Windows 7 и Windows 10 (с изключение на qvideo).
Мина при преминаване от реална среда към виртуална възниква проблем с активирането на Windows в случай на използване на предварително инсталирани OEM версии. Такива системи използват активация на базата на лицензии, записани в UEFI устройството. За правилното изпълнение на активацията е необходимо да се трансферира в гостоприемната система една от секциите ACPI на хост системата изцяло (таблица SLIC) и малко да се коригират други, записвайки производителя. Xen позволява настройването на съдържанието на допълнителните таблици ACPI, но без модификация на основните. С решението помогна патч от подобен проект OpenXT, който беше адаптиран за Qubes. Корекциите се оказаха полезни не само за нас и бяха трансферирани в основния репозитории на Qubes и библиотеката Libvirt.
Очевидните недостатъци на средствата за интеграция на Windows включват липсата на поддръжка на звук, USB устройства и трудности при работа с медии, тъй като няма хардуерна поддръжка на GPU. Но посоченото не пречи на използването на ВМ за работа с офис документи и не пречи на стартирането на специфични корпоративни приложения.
Изискването да се премине в режим на работа без мрежа или с ограничена свързаност след създаването на шаблона Windows ВМ беше изпълнено чрез създаване на съответните конфигурации на приложни ВМ, а възможността за селективно свързване на сменяеми носители също беше разрешена с инсталираните средства на ОС — при свързване те са достъпни в системната ВМ sys-usb, от която могат да бъдат "пробити" в необходимата ВМ. Работният плот на потребителя изглежда приблизително така.
Крайната версия на системата беше позитивно приета от потребителите (доколкото такова комплексно решение позволява), а вградените средства на системата позволиха разширяване на приложението до мобилната работна станция на потребителя с достъп чрез VPN.
Вместо заключение
Виртуализацията като цяло намалява рисковете от използването на Windows системи, оставени без поддръжка — не принуждава към осигуряване на съвместимост с нови хардуерни средства, позволява изключване или контрол на достъпа до системата по мрежата или посредством свързани устройства, позволява реализирането на среда за еднократно стартиране.
ОС Qubes, основана на концепции изоляции через виртуализацию, что помогает использовать различные механизмы для обеспечения безопасности. Взгляд со стороны подчеркивает стремление к анонимности, но это полезная система как для инженеров, часто работающих над несколькими проектами с инфраструктурой и секретами доступа к ним, так и для исследователей безопасности. Разделение приложений, данных и формализация их взаимодействия — это начальные шаги анализа угроз и проектирования системы защиты. Такое разделение помогает структурировать информацию и снизить вероятность ошибок, вызванных человеческим фактором — спешкой, усталостью и тому подобным.
В настоящее время основной акцент в разработке делается на расширение функциональности сред Linux. Готовится к выходу версия 4.1, которая будет основываться на Fedora 31 и включать актуальные версии ключевых компонентов Xen и Libvirt. Следует отметить, что Qubes разрабатывается профессионалами в области информационной безопасности, которые всегда вовремя выпускают обновления при выявлении новых угроз или ошибок.
Следсловие
Одна из экспериментальных возможностей, над которыми мы работаем, позволяет создавать виртуальные машины с поддержкой гостевого доступа к GPU на основе технологии Intel GVT-g. Это открывает новые возможности графического адаптера и значительно расширяет область применения системы. На момент написания статьи этот функционал доступен для тестовых сборок Qubes 4.1 и доступен на .
Източник: habr.com
