A Habré-ról nem sok cikk foglalkozik a Qubes operációs rendszerrel, és azok, amelyeket láttam, nem írnak le sokat a használat tapasztalatairól. A vágás alatt ezt remélem korrigálni a Qubes mint védelmi eszköz (a Windows-környezet ellen) példájával, és ezzel egyidejűleg megbecsülni a rendszer oroszul beszélő felhasználóinak számát.
Miért Qubes?
A Windows 7 technikai támogatásának megszűnésének története és a felhasználók növekvő szorongása miatt meg kellett szervezni az operációs rendszer munkáját, figyelembe véve a következő követelményeket:
- biztosítsa a teljesen aktivált Windows 7 használatát azzal a lehetőséggel, hogy a felhasználó frissítéseket és különféle alkalmazásokat telepítsen (beleértve az interneten keresztül is);
- a hálózati interakciók teljes vagy szelektív kizárása a feltételek alapján (autonóm működés és forgalomszűrési módok);
- lehetővé teszi a cserélhető adathordozók és eszközök szelektív csatlakoztatását.
Ez a korlátozáskészlet egyértelműen felkészült felhasználót feltételez, hiszen megengedett a független adminisztráció, és a korlátozások nem az esetleges cselekvéseinek blokkolására, hanem az esetleges hibák vagy destruktív szoftverhatások kizárására vonatkoznak. Azok. A modellben nincs belső bűnöző.
A megoldás keresése során gyorsan elvettük a korlátozások bevezetésének gondolatát a beépített vagy további Windows-eszközökkel, mivel meglehetősen nehéz hatékonyan korlátozni a rendszergazdai jogosultságokkal rendelkező felhasználót, így lehetősége nyílik az alkalmazások telepítésére.
A következő megoldás a virtualizáció segítségével történő izolálás volt. A jól ismert asztali virtualizációs eszközök (például a virtualbox) nem alkalmasak biztonsági problémák megoldására, és a felsorolt korlátozásokat a felhasználónak kell végrehajtania a vendég virtuális gép (a továbbiakban: mint VM), ami növeli a hibák kockázatát.
Ugyanakkor volt tapasztalatunk a Qubes felhasználói asztali rendszerként való használatában, de kételkedtünk a vendég Windows rendszerrel való munka stabilitását illetően. A Qubes jelenlegi verziójának ellenőrzése mellett döntöttek, mivel a megfogalmazott korlátok nagyon jól illeszkednek a rendszer paradigmájába, különösen a virtuálisgép-sablonok megvalósítása és a vizuális integráció. A továbbiakban megpróbálok röviden beszélni a Qubes ötleteiről, eszközeiről, a problémamegoldás példáján keresztül.
A Xen virtualizáció típusai
A Qubes a Xen hypervisoron alapul, amely minimalizálja a processzor erőforrások, a memória és a virtuális gépek kezelésének funkcióit. Minden egyéb, az eszközökkel végzett munka a Linux kernelen alapuló dom0-ban összpontosul (a Qubes for dom0 a Fedora disztribúciót használja).
A Xen többféle virtualizációt támogat (Példákat mondok az Intel architektúrára, bár a Xen másokat is támogat):
- paravirtualizáció (PV) - hardveres támogatást nem igénylő virtualizációs mód, amely a konténervirtualizációra emlékeztet, adaptált kernellel rendelkező rendszerekhez használható (a dom0 ebben a módban működik);
- teljes virtualizáció (HVM) - ebben a módban a processzorerőforrásokhoz hardveres támogatást használnak, az összes többi berendezést pedig a QEMU segítségével emulálják. Ez a leguniverzálisabb módja a különféle operációs rendszerek futtatásának;
- hardver paravirtualizálása (PVH - ParaVirtualized Hardware) - hardvertámogatást használó virtualizációs mód, amikor a hardverrel való együttműködéshez a vendégrendszermag a hipervizor képességeihez igazított illesztőprogramokat (például megosztott memória) használ, így nincs szükség QEMU emulációra. és az I/O teljesítmény növelése. A 4.11-től kezdődő Linux kernel működhet ebben a módban.
A Qubes 4.0-s verziójától kezdődően biztonsági okokból a paravirtualizációs mód használata megszűnt (többek között az Intel architektúra ismert sérülékenységei miatt, amelyeket részben enyhít a teljes virtualizáció használata); alapértelmezés szerint a PVH mód használatos.
Emuláció (HVM mód) használatakor a QEMU egy izolált virtuális gépben, úgynevezett stubdomainben indul el, ezáltal csökkentve a potenciális hibák kihasználásának kockázatát a megvalósításban (a QEMU projekt sok kódot tartalmaz, beleértve a kompatibilitást is).
Esetünkben ezt a módot kell használni a Windows számára.
Virtuális gépek kiszolgálása
A Qubes biztonsági architektúrában a hypervisor egyik kulcsfontosságú képessége a PCI-eszközök átvitele a vendégkörnyezetbe. A hardveres kizárás lehetővé teszi a rendszer gazdagép részének elkülönítését a külső támadásoktól. A Xen ezt támogatja a PV és HVM módokhoz, a második esetben az IOMMU (Intel VT-d) támogatása szükséges - hardveres memóriakezelés virtualizált eszközökhöz.
Ez több rendszer virtuális gépet hoz létre:
- sys-net, amelyre hálózati eszközöket továbbítanak, és amely hídként szolgál más virtuális gépekhez, például olyanokhoz, amelyek tűzfal vagy VPN-kliens funkcióit valósítják meg;
- sys-usb, amelyre az USB és más perifériavezérlők átvitele történik;
- sys-firewall, amely nem használ eszközöket, de tűzfalként működik a csatlakoztatott virtuális gépek számára.
Az USB-eszközökkel való munkavégzéshez proxyszolgáltatásokat használnak, amelyek többek között a következőket nyújtják:
- a HID (human interface device) eszközosztályhoz parancsok küldése a dom0-nak;
- cserélhető adathordozók esetén az eszközkötetek átirányítása más virtuális gépekre (a dom0 kivételével);
- közvetlen átirányítás USB-eszközre (USBIP és integrációs eszközök használatával).
Egy ilyen konfigurációban a sikeres támadás a hálózati veremen vagy a csatlakoztatott eszközökön keresztül csak a futó szolgáltatási virtuális gép kompromittálásához vezethet, nem pedig a teljes rendszer egészéhez. A szolgáltatási virtuális gép újraindítása után pedig az eredeti állapotában töltődik be.
VM integrációs eszközök
Számos módja van a virtuális gép asztalával való interakciónak – alkalmazások telepítése a vendégrendszerbe vagy videó emuláció virtualizációs eszközök segítségével. A vendégalkalmazások lehetnek különféle univerzális távoli elérési eszközök (RDP, VNC, Spice stb.), vagy egy adott hipervizorhoz adaptálhatók (az ilyen eszközöket általában vendég segédprogramoknak nevezik). Vegyes opció is használható, ha a hypervisor emulálja az I/O-t a vendégrendszer számára, és külsőleg lehetőséget biztosít olyan protokoll használatára, amely egyesíti az I/O-t, például, mint a Spice. Ugyanakkor a távelérési eszközök általában optimalizálják a képet, mivel hálózaton keresztüli munkát jelentenek, ami nincs pozitív hatással a kép minőségére.
A Qubes saját eszközöket biztosít a virtuális gépek integrációjához. Először is, ez egy grafikus alrendszer - a különböző virtuális gépekről származó ablakok egyetlen asztalon jelennek meg, saját színkerettel. Az integrációs eszközök általában a hypervisor képességein alapulnak - megosztott memória (Xen engedélyezési tábla), értesítési eszközök (Xen eseménycsatorna), megosztott tárolási xenstore és vchan kommunikációs protokoll. Segítségükkel megvalósulnak a qrexec és qubes-rpc alapkomponensek, valamint az alkalmazásszolgáltatások - audio vagy USB átirányítás, fájlok vagy vágólap tartalmának átvitele, parancsok végrehajtása és alkalmazások indítása. Lehetőség van olyan házirendek beállítására, amelyek lehetővé teszik a virtuális gépeken elérhető szolgáltatások korlátozását. Az alábbi ábra egy példa a két virtuális gép interakciójának inicializálására szolgáló eljárásra.
Így a virtuális gépben végzett munka hálózat használata nélkül történik, ami lehetővé teszi az autonóm virtuális gépek teljes körű használatát az információszivárgás elkerülése érdekében. Például így valósul meg a kriptográfiai műveletek szétválasztása (PGP/SSH), amikor a magánkulcsokat elszigetelt virtuális gépekben használják, és nem lépik túl azokat.
Sablonok, alkalmazások és egyszeri virtuális gépek
A Qubes-ban végzett összes felhasználói munka virtuális gépeken történik. Ezek vezérlésére és megjelenítésére a fő gazdagép rendszer szolgál. Az operációs rendszert a sablonalapú virtuális gépek (TemplateVM) alapkészletével együtt telepítik. Ez a sablon egy Fedora vagy Debian disztribúción alapuló Linux virtuális gép, telepített és konfigurált integrációs eszközökkel, valamint dedikált rendszer- és felhasználói partíciókkal. A szoftverek telepítését és frissítését egy szabványos csomagkezelő (dnf vagy apt) végzi a kötelező digitális aláírás-ellenőrzéssel (GnuPG) konfigurált tárolókból. Az ilyen virtuális gépek célja az alapjukon elindított alkalmazási virtuális gépekbe vetett bizalom biztosítása.
Indításkor az alkalmazás virtuális gépe (AppVM) a megfelelő virtuálisgép-sablon rendszerpartíciójának pillanatképét használja, és a befejezés után a módosítások mentése nélkül törli ezt a pillanatképet. A felhasználó által igényelt adatokat a rendszer egy felhasználói partíción tárolja, amely minden egyes alkalmazás-VM-hez egyedi, és amely a kezdőkönyvtárba van beillesztve.
Az eldobható virtuális gépek (disposableVM) használata biztonsági szempontból hasznos lehet. Az ilyen virtuális gépet az indításkor sablon alapján hozzák létre, és egyetlen célból indítják el - egy alkalmazás végrehajtására, a munka befejezésére a bezárás után. Az eldobható virtuális gépek olyan gyanús fájlok megnyitására használhatók, amelyek tartalma bizonyos alkalmazási sebezhetőségek kihasználásához vezethet. Az egyszeri virtuális gép futtatásának képessége be van építve a fájlkezelőbe (Nautilus) és az e-mail kliensbe (Thunderbird).
A Windows virtuális gép sablon és egyszeri virtuális gép létrehozására is használható, ha a felhasználói profilt egy külön szakaszba helyezi át. A mi verziónkban egy ilyen sablont használ a felhasználó az adminisztrációs feladatokhoz és az alkalmazások telepítéséhez. A sablon alapján több alkalmazási virtuális gép készül - korlátozott hozzáféréssel a hálózathoz (standard sys-tűzfal képességek), és egyáltalán nem lesz hozzáférése a hálózathoz (virtuális hálózati eszköz nem jön létre). A sablonban telepített összes változtatás és alkalmazás elérhető lesz ezeken a virtuális gépeken, és még ha könyvjelzőprogramokat is bevezetnek, nem lesz hálózati hozzáférésük a kompromisszum miatt.
Harcolj a Windowsért
A fent leírt funkciók a Qubes alapját képezik, és meglehetősen stabilan működnek, a nehézségek a Windows-nál kezdődnek. A Windows integrálásához a Qubes Windows Tools (QWT) vendégeszköz-készletet kell használnia, amely tartalmazza a Xen-nel való munkavégzéshez szükséges illesztőprogramokat, egy qvideo illesztőprogramot és egy sor segédprogramot az információcseréhez (fájlátvitel, vágólap). A telepítési és konfigurálási folyamatot részletesen dokumentáljuk a projekt honlapján, így megosztjuk egymással az alkalmazási tapasztalatainkat.
A fő nehézség lényegében a kifejlesztett eszközök támogatásának hiánya. Úgy tűnik, hogy a Key Developers (QWT) nem érhető el, és a Windows integrációs projekt vezető fejlesztőre vár. Ezért mindenekelőtt fel kellett mérni a teljesítményét, és megértetni kell az önálló támogatás lehetőségével, ha szükséges. A legnehezebben fejleszthető és hibakereső a grafikus illesztőprogram, amely a videoadapter és a kijelző emulációjával hoz létre képet az osztott memóriában, lehetővé téve, hogy a teljes asztalt vagy az alkalmazás ablakát közvetlenül a gazdarendszer ablakában jelenítse meg. A meghajtó működésének elemzése során a kódot Linux környezetben való összeállításhoz adaptáltuk, és kidolgoztunk egy hibakeresési sémát két Windows vendégrendszer között. A crossbuild szakaszban több olyan változtatást hajtottunk végre, amelyek leegyszerűsítették számunkra a dolgokat, főként a közművek „csendes” telepítése terén, valamint kiküszöböltük a hosszú ideig tartó virtuális gépben végzett munka során bosszantó teljesítményromlást. A munka eredményeit külön bemutattuk , tehát nem sokáig Vezető Qubes fejlesztő.
A vendégrendszer stabilitása szempontjából a legkritikusabb szakasz a Windows indítása, itt látható (vagy nem is) az ismerős kék képernyő. A legtöbb azonosított hiba esetében különféle megoldások léteztek – a Xen blokk eszközillesztőinek eltávolítása, a virtuális gépek memóriakiegyenlítésének letiltása, a hálózati beállítások javítása és a magok számának minimalizálása. Vendégeszközeink teljesen frissített Windows 7 és Windows 10 rendszereken telepítenek és futnak (kivéve a qvideot).
Valós környezetből virtuális környezetbe való áttéréskor probléma adódik a Windows aktiválásával, ha előre telepített OEM-verziókat használnak. Az ilyen rendszerek az eszköz UEFI-jében megadott licencek alapján aktiválják. Az aktiválás helyes feldolgozásához le kell fordítani a gazdarendszer teljes ACPI szakaszának egyikét (SLIC tábla) a vendégrendszerre, és kissé módosítani kell a többit, regisztrálva a gyártót. A Xen lehetővé teszi a további táblák ACPI-tartalmának testreszabását, de a főbb táblák módosítása nélkül. A megoldásban egy hasonló OpenXT projektből származó, Qubes-ra adaptált patch segített. A javítások nemcsak nekünk tűntek hasznosnak, hanem lefordították őket a fő Qubes-tárba és a Libvirt könyvtárba.
A Windows integrációs eszközeinek nyilvánvaló hátrányai közé tartozik az audio- és USB-eszközök támogatásának hiánya, valamint a médiával való munka bonyolultsága, mivel a GPU-hoz nincs hardver támogatás. De a fentiek nem akadályozzák meg a virtuális gép használatát az irodai dokumentumokkal való munkavégzéshez, és nem akadályozzák meg konkrét vállalati alkalmazások elindítását sem.
A Windows VM-sablon létrehozása után a hálózat nélküli vagy korlátozott hálózattal működő üzemmódra váltás követelménye az alkalmazási virtuális gépek megfelelő konfigurációinak elkészítésével teljesült, és a cserélhető adathordozók szelektív csatlakoztatásának lehetőségét is megoldották a szabványos operációs rendszer eszközei - csatlakozáskor , a rendszer VM sys-usb-ben érhetők el, ahonnan "tovább lehet küldeni" a szükséges virtuális gépre. A felhasználó asztala valahogy így néz ki.
A rendszer végleges verzióját pozitívan fogadták (amennyire ezt az átfogó megoldás lehetővé teszi) a felhasználók, és a rendszer standard eszközei lehetővé tették az alkalmazás kiterjesztését a felhasználó mobil munkaállomására VPN-en keresztül.
Ahelyett, hogy egy következtetés
A virtualizáció általában lehetővé teszi a támogatás nélkül maradt Windows rendszerek használatának kockázatának csökkentését - nem kényszeríti ki az új hardverrel való kompatibilitást, lehetővé teszi a rendszerhez való hozzáférés kizárását vagy ellenőrzését a hálózaton vagy a csatlakoztatott eszközökön keresztül, valamint egyszeri indítási környezet megvalósítása.
A virtualizáción keresztüli elkülönítés ötlete alapján a Qubes OS segít ezeknek és más biztonsági mechanizmusoknak a kihasználásában. Kívülről sokan elsősorban az anonimitás vágyának tekintik a Qubest, de hasznos rendszer mind a mérnököknek, akik gyakran projektekkel, infrastruktúrákkal, titkokkal zsonglőrködnek, hogy hozzáférjenek azokhoz, mind pedig a biztonsági kutatóknak. Az alkalmazások, adatok szétválasztása és interakciójuk formalizálása a fenyegetéselemzés és a biztonsági rendszer tervezésének kezdeti lépései. Ez a szétválasztás segít strukturálni az információkat, és csökkenti az emberi tényező – kapkodás, fáradtság stb. – miatti hibák valószínűségét.
Jelenleg a fejlesztés során a fő hangsúly a Linux környezetek funkcionalitásának bővítésén van. A 4.1-es verzió kiadásra készül, amely a Fedora 31-en fog alapulni, és tartalmazza a Xen és a Libvirt kulcskomponensek jelenlegi verzióit. Érdemes megjegyezni, hogy a Qubes-t információbiztonsági szakemberek hozzák létre, akik mindig azonnal kiadják a frissítéseket, ha új fenyegetéseket vagy hibákat észlelnek.
utószó
Az egyik fejlesztés alatt álló kísérleti lehetőség lehetővé teszi, hogy az Intel GVT-g technológián alapuló GPU-hoz vendég hozzáférést támogató virtuális gépeket készítsünk, ami lehetővé teszi a grafikus adapter képességeinek kihasználását és a rendszer hatókörének jelentős bővítését. A cikk írásakor ez a funkció a Qubes 4.1 tesztverzióihoz működik, és a következőn érhető el .
Forrás: will.com