Használj még több egérgombot!
A „sokgombos” egerek manapság már egyáltalán nem számítanak különlegességnek, azonban az ezekben rejlő lehetőségeket szinte alig használjuk ki.
A „sokgombos” egerek manapság már egyáltalán nem számítanak különlegességnek, azonban az ezekben rejlő lehetőségeket szinte alig használjuk ki.
A Qubes OS egyik remek tulajdonsága, hogy különböző típusú VM-eket lehet benne használni, köztük az egyik legérdekesebb a ProxyVM.
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.
Az alábbi ismertető a Qubes OS aktuálisan elérhető legfrissebb stabil – vagy az általam már használhatónak ítélt – verziójáról szól, ami jelenleg a:
„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 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.
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.
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 esetében egy – kifejezetten erre a feladatra specializált – Fedora 25 alapokra építkező disztribúció.
A Qubes OS esetében extra biztonsági fícsör, hogy a dom0 nem rendelkezik közvetlen hálózati összeköttetéssel! Így a gyorsan elavuló Fedora 25 sem jelent biztonsági problémát, a hardvertámogatásért felelős komponenseket (Kernel, Xorg) pedig rendszeresen backportolják a fejlesztők.
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.
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 oldalán találunk bővebb informáviókat.
Ez a megoldás a következő előnyöket biztosítja:
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’ a következő template-ek használatát támogatja:
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 több – a közösség által támogatott – megoldás is:
Amellett, hogy a template alapú VM-ek használata a gyakorlatban nagyon hasznos, természetesen lehetőség van egymástól teljesen független (Standalone) VM-ek létrehozására is.
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. Alapértelmezett telepítés esetén egy ilyen VM (sys-net) 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.
Ez szintén egy speciális feladatot ellátó virtuális (sys-usb) gép, amihez alapértelmezetten a gépünkben található összes USB támogatásért felelős PCI eszköz hozzá van rendelve. Itt került implementálásra az első USB proxy szolgáltatás is, ami az USB alapú beviteli eszközök biztonságos használatát teszi lehetővé.
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.
Alapértelmezett telepítés esetén egy ilyen VM (sys-firewall) jön létre. A gyakorlatban azonban magam is több ProxyVM-et: használok: Whonix (TOR), VPN, vagy épp az AppVM-ek egymás közötti kommunikációjának engedélyezésére.
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 figyelembevételével tervezzük meg, hogy mennyire szeretnénk darabokra szeparálni a digitális életünket.
Az eddig vázolt VM-ek mind PHV – 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 PHV 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.
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/Whonix megoldással kiegészítve.
Ez a VM mindenképpen egy PHV alapú, speciális template-re épülő megoldás, amiből akár több példány is futhat egyszerre, és készíthetünk akár többféle különböző template-et is. Ezeket a többi VM-től függetlenül testreszabhatjuk.
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.
A mára már alapvetőnek számító Qube 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.
Alternatívaként természetesen ott vannak a kezdetektől létező CLI parancsok, és az akár automatizálást is lehetővé tevő SaltStack.
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 oldalán
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.
Minden AppVM egy belső virtuális hálózat része. Hogy ezek a virtuális gépek pontosan mit érhessenek el, azt a qubes firewall szabályozza.
Nem, a biztonsági mentések fontosságát nem szeretném szajkózni.Úgyis mindenki 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…
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 oldalán.
Ez első hallásra ugyan sokkal inkább 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.
Természetesen, az itt leírtak csak a főbb tulajdonságokat taglalják. A projekt teljes dokumentációja ennél lényegesen bővebb információkat tartalmaz.
A Qubes OS egyik remek megoldása, hogy különböző típusú VM-eket lehet benne használni, köztük az egyik legérdekesebb a ProxyVM (vagy FirewallVM).
Október 1-én megjelent a Qubes OS legújabb, 3.0 verziószámot viselő kiadása, amelyet a fejlesztői csapat Caspar Bowden emlékének ajánlja.
Oldalaim nagyon lassan ugyan, de végül egy teljes átalakításon estek át. Mindez persze nagyrészt a háttérben történt, kívülről remélhetőleg csak az tűnt fel, hogy régóta nem jelent meg friss írás/kép az oldalakon.
Noha maga a WordPress már jó ideje kérdés – és beavatkozás – nélkül frissíti önmagát, ettől még bőven akad teendő egy WordPress oldal üzemeltetése kapcsán.
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.