A hamarosan megjelenő 2.0 kiadás annyi újdonságot tartalmaz, hogy azok taglalása helyett inkább egy összefoglaló jellegű cikk megírása mellett döntöttem, így aki most olvas erről megoldásról először, annak sem kell ‘feleslegesen’ a régi cikkeket is átolvasnia ahhoz hogy képbe kerüljön a Qubes által nyújtott remek lehetőségek összességével. Az is emellett szól, hogy tulajdonképpen ezek már mind dokumentálva vannak a projekt saját wiki oldalán és/vagy a fejlesztők blogján.
A Qubes projekt célja
Az első és legfontosabb információ a projekttel kapcsolatban, hogy egyáltalán miért jött létre, mit szeretne megvalósítani. A cél nagyon röviden: egy biztonságos Desktop Operációs Rendszer megalkotása. Ennek megértésben – a már több cikkemben is linkelt – rövid prezentáció segíthet: Qubes-meetup
Felmerülhet a kérdés, hogy miben különbözik ez, a többi egyéb hasonló célt szolgáló megoldástól? Erre ad választ a projekt alapítója – egy blog bejegyzés formájában.
Az egyéb kérdéseket a Gyakran Ismételt Kérdések szekció igyekszik megválaszolni.
A Qubes OS felépítése
„Security by Isolation„
A fenti ábra jól szemlélteti a Qubes OS felépítését, aminek alapvető eleme a Xen hypervisor, ami egy biztonságos Type-1 (Bare-metal) virtualizációs réteget biztosít. Ennek segítségével külön-külön virtuális gépek formájában valósítja meg az elkülönítést a rendszer kritikus elemei és az alkalmazásokat futtató AppVM-ek között. Mindezt úgy, hogy közben a különböző AppVM-ben futó alkalmazások ugyan azon a képernyőn jelenjenek meg, sőt lehetőség van egymás közötti biztonságos adatátvitelre is.
Természetesen, ilyen szintű szeparáció biztonságos megvalósításához hardver szintű támogatás is szükséges. A rendszer futtatásához szükséges konkrét hardver követelmények megtalálhatóak a projekt wiki oldalán. Sőt, a fejlesztők és a felhasználók által tesztelt konkrét eszközökkel kapcsolatban a HCL nyújthat további segítséget.
Bare-metal (Type-1) hypervisor
Ahogy ezt már többször is igyekeztem kihangsúlyozni, a rendszer legfontosabb eleme – a virtualizációt és ennek segítségével a szeparációt biztosító hypervisor – esetünkben a Xen.
Hardver szintű támogatással elkülönített rendszer komponensek:
- dom0
A Xen hypervisor ugyan nem egy másik operációs rendszeren belül fut, de szüksége van eszközmeghajtókra (driver), management szoftverekre, és grafikus felületre is. Ezeket biztosítja a dom0 operációs rendszere, ami a Qubes OS 2.0 esetében egy – kifejezetten erre a feladatra specializált – Fedora 20 disztribúció 3.12 verziójú kernellel.
A Qubes OS esetében extra biztonsági fícsör, hogy a dom0 nem rendelkezik közvetlen hálózati összeköttetéssel!
- Network
A Qubes egyik legfontosabb – a fenti ábrán is jól szemléltetett – biztonsági megoldása, a hálózati eszközök elkülönítése a dom0, illetve az AppVM-ektől. Ezt a Xen hypervisor egyik remek lehetősége, a PCI Passtrough biztosítja. A megoldás lényege, hogy a fizikai hálózati eszközeinket egy kifejezetten erre a feladatra tervezett virtuális gép típushoz – egy NetVM-hez csatoljuk. Így hatékonyan elszeparálhatjuk a külső hálózatokkal közvetlen kapcsolatot tartó eszközöket (és az ehhez szükséges drivereket) az érzékeny adatokat tartalmazó alkalmazásainktól, és az egész rendszert vezérlő dom0-tól egyaránt.
Template alapú virtuális gépek
Mivel sok virtuális gépet fogunk futtatni, elengedhetetlen fícsör, hogy ezeket ne kelljen külön-külön egyesével frissíteni, karbantartani. Ez a gyakorlatban azt jelenti, hogy a virtuális gépek egy read-only template (itt találhatóak a telepített alkalmazások, és a rendszer szintű beállítások) és egy read-write lehetőséggel bíró virtuális diszket (amin a home könyvtárunk és a VM-enként eltérő konfigurációs állományok találhatóak) is kapnak, ezek összessége adja a virtuális gép teljes file struktúráját.
Ennek technikai megvalósításáról a projekt wiki oldalán találunk bővebb informáviókat.
Ez a megoldás a következő előnyöket biztosítja:
- nagyságrendekkel kisebb diszk igény,
- csak egy helyen kell az alkalmazásokat telepíteni/frissíteni,
- csak egyszer kell a globális (minden VM-re érvényes) beállításokat elvégezni,
- ‘elronthatatlan’ bináris készlet – ideiglenesen ugyan felülírhatjuk a template-ből kapott álloományokat is, ám azok egy reboot után visszaállnak az eredeti állapotra.
Természetesen ennek a megoldásnak ugyan úgy vannak hátrányai is, legfőképp a megnövekedett diszk I/O igény – mivel minden VM ugyan azt a diszk területet akarja egyszerre olvasgatni. Erre azonban a ma már igen elterjedt SSD technológia remek megoldást nyújt. Éppen ezért erősen javasolt is, a hagyományos HDD-kel szemben.
A Qubes OS ‘gyárilag’ egyetlen template-et tartalmaz, ami egy standard Fedora 20 kiadás – Qubes specifikus csomagokkal kiegészítve. Azonban a lehetőség adott, bárki készíthet egyéb más operációs rendszerekre épülő template-eket is, köszönhetően a template builder-nek. Ennek segítségével készül már ArchLinux és Debian template is a közösség tagjai által.
Amellett, hogy a template alapú VM-ek használata a gyakorlatban nagyon hasznos, természetesen lehetőség van Standalone VM-ek létrehozására is.
Különböző típusú virtuális gépek futtatásának lehetősége:
- NetVM
Ez egy speciális feladatot ellátó virtuális gép típus, ez biztosít összeköttetést a fizikai hálózatok és az alkalmazásainkat futtató AppVM-ek között. Legalább egy ilyen típusú VM kell hogy legyen a rendszerünkben. Default telepítés esetén egy ilyen VM jön létre, és ehhez lesz hozzárendelve a gépünkben található összes hálózati eszköz, de természetesen ennél jóval bonyolultabb rendszert is kialakíthatunk, ha a különböző eszközöket (Ethernet, WiFi, 3G) külön-külön NetVM-ekhez rendeljük.
- ProxyVM
A Proxy (vagy Firewall) típusú virtuális gépeket az AppVM-ek és a NetVM(ek) közé csatlakoztatva, még tovább szeparálhatjuk – ezzel még biztonságosabbá téve – a belső virtuális hálózatunkat.
Default telepítés esetén egy ilyen VM jön létre. A gyakorlatban azonban magam is több ProxyVM-et: hasnálok: TOR, VPN, vagy épp az AppVM-ek egymás közötti kommunikációjának engedélyezésére.
- AppVM
Felhasználói szemszögből ez a fajta VM tartalmazza a lényeget: az alkalmazásokat, amiket használni szeretnénk :) Hogy kinek mennyi kell ezekből, az már a felhasználás módjától és a tevékenységeink sokszínűségétől (és biztonsági vonzataitól) függ. Természetesen minél több AppVM fut, annál több erőforrást is igényel, tehát a rendelkezésünkre álló hardver figyelembe vételével tervezzük meg, hogy mennyire szeretnénk darabokra szeparálni a digitális életünket.
- HVM
Az eddig vázolt VM-ek mind PV – vagyis paravirtualizát környezetben futnak, aminek legfőbb tulajdonsága, hogy az operációs rendszernek erről tudnia kell, azaz egy módosított kernelre van szükség az ilyen környezetben való futáshoz. Ezzel szemben a HVM – vagy ‘Full Virtualization – környezetben módosítás nélkül futtathatunk szinte bármilyen operációs rendszert, így lehetőség van olyan operációs rendszerek futtatására is, amik kernelét nem tudjuk/akarjuk módosítani a PV környezethez. Ilyen például a Windows is.
Ilyen típusú VM esetén lehetséges nem template alapú – azaz Standalone VM-eket is létrehozni.
DVM – Disposable VM
Az eldobható – azaz egyszer használatos – VM-ek segítségével még tovább tudjuk csökkenteni az internetről ránk áradó támadások, vírusok, és egyéb gonosz dolgok káros hatásait. Ez a VM ugyanis a kikapcsolás után végleg megszűnik létezni – az esetleg összeszedett károkozókkal együtt :)
Ez a megoldás kiválóan alkalmas ismeretlen eredetű, vagy akár tudottan ártó jellegű weboldalak felkeresésére, fájlok letöltésére, vírusok ‘tesztelésére’. Mindemellett magánéleti (privacy) szempontból kényes ügyek intézésére is remek megoldás, főleg egy ProxyVM-ben futó TOR megoldással kiegészítve.
Ezek használatát nagyban megkönnyíti a File kezelőhöz, Evolution-höz. és Firefox-hoz is elérhető plugin, aminek segítségével egy normál AppVM-ből is egyetlen kattintással nyithatunk meg állományokat, weboldalakat egy újonnan indított DVM-ben.
Grafikus VM kezelőfelület
A mára már alapvetőnek számító Qubes VM Manager az 1.0 kiadásban debütált, és mivel azóta csak apróbb változtatásokon esett át, így ezt nem részletezném újra.
Seamless GUI Integration
Mivel ezt a kifejezést igen nehéz lefordítani, igyekszem elmagyarázni miről is van szó. Nehéz dolog ez azért is, mert a végeredménynek pont az a lényege, hogy a felhasználó számára egyértelmű legyen, hogy melyik alkalmazás melyik VM-ben fut, ám ez mégse jelentsen korlátokat a használhatóságban. Ez a gyakorlatban azt jelenti, hogy minden egyes alkalmazás egy színes ablakkeretet kap. Ez az ablakkeret a színével és az alkalmazást futtató VM nevével van ellátva, de ettől függetlenül ugyan azon a desktop felületen láthatjuk őket, sőt akár copy-paste műveletet is végezhetünk a közöttük, attól függetlenül, hogy valójában külön VM-ben futnak. Persze mindezt látni kell, és máris egyértelmű miről is beszélek :)
Technikai részletek a projekt wiki oldalán
Biztonságos adatátviteli lehetőségek a VM-ek között:
Segítségével lehetőségünk van biztonságos módon állományokat mozgatni anélkül, hogy bármilyen közös eszközt kellene felcsatolnunk az érintett VM-ekben.
A „Seamless GUI Integration” egyik lényeges eleme, hogy Copy-Paste műveleteket is végezhetünk a különböző VM-ek között.
- Trusted PDF
Egy olyan remek megoldás is született, ami a .pdf állományokat egy eldobható VM-ben egy sokkal megbízhatóbb (makrók, scriptek, és egyéb veszélyforrások nélküli) formátumba konvertálja.
Minden AppVM egy belső virtuális hálózat része. Hogy ezek a virtuális gépek hogyan kapcsolódhassan egymáshoz – majd végül a fizikai hálózathoz – azt a qubes firewall szabályozza.
Backup & Restore
Nem, a biztonsági mentések fontosságát nem szeretném szajkózni.Úgyis mindeki csak egy őt is érintő adatvesztés után kezd el rendszeres mentéseket készíteni, és általában ez is csak addig tart, amíg az ezzel kapcsolatos rossz emlékek.
A Qubes mindenesetre lehetőséget biztosít a rendszerünk egyszerű és biztonságos mentésére és visszaállítására egyaránt. Itt azért kihangsúlyoznám a működő visszaállítást. A Qubes tesztelése során ugyanis ez a fícsör adta a lehetőséget arra, hogy különösebb probléma (és adatvesztés) nélkül lehessen frissíteni, vagy akár egy régebbi állapotra visszaállni. Az egyéb operációs rendszerek és mentéseikkel kapcsolatban eddig sajnos nem voltak ilyen pozitív tapasztalataim…
Anti Evil Maid
Ez egyfajta TPM implementáció, aminek elsődleges célja az ‘Evil Maid’ tipusú támadások megakadályozása. Bővebb információk a projet wiki oldalán.
Single User Mode – by design
Ez első hallásra ugyan sokkal inkáb hiányosságként lehetne értelmezni, ám aki a dom0-hoz hozzáfér, az az összes VM felett korlátlan jogokkal rendelkezik. Emiatt a jelenlegi megoldásokkal nem biztosítható a felhasználók jogainak elkülönítése a dom0-ban. Tehát a Qubes OS csak egyetlen felhasználót feltételez. – ami egy laptop esetében nem is túl elvonatkoztatott dolog.