Na Habu není mnoho článků věnovaných operačnímu systému Qubes, a ty, které jsem viděl, málo popisují zkušenosti s jeho využitím. Doufám, že toto napravím na příkladu použití Qubes jako ochranného prostředku pro Windows a zároveň zhodnotím počet rusky mluvících uživatelů systému.
Proč Qubes?
Situace s koncem technické podpory Windows 7 a zvyšující se obavy uživatelů vedla k nutnosti zorganizovat práci tohoto operačního systému s ohledem na následující požadavky:
- zajistit použití plně aktivované Windows 7 s možností uživatelského instalování aktualizací a různých aplikací (včetně přes Internet);
- implementovat úplné nebo selektivní vyloučení síťových interakcí na základě podmínky (režimy offline a filtrování provozu);
- poskytnout možnost selektivního připojení externích nosičů a zařízení.
Tento soubor omezení předpokládá jasně připraveného uživatele, neboť je povoleno samostatné administrativní řízení, a omezení nesouvisí s blokováním jeho potenciálních činů, ale s vyloučením možných chyb či destruktivního vlivu softwaru. Tedy interní narušitel v modelu není.
Při hledání řešení jsme rychle opustili myšlenku implementovat omezení vnořenými nebo dodatečnými prostředky Windows, protože je dost obtížné efektivně omezit uživatele s administrátorskými právy, zatímco mu zůstane možnost instalovat aplikace.
Dalším variantou řešení byla izolace pomocí virtualizace. Široce známé nástroje pro desktopovou virtualizaci (například jako virtualbox) jsou špatně přizpůsobeny pro bezpečnostní úkoly a uvedená omezení bude nutné neustále nastavovat uživatelům přepínáním nebo nastavováním vlastností hostitelské virtuální mašiny (dále VМ), což zvyšuje rizika chyb.
Zároveň jsme měli zkušenosti s používáním Qubes jako uživatelského desktopového systému, ale byli jsme skeptičtí ohledně stability práce s hostitelským Windows. Bylo rozhodnuto otestovat aktuální verzi Qubes, protože stanovená omezení velmi dobře zapadají do paradigmatu tohoto systému, zejména realizace šablon virtuálních strojů a vizuální integrace. Následující text se pokusím stručně představit myšlenky a nástroje Qubes na příkladu vyřešení daného úkolu.
Typy virtualizace Xen
Qubes je postaven na hypervizoru Xen, který minimalizuje funkce správy zdrojů procesoru, paměti a virtuálních strojů. Veškerá další práce se zařízeními je soustředěna v dom0 na bázi jádra Linuxu (v Qubes pro dom0 se používá distribuce Fedora).
Xen podporuje několik typů virtualizace (budu uvádět příklady pro Intel architekturu, i když Xen podporuje i jiné):
- paravirtualizace (PV) — režim virtualizace bez použití hardwarové podpory, připomíná kontejnerovou virtualizaci, může být používán pro systémy s přizpůsobeným jádrem (v takovém režimu funguje dom0);
- plná virtualizace (HVM) — v tomto režimu se pro zdroje procesoru používá hardwarová podpora, zatímco veškeré ostatní zařízení jsou emulována prostřednictvím QEMU. Je to nejuniverzálnější způsob spuštění různých operačních systémů;
- paravirtualizace hardwaru (PVH — ParaVirtualized Hardware) — režim virtualizace s využitím hardwarové podpory, kdy jádro hostitelského systému používá ovladače upravené pro specifikace hypervizoru (například sdílenou paměť), což eliminuje potřebu emulace QEMU a zvyšuje výkon vstupu a výstupu. Jádro Linuxu od verze 4.11 může fungovat v tomto režimu.
Od verze Qubes 4.0 se z bezpečnostních důvodů upouští od využívání režimu paravirtualizace (mimo jiné kvůli známým zranitelnostem architektury Intel, které jsou zčásti eliminovány použitím plné virtualizace), standardně se používá režim PVH.
Při použití emulace (režim HVM) se spuštění QEMU provádí v izolované VM zvané stubdomain, čímž se snižují rizika zneužití potenciálních chyb v implementaci (projekt QEMU obsahuje mnoho kódu, včetně pro kompatibilitu).
Takový režim by se v našem případě měl použít pro Windows.
Služební virtuální stroje
V architektuře bezpečnosti Qubes je jednou z klíčových funkcí hypervizora předávání PCI zařízení do hostitelského prostředí. Vyloučení hardwaru umožňuje izolovat hostitelskou část systému od externích útoků. Xen to podporuje pro režimy PV a HVM, přičemž ve druhém případě je vyžadována podpora IOMMU (Intel VT-d) — hardwarové řízení paměti pro virtualizovaná zařízení.
Takto se vytváří několik systémových virtuálních strojů:
- sys-net, který přebírá síťová zařízení a který se používá jako most pro další VM, například realizující funkce firewallu nebo klienta VPN;
- sys-usb, který přebírá USB a další ovladače periferních zařízení;
- sys-firewall, který nepoužívá zařízení, ale funguje jako firewall pro připojené VM.
Pro práci s USB zařízeními se používají proxy služby, které zajišťují mimo jiné:
- pro třídu zařízení HID (human interface device) přenos příkazů do dom0;
- pro přenosné disky přesměrování svazků zařízení do dalších VM (s výjimkou dom0);
- přesměrování přímo USB zařízení (používá se USBIP a integrační nástroje).
V takové konfiguraci může úspěšný útok přes síťový zásobník nebo připojená zařízení vést k kompromitaci pouze spuštěné služební VM, nikoli celé systému. A po restartu služební VM se načte v původním stavu.
Nástroje pro integraci VM
Existuje několik způsobů, jak interagovat s pracovní plochou virtuálního stroje — instalace aplikací do hostitelského systému nebo emulace videa pomocí virtualizačních prostředků. Jako hostitelské aplikace mohou fungovat různé univerzální prostředky pro vzdálený přístup (RDP, VNC, Spice atd.) nebo přizpůsobené konkrétním hypervizoru (takovéto nástroje obvykle nazýváme hostitelskými utilitami). Může být také použit smíšený přístup, kdy hypervizor emuluje vstup-výstup pro hostitelský systém a venku poskytuje možnost používat protokol kombinující vstup-výstup, například jako u Spice. V tomto případě vzdálené přístupové nástroje obvykle optimalizují obraz, protože jsou navrženy pro práci přes síť, což negativně ovlivňuje kvalitu obrazu.
Qubes nabízí vlastní prostředky pro integraci VM. Především je to grafický subsystém — okna z různých VM se zobrazují na jediné pracovní ploše s vlastním barevným rámováním. Obecně jsou prostředky integrace založeny na možnostech hypervizoru — sdílené paměti (Xen grant table), prostředcích notifikace (Xen event channel), sdíleném úložišti xenstore a komunikačním protokolu vchan. Pomocí nich se realizují základní komponenty qrexec a qubes-rpc, a aplikační služby — přesměrování zvuku nebo USB, přenos souborů nebo obsahu schránky, vykonávání příkazů a spouštění aplikací. Existuje možnost nastavovat politiky, které omezují dostupné služby na VM. Na obrázku níže je příklad postupu inicializace interakce dvou VM.
Takto probíhá práce ve VM bez použití sítě, což umožňuje plně využívat autonomní VM k vyhnutí se úniku informací. Například tímto způsobem je realizováno oddělení kryptografických operací (PGP/SSH), kdy se soukromé klíče používají v izolovaných VM a nepřesahují jejich hranice.
Šablony, aplikace a jednorázové VM
Všechny činnosti uživatele v Qubes probíhají ve virtuálních strojích. Hlavní hostitelský systém slouží k řízení jejich činnosti a vizualizaci. Operační systém se instaluje spolu se základním souborem virtuálních strojů na základě šablon (TemplateVM). Taková šablona představuje Linux VM založenou na distribuci Fedora nebo Debian, se nainstalovanými a nakonfigurovanými prostředky integrace, vyhrazenými systémovými a uživatelskými oddíly. Instalace a aktualizace softwaru se provádí standardním správcem balíčků (dnf nebo apt) z nakonfigurovaných repozitářů s povinnou kontrolou digitálního podpisu (GnuPG). Účelem takových VM je zajistit důvěru k aplikativním VM, které na jejich základě běží.
Aplikační VM (AppVM) při startu používá snímek systémového oddílu příslušné šablony VM, a po dokončení práci tento snímek odstraní bez zachování změn. Potřebná uživatelská data jsou uložena v unikátním uživatelském oddílu pro každou aplikační VM, který je připojen do domácího adresáře.
Užitečné z hlediska bezpečnosti může být použití jednorázových VM (disposableVM). Taková VM se vytváří na základě šablony v okamžiku spuštění a je spuštěna s jedním cílem - provedením jedné aplikace, ukončující svou činnost po jejím zavření. Jednorázové VM mohou být používány pro otevírání podezřelých souborů, jejichž obsah může vyústit ve využití zranitelností konkrétních aplikací. Možnost spuštění jednorázové VM je integrována do správce souborů (Nautilus) a poštovního klienta (Thunderbird).
Windows VM může být také použita k vytvoření šablony a jednorázové VM, pro to je uživatelský profil přenesen do samostatného oddílu. V naší variantě bude tato šablona používána uživateli pro administrativní úkoly a instalaci aplikací. Na základě šablony bude vytvořeno několik aplikačních VM - s omezeným přístupem do sítě (standardní možnosti sys-firewall) a bez přístupu do sítě vůbec (ne vytváří se virtuální síťové zařízení). Pro práci v těchto VM budou dostupné všechny změny a aplikace instalované v šabloně a i v případě zavedení programů-zakládek jim nebude dostupný síťový přístup pro kompromitaci.
Boj za Windows
Popisované možnosti jsou základem Qubes a fungují poměrně stabilně, problémy začínají s Windows. Pro integraci Windows je nutné použít sadu nástrojů Qubes Windows Tools (QWT), která zahrnuje ovladače pro práci s Xen, ovladač qvideo a sadu utilit pro výměnu informací (přenos souborů, clipboard). Proces instalace a nastavení je podrobně zdokumentován na webu projektu, proto se podělíme o naše zkušenosti.
Hlavní obtíž spočívá v podstatě v absenci podpory vyvinutého nástroje. Klíčoví vývojáři (QWT) jsou zřejmě nedostupní a projekt integrace s Windows čeká na vedoucího vývojáře. Proto bylo nejprve nutné posoudit funkčnost a utvořit si představu o možnosti jeho podpory v případě potřeby samostatně. Nejtěžší na vývoj a ladění je grafický ovladač, který emuluje grafickou kartu a displej pro formování obrazu v sdílené paměti, což umožňuje zobrazit celou pracovní plochu nebo konkrétní okno aplikace v okně hostitelského systému. Během analýzy práce ovladače jsme adaptovali kód pro sestavení v prostředí Linux a vyladili schéma ladění mezi dvěma hostovanými systémy Windows. V rámci krosového sestavení jsme provedli několik usnadnění zejména v části "tichého" instalování utilit a odstranili jsme otravnou degradaci výkonu při dlouhodobém provozu ve VM. Výsledky naší práce jsme zformulovali do samostatného , čímž na chvíli vedoucího vývojáře Qubes.
Nejkritičtějším krokem z pohledu stability hostitelského systému je spuštění Windows, zde se může objevit známá modrá obrazovka (nebo ji dokonce ani nevidět). Pro většinu identifikovaných chyb byly nalezeny různé obchvaty — odmítnutí ovladačů Xen blokových zařízení, vypnutí vyvažování paměti VM, fixace síťových nastavení a minimalizace počtu jader. Naše sestavení hostitelských prostředků se instaluje a funguje na plně aktualizovaných Windows 7 a Windows 10 (s výjimkou qvideo).
Při přechodu z reálného prostředí do virtuálního se objevuje problém s aktivací Windows v případě použití předinstalovaných OEM verzí. Tyto systémy využívají aktivaci založenou na licencích, které jsou zapsány v UEFI zařízení. Pro správné fungování aktivace je nutné převést do hostovacího systému jeden z oddílů ACPI hostitelského systému v celku (SLIC tabulka) a mírně upravit další, zapisováním výrobce. Xen umožňuje nakonfigurovat obsah ACPI dodatečných tabulek, ale bez modifikace základních. S řešením pomohl patch od podobného projektu OpenXT, který byl přizpůsoben pro Qubes. Opravy se ukázaly jako užitečné nejen pro nás a byly přeneseny do hlavního repozitáře Qubes a knihovny Libvirt.
Mezi zřejmé nedostatky integračních prostředků Windows patří absence podpory zvuku, USB zařízení a složitost práce s médií, neboť zde chybí hardwarová podpora GPU. Ale uvedené nebrání používání VM pro práci s kancelářskými dokumenty a nebrání spuštění specifických firemních aplikací.
Požadavek na přepnutí do režimu práce bez sítě nebo s omezenou sítí po vytvoření šablony Windows VM byl splněn vytvořením odpovídajících konfigurací aplikačních VM, a možnost selektivního připojení přenosných médií byla rovněž vyřešena standardními prostředky OS — po připojení jsou dostupná v systémové VM sys-usb, odkud mohou být "prohozeny" k potřebné VM. Pracovní plocha uživatele vypadá zhruba takto.
Konečná verze systému byla uživateli přijata pozitivně (jak to komplexní řešení dovoluje) a standardní prostředky systému umožnily rozšířit použití na mobilní pracovní místo uživatele s přístupem prostřednictvím VPN.
Na závěr
Virtualizace obecně snižuje rizika spojená s použitím Windows systémů, které jsou ponechány bez podpory — nenutí zajištění kompatibility s novými hardwarovými prostředky, umožňuje vyloučení nebo kontrolu přístupu k systému přes síť nebo prostřednictvím připojených zařízení, a umožňuje realizaci prostředí pro jednorázové spuštění.
OS Qubes, založená na myšlence izolace prostřednictvím virtualizace, pomáhá využívat tyto a další mechanismy pro zajištění bezpečnosti. Z pohledu mnohých je Qubes především snahou o anonymitu, ale je to užitečný systém jak pro inženýry, kteří často spojují projekty, infrastruktury a tajné přístupy k nim, tak pro bezpečnostní výzkumníky. Oddělení aplikací, dat a formalizace jejich interakce jsou počátečními kroky analýzy hrozeb a navrhování ochranného systému. Takové rozdělení pomáhá strukturovat informace a snižovat pravděpodobnost chyby způsobené lidským faktorem — spěchem, únavou atd.
V současnosti se hlavní důraz v rozvoji klade na rozšíření funkčnosti Linuxových prostředí. Připravuje se k vydání verze 4.1, která bude založena na Fedoře 31 a zahrnuje aktuální verze klíčových komponentů Xen a Libvirt. Je třeba poznamenat, že Qubes vytvářejí profesionálové v oblasti informační bezpečnosti, kteří vždy rychle vydávají aktualizace v případě zjištění nových hrozeb nebo chyb.
Poznámka na závěr
Jedna z našich vyvíjených experimentálních funkcí umožňuje vytváření VM s podporou hostitelského přístupu k GPU na základě technologie Intel GVT-g, což umožňuje využívat možnosti grafického adaptéru a značně rozšířit oblast použití systému. V době psaní tohoto článku tato funkce funguje pro testovací sestavení Qubes 4.1 a je dostupná na .
Zdroj: habr.com
