Qubes – Beta3

Egy korábbi cikkben írtam arról az elvetemült igényemről, hogy egy biztonságos desktop operációs rendszert szeretnék használni, ahol nem keverednek a céges adataim/alkalmazásaim a priváttal, és legfőképp nem a szórakozásra használtakkal…

Úgy tűnik, az egyetlen projekt, ami pontosan ezt tűzte ki célul: a Qubes OS.

A projekt fejlődését régóta nyomon követem, tartottam is már erről egy rövid előadást az az egyik Budapest New Tech Meetup rendezvény keretében, íme az akkori előadásom anyaga, amiből egy gyors, de átfogó képet kaphatunk az alap problémáról, és annak lehetséges megoldásairól.

Most, hogy a projekt az utolsó tesztelési fázisában tart, nézzük milyen lehetőségeket biztosít mindez számunkra a gyakorlatban…

A megoldás

Ahogy a bevezető cikkből, és a rövid előadásomból is kiderülhetett az egyetlen – a gyakorlatban is működő – megoldás: a szeparáció.

A szeparáció alapját ezen projekt esetében is a Xen hypervisor jelenti, ami egy Type1 típusú – azaz közvetlenül a hardveren futó – virtualizációs megoldást biztosít számunkra.

Szemben a Citrix hasonló megoldásával, itt valóban a biztonság a legfontosabb szempont, amihez alapvető elvárás, hogy a Dom0-ban egyáltalán ne legyen hálózatkezelés. Ez ugyanis a rendszer ‘lelke’ – azaz aki ehhez hozzáfér, az teljes jogokkal rendelkezhet az operációs rendszerünk felett, a rajta lévő összes virtuális géppel együtt!

Használatba vétel

Az elmélet szép és jó, át mit sem ér mindez, ha csak beszélünk róla ;) Vegyük hát használatba, és nézzük mit is kapunk valójában:

Tervezés

Igen, ez fontos!

Létezik ugyanis ‘nex-next-finish’ jellegű telepítés is, de így az egésznek semmi értelme nem lesz. Ez ugyanis nem egy windows, hogy sikeresen feltelepítjük, aztán nézzünk körül mi hol van, és irány a fészbúk…

De mégis mit is kellene tervezni??

Ha erre a kérdésre még nem tudod a választ, akkor biztosan nem olvastad el a bevezető cikket, és a  Qubes-ról szóló rövid előadás anyagomat ;)

Tehát, azt szeretnénk, hogy a különböző biztonsági szinten lévő alkalmazásainkat külön-külön, egymástól független környezetben futtathassuk. Persze ne essünk túlzásba – mert a jelenlegi hardverünk azt biztosan nem fogja tolerálni. Jelenleg túlzás (azon felül, hogy egyelőre technikailag sem megoldható) az az igény, hogy minden alkalmazás külön VM-ben fusson… Az pedig kevés, amit egy jelenlegi átlagos operációs rendszer biztosíthat számunkra…

Akkor hol is az arany középút??

Hát, valahol a kettő között ;)

App VM-ek

Ezek az általunk valójában használt virtuális gépek, és ezekben fognak futni a böngészőink, a levelező klienseink, a szövegszerkesztő, és bármi egyéb alkalmazás amit csak használni szeretnénk…

Tehát, ezekből annyi kell, ahány féle dologra használjuk őket. A lényeg a biztonság, tehát  a céges oldalainkhoz a böngészőben ‘megjegyzett’ jelszavaink semmiképp se kerüljenek ki egyéb (nem céges) oldalakra. Így biztosan kell egy céges VM…

A privát adataink (gmail, facebook, blogok, fórumok) már nem olyan kritikusak (vagyis inkább más okból kritikusak) de ezeket sem szeretnénk az átlagos – egyszer látogatott – ismeretlen oldalak számára hozzáférhetővé tenni. Ezért praktikus egy privát célra fenntartott VM-is…

Egyéb, kevésbé fontos weboldalakat lehet hogy egészen más böngésző, (levelező vagy akármi) beállításokkal szeretnénk használni… ezek számára szintén praktikus egy külön VM…

Vannak ezen kívül a teljesen ‘megbízhatatlan’ oldalak – nem is hoznék példákat, biztosan mindenki látott már ilyen-olyan jellegű oldalt, amiről nem tudta (vagy nem is érdekelte) hogy ki üzemelteti ;) De ha ilyet nem is, gyanús levél csatolmányokat biztosan mindenki látott már… Az ilyen ügyeket egy speciális, eldobható (azaz egyszer használatos) úgynevezett ‘Disposable’ VM-ben végezzük…

Ezzel szöges ellentétben, lehet olyan igényünk is, hogy az adott VM semmilyen hálózati eléréssel ne rendelkezzen. Ilyen elszeparált helyen biztonságosan tárolhatjuk jelszavainkat, titkos kulcsainkat, stb…

Service VM-ek

Net VM (ek)

Egyre mindenképp szükségünk lesz, enélkül ugyanis nem fogunk tudni hálózatra csatlakozni.

Egyetlen NetVM használata esetén, az összes hálózati csatolót (ethernet, WiFi, 3G) PCI szinten ehhez a VM-hez rendeljük, és az AppVM-ek ezen keresztül jutnak hálózati eléréshez…

Több NetVM használata akkor indokolt, ha külön szeretnénk választani a különböző hálózati interface-eket – és így akár egyik AppVM etherneten, míg a másik WiFin-keresztül kommunikálhat a külvilággal, anélkül hogy a hálózati adataik bármilyen közös ponton áthaladnának!

Proxy (firewall) VM (ek)

A NetVM-(ek), és az AppVM-ek közé ékelődő, speciális (a NetVM számára AppVM, az AppVM számára pedig NetVM) hálózati tulajdonságokkal megáldott VM-ek, amik biztonságos, és könnyen áttekinthető tűzfal/proxy megoldást nyújthatnak alkalmazásainknak.

A gyakorlatban leginkább VPN kapcsolatok, és/vagy TOR proxy használata esetén van jelentőségük.

Mindebből jól látszik, hogy leginkább tőlünk (és a rendelkezésünkre álló hardver teljesítményétől) függ, hogy miből mennyit hozunk létre, és ezeket pontosan mire használjuk. Így nem lehet látatlanban, mindenki számára megfelelő megoldásokat előre kitalálni…

Hogy mindez érthetőbb legyen, íme a ‘default’ hálózati struktúra:

És íme, egy bonyolultabb (több NetVM-es felállás), amiben még olyan VM is szerepel, aminek egyáltalán nincs internet elérése:

A fenti topológia nem csak példa, nagyjából ez lett megvalósítva a saját laptopomon is…

Telepítés

Maga a telepítés nem egy agyműtét, bárki – aki telepített már valaha valamilyen operációs rendszert – könnyedén elboldogul vele. Aki esetleg közelebbi ismeretségben van a redhat, fedora – vagy ezek leszármazottjaival – annak pedig kifejezetten ismerős lesz az Anaconda telepítő felület.

A sikeres telepítéshez a legfontosabb információkat a projekt wiki oldalán találjuk.

Az izgalmas rész az első boot után következik, ekkor hozhatjuk létre ugyanis a rendszerünk alapvető építőkockáit – a virtuális gépeket. Ezzel kapcsolatban 3 lehetőségünk van:

  • default Service és AppVM-ek létrehozása

Ilyenkor a telepítő elkészíti a (szerinte) szükséges összes virtuális gépet, beleértve a majdan használni kívánt AppVM-eket is – amikben az általunk használni kívánt alkalmazások fognak majd futni. Ez az opció azoknak való, akik szeretnének egyből egy használható rendszert a kezükbe kapni. Azonban én ezt maximum kiindulási alapnak ajánlom, ugyanis biztosan nem a saját igényeinket fogja tükrözni… így pedig valós felhasználásra nem lesz alkalmas a kapott rendszer.

  • csak a Service VM-ek létrehozása

Köztes megoldás, AppVM-eket nem hoz létre, csak a (szerinte) lényeges Service VM-eket. Ezek ugyan sok helyzetben megfelelőek lehetnek, azonban ez sem azt fogja tükrözni amit valóban szeretnénk…

  • semmilyen egyéb VM-et nem kérünk.

Ilyenkor semmi egyéb VM-et nem hoz létre, megkapjuk az üres dom0-át. Ez kell nekünk, hiszen innentől úgy alakítjuk a rendszert, ahogy az nekünk valóban megfelel majd a gyakorlatban is…

VM-ek létrehozása

Ha az előzetes terveinknek megfelelően, saját magunk szeretnénk minden VM-et létrehozni, akkor ezt  (parancssorból) a következőképp tehetjük meg:

[dom0]$ qvm-create Ethernet --net --label orange
[dom0]$ qvm-create Wifi --net --label purple

Majd, hozzáadjuk  a kívánt PCI eszközöket a megfelelő NetVM-hez:

Ezt a qvm-pci paranccsal tehetjük meg, pl:

[dom0]$ qvm-pci -a WiFi `lspci |grep -i Wireless |cut -d ' ' -f1`
[dom0]$ qvm-pci -a Ethernet `lspci |grep -i Ether |cut -d ' ' -f1`

Ezek után, létre kell hoznunk a proxy VM-eket is:

[dom0]$ qvm-create Andrews-VPN --proxy --label gray
[dom0]$ qvm-create Firewall --proxy --label gray
Majd, csatlakoztatni őket a megfelelő NetVM-hez:
[dom0]$ qvm-prefs -s Andrews-VPN netvm Ethernet
[dom0]$ qvm-prefs -s Firewall netvm WiFi

Végül beállítjuk, hogy melyik AppVM melyik proxy VM-hez csatlakozzon :

[dom0]$ qvm-prefs -s Banking netvm Firewall
[dom0]$ qvm-prefs -s Andrews netvm Andrews-VPN
[dom0]$ qvm-prefs -s Vault netvm none
...
Természetesen, a hálózati összerendeléseket később bármikor – akár menet közben is – megváltoztathatjuk, ezzel könnyedén elérve hogy az aktuális helyi adottságokhoz igazítsuk a hálózati kapcsolatainkat…

Finomhangolás

Természetesen, akár melyik telepítési módot is választjuk, szinte minden esetben utólag is módosíthatjuk a VM-ek paramétereit, és egymással való kapcsolatukat. Erre a már használt qvm-prefs parancs használatos… De minderről bővebben később…

Alkalmazások telepítése

Az eddigiekből láthattuk, hogy egy-egy VM létrehozása, és használatba vétele igen egyszerű és gyors. Mindez azért lehetséges, mert a VM-ek egy közös template-re épülnek.

A projekt jelenlegi fázisában egyetlen ilyen template létezik, ami pedig egy Fedora 15 alapú linux operációs rendszer. Ebből az következik, hogy ha valamilyen új alkalmazást szeretnénk telepíteni (vagy a meglévőket frissíteni) azt csak a használt template-ben kell megtenni, és utána az összes VM-ben rendelkezésünkre áll…

Használat

Ha mindezzel megvagyunk, máris használhatjuk a rendszert… Ehhez persze azt minden esetben el kell döntenünk, hogy milyen alkalmazást, melyik VM-ben szeretnénk elindítani. Ebben nagy segítség a speciálisan erre a feladatra módosított KDE menü:

Miután elindítottunk egy-egy alkalmazást, az a VM-re jellemző színű keretben fog megjelenni, ezzel reprezentálva, hogy éppen mi melyik VM-ben fut:

Így könnyen megkülönböztethetjük a céges böngészőt a privát célra használttól, vagy az ideiglenesen megnyitott ismeretlen oldat tartalmazóktól…

További dokumentációk, és felhasználási esetek a projekt wiki oldalán…

A témáról hamarosan egy ingyenes előadást is tartok, ahol élőben fogom bemutatni a rendszer működését. Eerre jelentkezni itt lehet.

Összegzés

A fentiekből láthatjuk, hogy a Qubes egy olyan, eddig elképzelhetetlen biztonsági megoldást nyújt számunkra, aminek segítségével remekül elkülöníthetjük egymástól alkalmazásainkat – és a bennük tárolt érzékeny adatainkat…

Természetesen, az is látszik, hogy ez esetben is nagyon sok múlik a felhasználótól. Neki kell ugyanis eldönteni, hogy milyen oldalt melyik VM-ben nyitja meg, vagy épp melyik VM-et milyen hálózatba csatlakoztatja… Tehát, a Qubes ‘csak’ egy eszköz ahhoz, hogy végül egy biztonságos desktop gépen dolgozhassunk, tesztelhessünk vagy épp szórakozhassunk.

A projekt jövőbeli tervei között elsőkét szerepel további operációs rendszer (többek között windows!) alapú AppVM-ek támogatása is, ami még szélesebb felhasználói körnek biztosít majd egy rendkívül jó, és biztonságos, virtualizált desktop környezetet…

Az eredeti, sokkal bővebb cikk itt olvasható.

 

Biztonságos desktop OS?

Sajnos kevesen vannak egyáltalán tisztában azzal, hogy miféle veszélyeknek van kitéve egy átlagos felhasználó számítógépe, és a rajta tárolt bizalmas/értékes adatai. Ha pedig nem átlagos, hanem pl: magas beosztású vezetőről, vagy bizalmas adatokkal dolgozó szakemberekről, vagy éppen egy IT biztonsági szakemberről van szó, akkor a veszély még komolyabb!

A hordozható számítógépek, okostelefonok, és egyéb kütyük elterjedésével a helyzet csak egyre romlik, hiszen ezekkel az eszközökkel céges hálózatokat, leveleket, és egyéb bizalmas adatokat is elérhetünk.

A leggyengébb láncszem persze legtöbbször maga a felhasználó. Köszönhető ez a informatika világának rohamos – sokak számára követhetetlen – fejlődésének, és a marketing gépezetnek, ami pedig elhiteti velünk, hogy a fészbúk elérése a legfontosabb dolog a világon ;)

Aki képes ezen átlátni, és egy kicsit is érdekli, hogyan tudhatja biztonságban a laptopján tárolt adatait, az lapozza végig ezt a rövid prezentációt, ami valójában már egy konkrét megoldásra is fókuszál, azonban termékektől függetlenül is a probléma forrására igyekszik felhívni a figyelmet…

A megoldás: szeparáció

Előfeltételek

A fenti ábrán látható architektúra megvalósításának elengedhetetlen feltételei a következők:

Hardver

Ez alapvető fontosságú processzor feature. Ennek megléte (bekapcsolt állapota) nélkül egyáltalán nem használható egyetlen HVM Hypervisor sem. Bővebben…

A Xen azonban nem csak HVM domaineket (virtuális gépekt) képes létrehozni, sőt a Qubes 1.0 VT-x nélkül is működőképes, mivel nem HVM virtualizációt használ.

Ez a fícsört szinte minden mai processzor támogatja, ám sok laptop BIOS-ból hiányzik a ki/be kapcsolás lehetősége. Az én laptopom (Esprimo V5505) is ebbe a kategóriába tartozik, így kicsit hackelni kellet a BIOS-t hogy bekapcsolható legyen.

Ez a chipset feature ahhoz szükséges, hogy a különböző I/O eszközöket is biztonságosan hozzárendelhessünk különböző VM-ekhez. Ennek megléte nélkül technikailag működőképes megoldást hozhatunk létre, viszont biztonsági szempontból nem leszünk sokkal előrébb. Bővebben...

Megléte opcionális, ezzel még tovább növelhetjük rendszerünk megbízhatóságát.

Az Intel legújabb technológiája, ami a fent említett ‘alap’ dolgokon felül, a még teljesebb hardver virtualizáció megvalósítását tűzte ki célul. Bővebben…

Szoftver

Ha a hardveres alapfeltételek adottak, akkor már csak a megfelelő szoftver kell a megvalósításhoz. Technikailag bármelyik Hypervisor alkalmas lenne erre, a gyakorlatban mégis egyelőre csak Xen alapú megoldások léteznek:

A projekt egyelőre ‘beta’ állapotban van, azonban technikailag a legjobbat szeretnék kihozni belőle, így a biztonság az első és legfontosabb szempont. Ennek ellenére egyedülálló integrációs kiegészítő szoftvereken dolgoznak, ami a különböző VM-ek közötti állománycserét, és interakciót igyekeznek biztosítani ‘felhasználóbarát’ módon.

Egyetlen hátrányos tulajdonsága, hogy egyelőre csak Linux alapú VM-eket lehet benne használni, egészen konkrétan: Fedora Mivel sokaknak nem ez a szimpatikus disztribúció, így az ismeretlen felület és beállítási lehetőségek a tesztelés során némi kényelmetlenséget okozhatnak.

Nagyobb baj az, hogy akinek elengedhetetlen a windows-os VM, az nem sokra megy ezzel egyelőre :(

A projektről azóta több cikk is született:

  1. Qubes – Beta3
  2. Qubes 1.0 – RC1

Ez a szoftver a Citrixtől, ugyan ezt ígéri, ám esetükben a windows az alapértelmezett VM, a Linux egyelőre ‘experimental’ jelzéssel van ellátva.

A termékről azóta külön cikk is született…