🥇A QubesOS használata Windows 7-tel

A Habrán nem sok cikk található a Qubes operációs rendszerről, és azok is kevéssé írják le az alkalmazás élményeit. A következő részben remélem, hogy ezt a példán keresztül javíthatom, bemutatva a Qubes használatát a Windows környezet védelmi eszközeként, és egyúttal felmérhetem az oroszul beszélő felhasználók számát.

Miért Qubes?

A Windows 7 támogatásának megszűnésével és a felhasználók fokozódó aggodalmaival a rendszer működésének megszervezésére volt szükség, figyelembe véve a következő követelményeket:

biztosítani kell egy teljes körűen aktivált Windows 7 alkalmazását, amely lehetővé teszi a felhasználó számára a frissítések és különböző alkalmazások telepítését (beleértve az Internetet is);
meg kell valósítani a teljes vagy szelektív hálózati interakciók kizárását bizonyos feltételek mellett (offline üzemmódok és forgalom szűrés);
lehetővé kell tenni a szelektív csatlakozást eltávolítható tárolókhoz és eszközökhöz.

Ilyen korlátozások megvalósítása egyértelműen felkészült felhasználót igényel, mivel az önálló adminisztráció engedélyezett, és a korlátozások nem a potenciális cselekedeteinek blokkolásáról, hanem a potenciális hibák vagy romboló programok hatásainak kizárásáról szólnak. Tehát az internalis ártó a modellben nincs.

A megoldás keresése során gyorsan lemondtunk arról az ötletünkről, hogy a Windows beépített vagy kiegészítő eszközeivel valósítsuk meg a korlátozásokat, mivel elég nehéz hatékonyan korlátozni a felhasználót adminisztrátori jogosultságokkal, miközben lehetőséget adunk számára alkalmazások telepítésére.

A következő megoldási lehetőség a virtualizáció általi elszigetelés volt. A közismert asztali virtualizációs eszközök (például a virtualbox) nem megfelelőek a biztonsági problémák megoldására, és az említett korlátozásokat a felhasználóknak folyamatosan kellene beállítaniuk vagy módosítani a vendég virtuális gép (továbbiakban V.M.) tulajdonságait, ami növeli a hibák kockázatát.

Ugyanakkor volt tapasztalatunk a Qubes asztali operációs rendszerként való használatával, de kétségeink voltak a Windows virtuális gép stabilitásával kapcsolatban. Eldöntöttük, hogy ellenőrizzük a Qubes legfrissebb verzióját, mivel a megadott korlátok jól illeszkednek a rendszer paradigmájába, különösen a virtuális gépek sablonjainak megvalósítása és a vizuális integráció terén. A következőkben próbálok röviden beszámolni a Qubes ötleteiről és eszközeiről a feladat megoldásának példáján keresztül.

Xen virtualizálási típusai

A Qubes alapja a Xen hipervizor, amely minimalizálja a CPU, a memória és a virtuális gépek erőforrás-kezelési funkcióit. Minden egyéb eszközkezelés a Linux magon alapuló dom0-ban összpontosul (a Qubes esetében a dom0 Fedora disztribúciót használ).

A Xen többféle virtualizálási típust támogat (példákat az Intel architektúrára fogok hozni, bár a Xen másokat is támogat):

párhuzamos virtualizálás (PV) – olyan virtualizálási mód, amely nem használ hardvertámogatást, hasonlít a konténeres virtualizálásra, alkalmazható olyan rendszerek esetében, amelyekhez a kernel van igazítva (ebben a módban működik a dom0);
teljes virtualizálás (HVM) – ebben a módban a CPU erőforrásaihoz hardvertámogatás szükséges, míg minden egyéb hardver a QEMU eszközök segítségével van emulálva. Ez a leguniverzálisabb mód különböző operációs rendszerek indítására;
hardver párhuzamos virtualizálás (PVH – ParaVirtualized Hardware) – olyan virtualizálási mód, amely hardvertámogatást használ, amikor a vendég rendszer magja az eszközökkel való munkához a hipervizor lehetőségeinek megfelelő illesztőprogramokat használ (például megosztott memória), ezzel megszüntetve a QEMU emuláció szükségességét, és növelve a bemeneti-kimeneti teljesítményt. A Linux kernel 4.11-től kezdve képes ilyen módban működni.

A Qubes 4.0 verziójától kezdve biztonsági megfontolások miatt lemondanak a párhuzamos virtualizálás alkalmazásáról (az ismert Intel architektúrák sebezhetőségei miatt is, amelyek részben megszüntethetők teljes virtualizálás alkalmazásával), alapértelmezés szerint a PVH módot használják.

A QEMU launch in an isolated VM called stubdomain is implemented when using emulation (HVM mode), thereby reducing the risks of exploiting potential implementation errors (the QEMU project contains a lot of code, including for compatibility).
Such a mode should be used for Windows in our case.

Service Virtual Machines

In the security architecture of Qubes, one of the key capabilities of the hypervisor is passing PCI devices to the guest environment. Hardware exclusion allows isolating the host part of the system from external attacks. Xen supports this for both PV and HVM modes; in the latter case, support for IOMMU (Intel VT-d) is required — hardware memory management for virtualized devices.

This creates several system virtual machines:

sys-net, to which network devices are assigned and which is used as a bridge for other VMs, for example, implementing firewall functions or VPN client;
sys-usb, to which USB and other peripheral device controllers are assigned;
sys-firewall, which does not use devices but acts as a firewall for connected VMs.

For working with USB devices, proxy services are used that provide, among other things:

for HID (human interface device) class devices, command transmission to dom0;
for removable media, redirection of device volumes to other VMs (except dom0);
direct redirection of USB devices (USBIP and integration tools are used).

In such a configuration, a successful attack through the network stack or connected devices can compromise only the running service VM, not the entire system. After restarting the service VM, it will be loaded in its original state.

VM integration tools

Többféle módon lehet interakcióba lépni a virtuális gép asztalával — alkalmazások telepítése a vendég rendszerbe vagy a videó emulálása virtualizációs eszközökkel. Vendégalkalmazásokként különböző általános távoli hozzáférési eszközök (RDP, VNC, Spice stb.) vagy a konkrét hypervisorhoz igazított eszközök alkalmazhatók (ezeket az eszközöket általában vendég segédprogramoknak hívják). A hibrid megoldás is alkalmazható, ahol a hypervisor emulálja a be- és kimenetet a vendég rendszer számára, míg kívülről egy olyan protokollt kínál, amely kombinálja a be- és kimenetet, mint a Spice esetében. Ezen kívül a távoli hozzáférési eszközök általában optimalizálják a képet, mivel a hálózaton keresztül történő munkavégzést tételeznek fel, ami nem kedvez a kép minőségének.

A Qubes saját eszközöket biztosít a VM-ek integrálásához. Elsősorban ez egy grafikus alrendszer — különböző VM-ek ablakai egy egységes asztalon jelennek meg, saját színkerettel. Az integrációs eszközök alapvetően a hypervisor képességeire építenek — megosztott memória (Xen grant table), értesítési eszközök (Xen event channel), megosztott tároló (xenstore) és kommunikációs protokoll (vchan). Ezek segítségével valósulnak meg a qrexec és qubes-rpc alapvető összetevői, valamint az alkalmazási szolgáltatások — hang vagy USB átirányítása, fájlok vagy vágólap tartalmának átvitele, parancsok végrehajtása és alkalmazások indítása. Lehetőség van politikák beállítására, amelyek korlátozzák a VM-en elérhető szolgáltatásokat. Az alábbi ábrán a két VM közötti interakció inicializálásának folyamata látható.

Így a VM-en végzett munkát nem hálózat használatával valósítják meg, ami lehetővé teszi az önálló VM-ek teljes körű kihasználását az információszivárgás elkerülése érdekében. Például így valósul meg a kriptográfiai műveletek elkülönítése (PGP/SSH), amikor a titkos kulcsokat izolált VM-ekben használják, és azok nem lépnek ki a kereteikből.

Sablonok, alkalmazásos és egyszer használatos VM-ek

A felhasználó minden munkája a Qubes-ben virtuális gépekben történik. A fő hoszt rendszer a működésük irányítására és vizualizálására szolgál. Az operációs rendszert egy alapvető virtuális gépcsoporttal együtt telepítik, amely sablonok alapján készült (TemplateVM). Egy ilyen sablon egy Linux VM, amely a Fedora vagy Debian disztribúcióra épül, és telepített és beállított integrációs eszközökkel, valamint elkülönített rendszer- és felhasználói partíciókkal rendelkezik. A szoftver telepítése és frissítése a standard csomagkezelő (dnf vagy apt) segítségével történik, a beállított tárolókból, kötelező digitális aláírás-ellenőrzéssel (GnuPG). Az ilyen VM-ek célja a bizalom biztosítása a rajtuk futó alkalmazás VM-ek iránt.

Az alkalmazás VM (AppVM) induláskor a megfelelő VM sablonról készített rendszerpartíció pillanatképét használja, és a munkamenet befejezése után ezt a pillanatképet a módosítások megőrzése nélkül eltávolítja. A felhasználónak szükséges adatokat minden alkalmazás VM-hez külön felhasználói partícióban tárolják, amely a felhasználó otthoni könyvtárába van csatolva.

A biztonság szempontjából hasznos lehet az egyszer használatos VM-ek (disposableVM) alkalmazása. Ez a VM a sablon alapján jön létre, amikor elindítják, és egyetlen célra indul — egy alkalmazás végrehajtására, lezárva a munkát a program bezárásakor. Az egyszer használatos VM-eket gyanús fájlok megnyitására használhatják, amely fájlok tartalma kihasználhatja a konkrét alkalmazások sebezhetőségeit. Az egyszer használatos VM indításának lehetősége integrálva van a fájlkezelőbe (Nautilus) és az e-mail kliensbe (Thunderbird).

A Windows VM-et a sablon és az egyszer használatos VM létrehozására is felhasználhatják, ehhez a felhasználói profilt külön partícióra kell áthelyezni. Az általunk bemutatott változatban ezt a sablont az adminisztrációs és alkalmazástelepítési feladatokhoz használják. A sablon alapján több alkalmazás VM jön létre — korlátozott hálózati hozzáféréssel (a sys-firewall beépített funkciói) és teljes hálózati hozzáférés nélküli (nem hoznak létre virtuális hálózati eszközöket). Ezekben a VM-ekben elérhetőek lesznek a sablonban telepített és módosított alkalmazások, és még akkor is, ha kártevő programok épülnek be, azoknak nem lesz hálózati hozzáférésük a kompromittáláshoz.

Harcolni a Windows ellen

A fentiekben leírt lehetőségek a Qubes alapját képezik, és meglehetősen stabilan működnek, a nehézségek Windows alatt kezdődnek. A Windows integrálásához a Qubes Windows Tools (QWT) vendégszerszámkészletet kell használni, amely tartalmazza a Xen működéséhez szükséges illesztőprogramokat, a qvideo illesztőprogramot és egy információcsere segédprogramkészletet (fájlok átvitele, vágólap). A telepítés és beállítás folyamata részletesen dokumentálva van a projekt webhelyén, ezért megosztjuk tapasztalatainkat.

A fő nehézséget valójában a kidolgozott eszközök támogatásának hiánya jelenti. A kulcsfejlesztők (QWT) nyilvánvalóan nem elérhetők, és a Windows integrációs projekt a vezető fejlesztő felé várakozik. Ezért elsősorban értékelni kellett a működőképességet, és meg kellett érteni lehetőségét, hogy szükség esetén önállóan támogathassuk. A legnehezebben fejleszthető és hibakereshető a grafikus illesztőprogram, amely emulálja a videoadaptert és a kijelzőt a megosztott memória képének megformálásához, lehetővé téve az egész asztal vagy közvetlenül az alkalmazásablak megjelenítését a gazdagépes rendszer ablakában. A vezérlő működésének elemzése során alkalmaztuk a kódot Linux környezetben történő összeállításra és kidolgoztunk egy hibakeresési sémát két vendég Windows rendszer között. A kereszt-összeállítás szakaszában több egyszerűsítő változtatást hajtottunk végre, főként a segédprogramok "csendes" telepítése terén, valamint megszüntettük a zavaró teljesítményromlást a VM hosszú idejű működése alatt. A munka eredményeit külön bemutattuk. tárhelyen, így rövid időre inspirálva a Qubes vezető fejlesztőjét.

A vendég rendszer stabilitása szempontjából a legkritikusabb lépés a Windows indítása, itt látható a jól ismert kék képernyő (vagy akár nem is látható). A legtöbb észlelt hiba esetében különféle megkerülő megoldásokat találtunk — a blokkeszközök Xen illesztőprogramjának elhagyása, a VM memória kiegyenlítésének kikapcsolása, a hálózati beállítások rögzítése és a magok számának minimalizálása. A mi vendégeszköz-összeállításunk teljesen frissített Windows 7-en és Windows 10-en (kivéve a qvideo) települ és működik.

A valós környezetből a virtuálisba való átmenet során probléma merül fel a Windows aktiválásával kapcsolatban, ha előtelepített OEM verziókat használnak. Az ilyen rendszerek az UEFI eszközön megadott licencek alapján történő aktiválást alkalmazzák. Az aktiválás megfelelő működéséhez át kell vinni a gazda rendszer egyik ACPI szegmensét a vendég rendszerbe (SLIC táblázat) és egy kicsit módosítani kell másokat is, megadva a gyártót. A Xen lehetővé teszi az ACPI kiegészítő táblák tartalmának testreszabását, de a fő táblák módosítása nélkül. A megoldásban segített egy hasonló projekt, az OpenXT, amelyet a Qubes-hoz alkalmaztak. A javítások nemcsak nekünk tűntek hasznosnak, hanem átkerültek a Qubes fő tárolójába és a Libvirt könyvtárba is.

A Windows integrációs eszközeinek nyilvánvaló hátrányai közé tartozik a hang, az USB-eszközök támogatásának hiánya, valamint a média kezelése, mivel nincs hardveres GPU támogatás. Azonban ezek nem akadályozzák meg a VM-ek használatát irodai dokumentumokkal való munkához, és nem hátráltatják a specifikus vállalati alkalmazások futtatását.

A Windows VM sablon létrehozása után a hálózat nélküli vagy korlátozott hálózati üzemmódba való átállás követelménye a megfelelő alkalmazás VM konfigurációk létrehozásával teljesült, és a cserélhető meghajtók szelektív csatlakoztatásának lehetősége szintén az operációs rendszer beépített eszközeivel valósult meg – csatlakoztatáskor azok elérhetők a sys-usb rendszer VM-ben, ahonnan "átirányíthatók" a szükséges VM-hez. A felhasználói asztal körülbelül így néz ki.

A rendszer végső változata pozitív fogadtatásra talált a felhasználók körében (amennyire egy ilyen összetett megoldás lehetővé teszi), és a rendszer beépített eszközei lehetővé tették a felhasználói mobil munkahely kiterjesztését VPN-en keresztüli hozzáféréssel.

Összegzésként

A virtualizáció általában csökkenti a frissítés nélküli Windows rendszerek használatának kockázatait – nem kényszerít az új hardverekkel való kompatibilitás biztosítására, lehetővé teszi a rendszerhez való hálózati vagy csatlakoztatott eszközök általi hozzáférés kizárását vagy ellenőrzését, és lehetőséget ad a környezet megvalósítására egy egyszeri indításhoz.

A Qubes OS, amely a virtualizáción keresztüli elszigetelés ötletén alapul, segít ezen és más mechanizmusok használatában a biztonság biztosítása érdekében. Sokak számára a Qubes elsősorban az anonimitás iránti törekvés, de ez egy hasznos rendszer mindazok számára, akik gyakran kombinálnak projekteket, infrastruktúrákat és az azokhoz való hozzáférés titkait, valamint a biztonsági kutatók számára is. Az alkalmazások, adatok elválasztása és kölcsönhatásuk formálása az alapvető lépései a fenyegetések elemzésének és a védelmi rendszer tervezésének. Az ilyen elválasztás segít strukturálni az információt, és csökkenti az emberi tényező által okozott hibák valószínűségét – a sietség, fáradtság stb. miatt.

Jelenleg a fejlesztés fő hangsúlya a Linux környezetek funkcionalitásának bővítésére irányul. A 4.1-es verzió megjelenésére készülünk, amely a Fedora 31-en alapul majd, és tartalmazni fogja a kulcsfontosságú összetevők aktuális verzióit, mint például a Xen és a Libvirt. Érdemes megjegyezni, hogy a Qubes-ot az információbiztonság területén dolgozó szakemberek hozzák létre, akik mindig gyorsan kiadják a frissítéseket új fenyegetések vagy hibák észlelése esetén.

Utószó

Az egyik kísérleti lehetőség, amelyet fejlesztünk, lehetővé teszi olyan virtuális gépek létrehozását, amelyek támogatják a GPU vendég hozzáférést az Intel GVT-g technológia segítségével, így kihasználható a grafikus adapter lehetősége, és jelentősen bővíthető a rendszer alkalmazási területe. A cikk írásakor ez a funkció a Qubes 4.1 tesztverzióira működik, és elérhető itt: github.

Forrás: habr.com