Използване на QubesOS за работа с Windows 7

В Хабра не много статей, посветени на операционната система 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 VM, базирана на дистрибуцията Fedora или Debian, с инсталирани и конфигурирани средства за интеграция, определени системни и потребителски дялове. Инсталирането и актуализирането на софтуера се извършва от стандартния пакетен мениджър (dnf или apt) от настроените хранилища с задължителна проверка на цифровия подпис (GnuPG). Назначението на тези VM е осигуряването на доверие към приложните VM, стартиращи на тяхна основа.

Приложната VM (AppVM) при стартиране използва моментен запис на системния дял на съответния шаблон VM и след завършването му изтрива този моментен запис без запазване на измененията. Необходимите за потребителя данни се съхраняват в уникален за всяка приложна VM потребителски дял, който се монтира в домашната директория.

Полезно от гледна точка на сигурността може да е използването на еднократни VM (disposibleVM). Такава VM се създава на база шаблон в момента на стартиране и се стартира с една цел — изпълнение на едно приложение, завършвайки работа след неговото затваряне. Еднократните VM могат да се използват за отваряне на съмнителни файлове, съдържанието на които може да доведе до експлоатация на уязвимости на конкретни приложения. Възможността за стартиране на еднократна VM е интегрирана в файловия мениджър (Nautilus) и пощенския клиент (Thunderbird).

Windows VM също може да бъде използвана за създаване на шаблон и еднократна VM, за тази цел профилът на потребителя се прехвърля в отделен дял. В нашия вариант такъв шаблон ще бъде използван от потребителя за задачи по администриране и инсталиране на приложения. На основата на шаблона ще бъдат създадени няколко приложни VM — с ограничен достъп до мрежата (стандартните възможности на sys-firewall) и без достъп до мрежата изобщо (въобразено е виртуално мрежово устройство). За работа в тези VM ще бъдат достъпни всички промени и приложения, инсталирани в шаблона и дори в случай на внедряване на шпионски софтуер, им ще бъде недостъпен мрежов достъп за компрометиране.

Борба за 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, основана на идеята за изолация чрез виртуализация, помага да се използват тези и други механизми за осигуряване на безопасност. Отстрани, много хора виждат в Qubes на първо място стремеж към анонимност, но това е полезна система както за инженери, които често съчетават проекти, инфраструктури и тайни достъпи до тях, така и за изследователи на безопасността. Разделението на приложения, данни и формализирането на тяхното взаимодействие са начални стъпки в анализа на заплахите и проектирането на система за защита. Такова разделение помага да се структурира информацията и да се намали вероятността за грешки поради човешкия фактор — бързане, умора и т.н.

В момента основният фокус в разработката е върху разширяване на функционалността на Linux средите. Готви се за пускане версия 4.1, която ще бъде основана на Fedora 31 и ще включва актуални версии на ключовите компоненти Xen и Libvirt. Трябва да се отбележи, че Qubes се разработва от професионалисти в областта на информационната безопасност, които винаги бързо пускат актуализации при откритие на нови заплахи или грешки.

Следсловие

Една от развиваните от нас експериментални възможности позволява създаване на ВМ с поддръжка на гостен достъп до GPU на базата на технологията Intel GVT-g, което позволява използването на възможностите на графичния адаптер и значително разширява обхвата на приложение на системата. Към момента на написване на статията тази функционалност работи за тестови версии на Qubes 4.1 и е достъпна на github.

Източник: habr.com